[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
This is what the specification says: "After an RM Source receives the <SequenceAcknowledgement> acknowledging the complete range of messages in a Sequence, it sends a <TerminateSequence> element, in the body of a message to the RM Destination to indicate that the Sequence is complete, and that it will not be sending any further messages related to the Sequence." This, at least to me, says pretty clearly that a conformant RMS will not send TerminateSequence until all messages have been acknowledged, and that it will not send any new messages after sending TerminateSequence. To be sure, duplicates of messages previously sent (and acknowledged) may arrive at the RMD after TerminateSequence. But these are duplicates, not unacknowledged messages. The specification has a definition of "normal termination" which requires that all messages be acknowledged, and therefore the "situation whereupon normal termination of a sequence some messages that were previously send and never acknowledged..." is, by definition, impossible. The "accuracy of acknowledgments upon normal sequence termination" is 100% perfect. Now, during the call today, Jacques seemed to suggest that what was behind this is that a sender may need/want to terminate the sequence prior to all messages being acked; this may well have merit, or at the very least is worthy of discussion; the current spec clearly does not allow it, and it is well within the responsibility of the TC to consider such a change. But if the request is to change the definition of sequence termination, or maybe to provide an additional type of termination, the issue description should clearly say just that ("we should allow for normal termination prior to acknowledgement of all messages"); but nothing in the text of the issue suggests that we are looking for a change in definition of normal termination. I don't know whether procedure allows revising the text of the issue for clarity. As it stands now both the description and justification below contain statements that appear to me to be factually incorrect, or at best highly misleading. It should not be surprising that this generates long discussions in the confcall about whether to even accept it as an issue. I will speculate that I may have an idea of what Jacques may be after: a sender may, for a variety of reasons which we could discuss (e.g. it is being shut down for maintenance longer than the sequence expiration), be forced to stop resending; if so, it would be nice to know which messages actually got delivered or didn't, so that it may send the undelivered ones again later in another sequence w/o duplicating them. AckRequested does not serve this purpose because, unless the sequence is actually terminated, there may be more message out there in flight which will actually arrive at the RMD and be delivered. But I'm just speculating, the issue doesn't say that. Jacques, please clarify. Giovanni. ________________________________________ From: Jacques Durand [mailto:JDurand@us.fujitsu.com]=20 Sent: Thursday, August 04, 2005 6:50 PM To: ws-rx@lists.oasis-open.org 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=20 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,=20 e.g. between the sending of the last SequenceAcknowledgement and before the reception of=20 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=20 "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=20 the RM Destination terminates the sequence (either at reception of TerminateSequence,=20 or due to timeout). Such a SequenceAcknowledgement element should have a "last" marker.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]