OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[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]