Hi Jacques,
Just to clarify - do you have a requirement for
cross-sequence ordering? If yes, could you please post an issue
using Marc's template and include your solution proposal in
there.
So far the
following three issues have been proposed that are related to max
message number handling, but none of these explicitly state the requirement for
cross-sequence ordering:
a> RM policy for max message number - Doug
Davis
b> Conformance when max message number is smaller - Doug
Bunting
c> Graceful sequence termination on fault - Jacques
Durand
Thanks,
Sanjay
From: Jacques Durand
[mailto:]
Sent: Monday, Jul 18, 2005 16:41
PM
To: 'Doug Davis'; Duane Nickull
Cc:
Subject: RE: [ws-rx] NEW ISSUE: Sequence
termination on Fault
Looking at this from
the "requirement" perspective:
- there
probably isn't a need to require that an RM Destination takes care of
cross-sequence Ordering (that is not such a benign requirement: would affect
the protocol: e.g. require associating somehow a new sequence ID with a
previous one.)
- but
there may be a requirement that an RM Source be able to order two sequences if
it wishes to do so (even if a RollOver or other fault occurred on first
sequence.) And for this I believe that all what is needed is again to
provide the same control on the sequence termination to the Source as in
normal cases, so that a Source can decide to initiate the new sequence only
after getting all the Acks it was waiting for (and if not getting these,
knowing which messages are lost).
Assuming that the
second point is what we are shooting for, I believe a little more is needed
actually:
The spec says
(section 3.5)
"...After an RM Source receives
the <SequenceAcknowledgement>
acknowledging
the
complete range of messages in a
Sequence, it sends a <TerminateSequence>
element,..."
A corner case here,
is when the (few) last message(s) of a sequence appear to be lost. At some
point the RM Source will stop asking for their Acks, and stop resending, and
will consider these as not received. To ensure there is no chance that a tardy
message (e.g. delayed by some intermediary) makes it to the Destination after
the last Ack was sent by the latter and before the TerminateSequence takes
effect, a final Ack for the entire sequence could be sent *at the time it was terminated* That would
help deal with sequence transition issues.
Jacques
From: Doug
Davis [mailto:]
Sent: Monday, July 18, 2005 12:30
PM
To: Duane
Nickull
Cc: Christopher B
Ferris; ; Jacques Durand; Paul Fremantle; 'Patil,
Sanjay';
Subject: Re: [ws-rx] NEW ISSUE: Sequence
termination on Fault
Duane,
I believe Paul is
talking about a new, second, sequence that is used as a
rollover for the first
sequence - not reusing the original sequence. If the
second sequence could
preserve the InOrder-ness (assuming that is the DA
needed) across sequences then
I believe it should work. The question is
whether or not this type of
logic is something the spec should help support
or leave it up to the source
to deal with it on its own.
thanks,
-Doug
Duane
Nickull <>
07/18/2005 11:35
AM
To
Paul Fremantle
<>
cc
Jacques
Durand
<>, "'Patil, Sanjay'"
<>, , Christopher B
Ferris/Waltham/IBM@IBMUS, Doug Davis/Raleigh/IBM@IBMUS,
Subject
Re: [ws-rx] NEW
ISSUE: Sequence termination on
Fault
Paul:
I am a bit confused. Rolling over a message sequence
number and
preserving the
original sequence does absolutely nothing to reclaim
resources or mitigate the problem of superseding the
destinations
capabilities.
Assume for example that the
rollover was at 1000 and message 1001 is now
the new 0001. In order to facilitate reliable
messaging, the
destination still
has to preserve all 1000 of the original message plus
reconcile message 0001 as message
1001, not have duplicate message
0001's in the sequence. Since the messaging component
of the stack is
relatively dumb
and will get its instructions for things like rolling
back transactions form the
application/business layer, it cannot release
the first 1000 messages since the upper stack logic may
dictate that if
message 1003 is
not received in XX minutes, the entire sequence should
roll back to message 934.
Accordingly, it must persist all messages in
the sequence or throw an unrecoverable
fault.
The rollover is
currently an unrecoverable fault and nothing more.
That is how it is written in the
current draft.
Did I miss
something? Please correct me if I did.
Thanks
Duane Nickull
Paul Fremantle wrote:
>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.
>
>
>
>
