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:
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.
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.
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.