[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ws-rx] NEW ISSUE: Sequence termination on Fault
Sanjay, 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. Regards, Jacques -----Original Message----- 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. Thoughts? Thanks, Sanjay |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]