Re: [ws-rx] NEW ISSUE, twin sister of i019

[Daniel Millwood <MILLWOOD@uk.ibm.com>]

Jacques,

I can see an example where this could be useful, however for my example I
can also see a workaround.

Lets say that issue i013 is resolved and an RM Source knows the maximum
message number that is acceptable for a sequence.  If ordering is not
important and the RM Source sends messages up to this maximum, then it may
want to gracefully close the sequence and start a new one to send more
messages.  If there are unACKed messages from the first sequence, then the
RM Source could keep the old sequence open to retransmit these messages and
start a second sequence to transmit new messages. Alternatively, if the RM
Source new the final ACK state of the first sequence, it could close it,
then send any untransmitted messages in the new sequence.

The part of the proposal Im not so keen on, is the idea that the RM
Destination must maintain the final ACK state even after the RM Source has
sent it a TerminateSequence message.  I think it would have to do so with
this proposal, as there is no guarantee that any response to the
TerminateSequence message would get back to the RM Source, so if this
information was important to the RM Source then it would need a way of
polling for it as you state.

Can you give an example of why an RM Source would need to terminate a
sequence with gaps in it?

Thanks,  Dan

WebSphere Platform Development
MP 211
Hursley
Tel. Internal 248617
Tel. External +44 1962 818617
Email. millwood@uk.ibm.com



                                                                           
             Jacques Durand                                                
             <JDurand@us.fujit                                             
             su.com>                                                    To 
                                       ws-rx@lists.oasis-open.org          
             04/08/2005 23:50                                           cc 
                                                                           
                                                                   Subject 
                                       [ws-rx] NEW ISSUE, twin sister of   
                                       i019                                
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I realize that we should probably discuss this new issue in conjunction
with i019, i.e. before closing on i019.
(it is stating a similar problem, but for normal termination cases.)

Daniel:
With the perspective of this new issue, I am leaning more toward your
proposal to mark as "last" the final sequence status.


Jacques


Title: Accuracy of acknowledgement status upon normal sequence termination

Description: The specification does not address the situation where upon
normal
termination of a sequence, some message that were previously sent and never
acknowledged
(for which RM Source had stop any resending effort) has been received late
by RM Destination,
e.g. between the sending of the last SequenceAcknowledgement and before the
reception of
a TerminateSequence message. This is the twin sister of issue i019 which
deals with a similar
problem but in case of fault termination.

Justification: Normal termination is actually a fairly common event
(compared to sequence fault)
and it is expected that sequences will be terminated even if they have
missing messages.
The specification is too lax on the loophole that permits stray messages to
"sneak-in" just before a termination, without any opportunity to be
acknowledged.

Target: core
Type: design

Proposal: A final acknowledgement status could be sent back that reflects
the exact state
at termination time. That could be done by sending (or by making available
for polling
even after the sequence is terminated) a last SequenceAcknowledgement
element, at the time
the RM Destination terminates the sequence (either at reception of
TerminateSequence,
or due to timeout). Such a SequenceAcknowledgement element should have a
"last" marker.