Hi Jacques,
I agree with you in principle that our issue
descriptions should be precise and accurate. However the danger with honing and
sharpening an issue too much now (as opposed to later when we actually
schedule the issue for TC discussion) is that the discussion may prematurely
move in the direction of a particular solution.
I guess we are both agreeing that the current design of
terminating the entire sequence upon encountering faults appears to
be too broad sweeping and may not have taken into account all the
consequences as well the other possible courses of action. Now we may scratch
our heads and attempt to exhaustively list the problems with the current
design or we could simply step back, log the high level problem area
for now and review all the available options in the light of the
actual problem to be solved later.
I agree that your issue text below correctly
identifies the key problems with the current design (handling of messages in the
abruptly terminated sequence on fault). However there may still be some other
unclear aspects that we haven't yet thought about such as - whether the
Source is allowed to reuse the identifier of the aborted sequence. Therefore I was
suggesting to phrase the issue such that it describes the root cause of the
problem rather than trying to list all the symptoms.
Having said that, I am fine with your proposed text with
the hope that we will remember to visit the root cause at the time of
actually discussing a solution. I guess that would be an AI for myself
:-)
Thanks,
Sanjay
From: Jacques Durand
[mailto:]
Sent: Tuesday, Jul 19, 2005 16:09
PM
To: Patil, Sanjay;
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:]
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.
