RE: [ws-rx] i0019 - a formal proposal - take 2

[Doug Davis <dug@us.ibm.com>]

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