Inline <JD>
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, August 25, 2005
5:59 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a
formal proposal - take 2
When InOrder DA is used the RMS knows that all messages
after the first gap were not delivered to the RMD's application - even if they
were ACKed.
<JD>
InOrder DA in itself does allow delivery of non-contiguous messages ( "...it
says nothing about duplications or omission..." Section 2, Core spec)
So, getting an ACK+Final
guarantees to the RMS which messages were not just ACKed but delivered - and
any messages after the first gap can be recovered (e.g. resent in a new
sequence if it wants) without fear of them being processed twice by the RMD's
app.
Actually, thinking about it more, perhaps some of the text should remain, like:
When a Sequence is closed and there are messages at the RM Destination
that are waiting for lower-numbered messages to arrive (such as the
case when InOrder delivery is being enforced) before they can be
processed by the RM Destination's application, the RM Destination
MUST NOT deliver those messages.
Just to ensure that the RMD does not interpret
the Close() as the trigger to let all messages after the gap thru to the app.
thanks,
<JD>
but again, because the semantics of Ack is just "on receipt" and
not "on delivery", an honest RMD developer may decide to Ack these
late messages, rendering the final Ack incorrect (or unstable, depending when
it is requested...). Another way to avoid adding this text is to make the
statement below more general, not limited to "new application messages":
"...can send a <wsrm:Close> element, in the
body of a message, to the RM Destination to indicate that RM Destination MUST
NOT accept any new application messages for the specified sequence."
Replace with:
"...can send a <wsrm:Close> element, in the
body of a message, to the RM Destination to indicate that RM Destination MUST
NOT accept any application messages for the specified sequence, other than
those already received at the time the <wsrm:Close> element is
interpreted by the RMD."
-jacques
-Doug
"Giovanni Boschi"
<gboschi@sonicsoftware.com>
08/25/2005 08:48 PM
|
To
|
Doug Davis/Raleigh/IBM@IBMUS, "Jacques Durand"
<JDurand@us.fujitsu.com>
|
cc
|
<ws-rx@lists.oasis-open.org>
|
Subject
|
RE: [ws-rx] i0019 - a formal proposal - take
2
|
|
If the RMD has already acked the out-of-order
messages (and the spec at this point doesn't say it can't or
shouldn't), and we then preclude the RMD from delivering them, then the
final Ack is not accurate, which I thought was the original goal. Even if
we leave it undefined, the RMD may choose not to deliver them, and the problem
remains.
G.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, August 25, 2005 7:23 PM
To: Jacques Durand
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
Jacques Durand
<JDurand@us.fujitsu.com> wrote on 08/25/2005 02:10:04 PM:
> When a Sequence is closed and there are messages at the RM
Destination
> that are waiting for lower-numbered messages to arrive (such as the
> case when InOrder delivery is being enforced) before they can be
> processed by the RM Destination's application, the RM Destination
> MUST NOT deliver those messages and a SequenceClosed fault MUST
> be generated for each one.
> <JD> it is important to also say that it should not acknowledge them
either.
If we change it so that it says nothing about those messages instead,
as Anish and Chris are suggesting, would that be ok with you?
So, basically, the semantics of undelivered messages would be undefined by
removing the above paragraph.
thanks,
-Doug