Re: [ws-rx] NEW ISSUE: Sequence termination on Fault

[Paul Fremantle <pzf@uk.ibm.com>]

I also agree about not having a hard max number. I can imagine a
lightweight implementation of WSRM being used in an embedded control system
- for example using it for reliable delivery over UDP, with a small max
message number.

I think Jacques' points about handling the rollover problem "smoothly" are
key. I would like to see an explicit sequence take-over model that can be
used to preserve ordering across sequences where one sequence has ended -
prematurely from the RM sources perspective.

Paul

Paul Fremantle,

STSM, WebServices standards and architecture
Hursley WebServices Team
Consulting IT Specialist
IBM Hursley Lab (MP 189)
 Winchester, SO21 2JN, UK

ph+fax    44 (0) 1962 815 078
int ph: 245 078
pzf@uk.ibm.com
"God, however, has chosen the most perfect world, that is to say the one
which is at the same time the simplest in hypotheses and the richest in
phenomena." Liebniz

Jacques Durand <JDurand@us.fujitsu.com> on 15/07/2005 16:19:51

To:    "'Patil, Sanjay'" <sanjay.patil@sap.com>, Doug.Bunting@sun.com,
       Christopher B Ferris <chrisfer@us.ibm.com>
cc:    Doug Davis <dug@us.ibm.com>, ws-rx@lists.oasis-open.org
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-----
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.

Thoughts?

Thanks,
Sanjay