RE: [ws-rx] A rewording of "Sequence termination on Fault" issue

OK Sanjay -  go for your
version of  "Description" .

I think the "justification"
part is precise enough as to show some of the effects- even if partial - that
justify action.

 

I guess that also addresses Dave Chappell
comment?

 

Jacques

 

From: Patil, Sanjay
[mailto:] 

Sent: Tuesday, July 19, 2005 7:07
PM

To: Jacques
 Durand; 

Subject: RE: [ws-rx] A rewording
of "Sequence termination on Fault" issue

 

 

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.