ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] New Issue; SequenceAcknowledgement:Final assumption ofdeliverability
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 23 Mar 2006 08:22:45 -0500
Bob - this gets into the entire DA issue
which is out of scope. All the RMD can/should say is whether or not
it got the messages - and that list of messages should never decrease.
If there are gaps in the sequence then the RMS will know which messages
will be delivered (or not) based on the DA in use. How it knows the
DA is out of scope :-)
thanks,
-Doug
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
03/23/2006 06:35 AM
|
To
| Doug Davis/Raleigh/IBM@IBMUS,
"[WS-RX]" <ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [ws-rx] New Issue; SequenceAcknowledgement:Final
assumption of deliverability |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]