OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ws-rx] NEW ISSUE: Is an implementation supporting a smaller max message number valid? [Re: [ws-rx] NEW ISSUE: Max message number in policy]

I am a bit skeptical about mandating a fixed value for the max message
number in the spec. What is sufficient for one domain may be entirely
unacceptable for some other domain. This is not to challenge our
collective judgment but it just seems harder that a particular value
would be universally satisfactory. 

So one option may be to not specify a rigid value for max message number
but just support declaring the max message number (we will have to spell
out what that means). A conformant implementation in this case would be
the one which obeys what it declares.

Besides whatever path we take, I think there are also couple of other
questions that we may want to look into:
- How is InOrder QoS handled when messages get rolled over into multiple
sequences? If all bets are off, then we should state that clearly.
- How is the sequence termination due to message number rollover
handled? The current text for MessageNumberRollover fault reads - It is
an unrecoverable error and terminates the Sequence. This sounds a bit
abrupt compared to a normal sequence termination.



>-----Original Message-----
>From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] 
>Sent: Thursday, Jul 14, 2005 18:43 PM
>To: Christopher B Ferris
>Cc: Doug Davis; ws-rx@lists.oasis-open.org
>Subject: Re: [ws-rx] NEW ISSUE: Is an implementation 
>supporting a smaller max message number valid? [Re: [ws-rx] 
>NEW ISSUE: Max message number in policy]
>Taking this in a slightly different direction: I agree max 
>Java long and 
>max XML Schema unsigned long are both gigantic values.  If we 
>agree that max(unsigned long) / 2 is sufficient, another option is to 
>make that the documented maximum message number.
>This would of course leave destinations able to run out of 
>many types of 
>resources and fail in many "mysterious" ways.  A conformant J2ME 
>implementation would however be *designed* without a lower limit than 
>max(unsigned long) / 2.
>	doug
>On 14/07/05 15:20, Christopher B Ferris wrote:
>> Doug,
>> Since nine quintillion is a REALLY BIG NUMBER,  (yeah, yeah, 19 
>> quintillion is an even bigger number) 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]