ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Mon, 29 Aug 2005 19:45:25 -0400
Jacques,
comments inline
thanks
-Doug
Jacques Durand <JDurand@us.fujitsu.com> wrote
on 08/25/2005 09:35:37 PM:
> 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)
<dug> Perhaps I should have said InOder+ExactlyOnce
- when combined I think we'll
get the semantics we want. Odd that InOrder
_could_ mean you have gaps - that
implicitly means that gaps could get ACKd but never
actually delivered. weird. </dug>
> 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."
Means the same to me :-) but it you think
it makes it clearer. ok
> -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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]