[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] NEW ISSUE: Sequence termination on Fault
Patil, Sanjay wrote: > > 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. > I know you are not suggesting that this be a requirement (and I don't think Jacques is either). But I was curious as to why this would be a requirement. Isn't this something that specs that layer on top should do, if they choose to do so? WSRM specifies a contract for a session (sequence). If something needs to be done across sessions, it seems to me that this should be done in a spec layered on top of WSRM. -Anish -- > 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:JDurand@us.fujitsu.com] > *Sent:* Monday, Jul 18, 2005 16:41 PM > *To:* 'Doug Davis'; Duane Nickull > *Cc:* ws-rx@lists.oasis-open.org > *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:dug@us.ibm.com] > *Sent:* Monday, July 18, 2005 12:30 PM > *To:* Duane Nickull > *Cc:* Christopher B Ferris; Doug.Bunting@sun.com; Jacques Durand; > Paul Fremantle; 'Patil, Sanjay'; ws-rx@lists.oasis-open.org > *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 <dnickull@adobe.com>* > > 07/18/2005 11:35 AM > > > > To > > > > Paul Fremantle <pzf@uk.ibm.com> > > cc > > > > Jacques Durand <JDurand@us.fujitsu.com>, "'Patil, Sanjay'" > <sanjay.patil@sap.com>, Doug.Bunting@sun.com, Christopher B > Ferris/Waltham/IBM@IBMUS, Doug Davis/Raleigh/IBM@IBMUS, > ws-rx@lists.oasis-open.org > > 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. >> >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]