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:]
Sent: Monday, July 18, 2005 6:42
PM
To: Jacques
Durand;
Subject: RE: [ws-rx] A rewording
of "Sequence termination on Fault" issue
One comment inline ...
From: Jacques Durand [mailto:]
Sent: Monday, Jul 18, 2005 18:15
PM
To:
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.
