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: [ws-rx] NEW ISSUE: Sequence termination on Fault



1. I am filing the same issue you and I just pointed at - just generalizing it:



Title: Sequence termination on Fault


Description: The RM Destination imperatively terminates a sequence due to one of these unrecoverable errors:

- wsrm:SequenceTerminated

- wsrm:MessageNumberRollover

- wsrm:LastMessageNumberExceeded


Justification: Then any pending non-acknowledged messages will be lost for the sequence. If these were to be resent in a new take-over sequence, stealth duplicates (same messages with different seq IDs) cannot be prevented. In addition, cross-sequence ordering will be hazardous at best.


Target: core


Type: design


Proposal: After the fault was notified to Source, simply rely on regular termination procedure (either expiration-based, or under Source control), meanwhile reject any message for this sequence that exceeds the ending number in case of MessageNumberRollover or LastMessageNumberExceeded.




2. I actually chime in with your idea of NOT requiring any maximum sequence number value in the spec.

You say "...A conformant implementation in this case would be

the one which obeys what it declares..." In what I proposed (previous mail), this "declaration" could be made dynamically, sent back in the CreateSequenceResponse. No need to have it in a policy or in the spec. Another reason for this: in some resource-strapped RM Destination implementations there may be a need to dynamically limit the length of new sequences. Let us not forget that the memory footprint of a sequence state is roughly proportional to its size (i.e. to the number of "holes" in it, or integer intevals). A Destination may have to choose between allocating a few long sequences, or many smaller ones.








-----Original Message-----
From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
Sent: Thursday, July 14, 2005 7:41 PM
To: Doug.Bunting@Sun.COM; 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]



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.







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