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] A rewording of "Sequence termination on Fault" issue


How about:

 

"In such cases any message sent by the Source for this sequence that was valid but not yet acknowledged, or acknowledged but not yet delivered, will be lost with no good recovery or resending option."

 

(I prefer to point to a precise issue rather than just complain about "unclear semantics" ....:-)

 

Jacques


From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
Sent: Monday, July 18, 2005 6:42 PM
To: Jacques Durand; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] A rewording of "Sequence termination on Fault" issue

 

 

One comment inline ...

 


From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Monday, Jul 18, 2005 18:15 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] A rewording of "Sequence termination on Fault" issue

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

Then any pending non-acknowledged message will be lost for the sequence.  

<Sanjay> In addition, I am not sure about the fate of acknowledged messages when a sequence is abruptly terminated. Consider the case where the contract between the Destination RM and the Destination Application is In-Order delivery, and also consider that there are some holes in the sequence at the time of sequence termination due to a MessageNumbeRollover fault. In this case, it is not clear how the Destination RM is supposed to handle the acknowledged messages in the incomplete sequence. If you agree, you may want to change the last sentence above to something on the lines of  - "The semantics of sequence termination due to a fault occurrence are not clearly specified".</Sanjay> 

 

Justification: Unless an accurate and final acknowledgement status was sent back at the time the sequence is closed, the Source will not know if some non-acknowledged messages were actually received before the termination occurs. This gives the source two unpleasant options: (a) resend all non-acknowledged message in a new sequence, with the risk of causing undetectable duplicates, (b) not resend any, and these will be lost.

 

Target: core

 

Type: design

 

Proposal: Two options need be discussed: Option (1): At the time a Destination-controlled termination gets into effect, a final and accurate Acknowledgement for the entire sequence is sent back. Option (2): After the fault was notified to Source, simply rely on regular termination procedure (either expiration-based, or under Source control, so that the Source can complete its resending of pending messages and get the final acks), meanwhile reject any message for this sequence that exceeds the ending number in case of MessageNumberRollover or LastMessageNumberExceeded.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]