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