Doug
If “taking responsibility” for
a message implies that at least an attempt to deliver the message will be made,
then I guess that the previous ack of a message with a sequence number larger
than a gap is untruthful if in-order delivery is enforced.
The proposal allows the rmd to correct the
previous misstatement, which it had no way of knowing was untruthful at the
time it was made. The RMS had the expectation at the previous
acknowledgement that further messages may be coming which was shattered when
the sequence was closed without that expectation being met.
The RMS has no way of knowing that ordered
delivery was in effect, so it cannot second guess the RMD.
Alternatively, we could say that all
messages that have been acknowledged will be delivered, on at least a
best-efforts basis, independent of in-order delivery and the existence of gaps
in the sequence.
Or, we could define durable persistence
and a way for sequences to be resumed after closure (I think just too
complicated)
Thanks
-bob
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Wednesday, March 22, 2006
10:54 PM
To: Bob Freund-Hitachi
Cc: [WS-RX]
Subject: Re: [ws-rx] New Issue;
SequenceAcknowledgement:Final assumption of deliverability
Bob,
I'm confused - doesn't the sending of an Ack for a certain message number
already imply that the RMD is taking responsibility for it? If only
SeqAck+Final means that, then does that mean that a SeqAck (non-final) means
something less? like a lie?
-Doug
"Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>
03/22/2006 02:07 PM
|
To
|
"[WS-RX]"
<ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
|
[ws-rx] New Issue;
SequenceAcknowledgement:Final assumption of deliverability
|
|
Description
Modify definition of SequenceAcknowledgement:Final to reflect accurate ending
delivery capability status.
Justification
The protocol defines the SequenceAcknowledgement:Final element which contains
the final summary of message acknowledgements at the closure of a sequence. It
is assumed that the RMD has taken responsibility for all messages that have
been acknowledged. Depending upon the operation of the RMD and its
interface with the application, Messages that have been previously acknowledged
as received by the RMD, may never be deliverable. One such case of note
that comes to mind is the situation of a message sequence that is being
delivered in-order to an application which is closed at the time when one or
more gaps that may exist in the sequence. If this situation occurs, the
RMS will have incorrect information concerning exactly which messages have been
or will be deliverable at the conclusion of a sequence.
Note
that there is nothing in the spec that states what the RMS is to do with the
information contained in SequenceAcknowledgement:Final. This proposal
does not add any such statement, but it does permit the information to be
potentially interpretable.
Target:
core
Proposal:
Reference Core Spec CD03
insert after line 613:
SequenceAcknowledgemnt:Final shall identify only those messages that have been
delivered or which the RMD has taken responsibility for delivery without regard
to the previous acknowledgement status of any message.
State
Table impact: None