OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



Giovanni,
If we assume InOrder+ExactlyOnce DA (which as of now, is determined thru some out of bands means),
then the RMS can assume that message 1-5 will be delivered to the AD.
thanks
-Doug


"Giovanni Boschi" <gboschi@sonicsoftware.com> wrote on 08/30/2005 09:13:39 AM:

> I guess it’s not clear to me that we’ve resolved the issue or, if we have, which
> way we have resolved it.  Let me try to focus on the key question:

>  
> 1)       I am the RMS;  Messages 1 thru 10 arrive from the AS, and I start
> transmitting them;  some time goes by, some get acked, some may get retransmitted, …

> 2)       At some point I decide that I want to close the sequence gracefully, so I
> send a <Close>

> 3)       I receive a final ack containing  [ (1-5), (7-9) ]
>  
> Which messages will the RMD deliver to the AD?
>  
> Thanks,
> G.
>  
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Monday, August 29, 2005 8:07 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i0019 - a formal proposal - take 2

>  
>
> Additional comments inline.
> All - any additional comments?  I need to send out 'take 3' tomorrow.
> thanks,
> -Doug
>

>
> Jacques Durand <JDurand@us.fujitsu.com>

> 08/26/2005 08:44 PM
>
> To

>
> "'Giovanni Boschi'" <gboschi@sonicsoftware.com>, Doug Davis/Raleigh/IBM@IBMUS, ws-
> rx@lists.oasis-open.org

>
> cc

>
>  

>
> Subject

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

>
>  

>
>  

>
>  

>
>
>
>
>  
> Giovani:
>  
> I believe there is more in what you say below than what is needed to resolve i019 and i028.
> I am commenting on some of  your points below - but I believe they can be largely
> dissociated from the current issues at hand, and  be treated separately.
>  
> Regards,
> Jacques

>  
>
>
> From: Giovanni Boschi [mailto:gboschi@sonicsoftware.com]
> Sent: Friday, August 26, 2005 9:01 AM
> To: Jacques Durand; Doug Davis; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
>  
> I don't see the current draft as directly specifying that acks are "on receipt",
> although clearly an implementation could take that approach, and it's probably the
> more intuitive one - but, specifically I think the current draft allows an RMD to
> defer acking until the messages are "in order" i.e. not acking those messages that
> are still sitting "behind gaps".
>  
> <JD> this is a very important point to clarify. What you are in effect suggesting,
> is an Ack on delivery (since once in order, they can be delivered.). But the spec is clear:
> Acknowledgement: The communication from the RM Destination to the RM Source
> indicating the successful receipt of a message. (and in the messaging model, there
> is a clear distinction between Receipt and Delivery, see Fig 1)
>
> <dug> +1, current spec is for Ack on receipt not delivery </dug>
>  
>  
>  There is a specific benefit to the "ack when deliverable" (note deliverable, not
> delivered) approach for low-resource situations (I can elaborate if needed, let me
> know), so I would hesitate to assume that ack-on-receipt is the model used by all
> implementations at all times.  
>  
> <JD> Join the club. I have been favoring "ack on delivery" from the start, but that
> seems to clash with the WS-RM model: the protocol would become involved in the RMD-
> AD delivery assurance. Please try to convince Chris...
>
> <dug> I'm staying out of this one for now  :-)  </dug>
>  
> Now, of course, if my "ack when deliverable" approach is in use by the RMD, then
> the final ack will be accurate:  all the messages that have been acked are safely
> deliverable after a close.  It's the "ack immediately on receipt" approach that has
> that problem - but to be clear, I do not want the spec to impose an ack strategy, I
> think the freedom the spec gives the RMD on choosing an ack strategy is one of the
> coolest things in the current spec.
>  
> <JD> well... too much choice is not necessarily good here: an RMS must preferably
> know what Ack means to the other party. I prefer the spec to be clear one way or
> the other about this. I think it is now. Just not the way I prefer - because as
> drafted today, I maintain, it is OK to acknowledge a message that will never be
> delivered, and there is no provision for the RMS to know about this. But that is
> another issue.
>
> <dug> I seem to recall the notion of having some sort of handshaking going on
> during the CreateSequence where the RMD would communicate the DA in-use back to the
> RMS.  I suppose the spec could also communicate the ACK strategy as well, if there
> was more than one choice.  Not really sure I'd want to offer more than one but its
> something to think about  </dug>
>  
> I think the general way out of this may be the following:  If the original use case
> was "I want to close the sequence and have an accurate final ack so I know which
> ones to resend in a different sequence later", then it seems to me that this is
> really only viable for sequences that do not have InOrder requirements:  If I will
> send some of them in sequence S2 later there is no guarantee that they will be
> delivered in order with respect to the ones I sent in sequence S1 earlier, and I am
> going to break the InOrder requirement anyway.
>  
> <JD> I think if InOrder is required but not AtLeastOnce, that means we accept
> message loss - and therefore we would not have any qualms not resending these in
> S2. Even if InOrder+ AtLeastOnce is required, some gap may still be there when
> closing the sequence S1. But again, S2 can forget about the missing messages in S1:
> the DA is still satisfied if a delivery failure has been notified for the missing,
>
> <dug> A while ago there was a discussion about how to handle the linking of
> sequences for cases where the MaxMsgNum was hit.  While there wasn't a formal
> decision by the TC, quite a few people said that that notion was something that
> should be done at a higher level.  I believe the notion of how to recover a
> sequence when it is closed prematurely fits into that category as well.  So, while
> I can see your point about there still being an issue of how to safely do some
> recovery, I think its another issue.  This current proposal simply focuses on how
> the RMS can get an accurate accounting of the 'current' sequence when it is closed
> down early.  What it does with that info - if anything at all - is something else.
> And personally, while I do agree there is some higher-level processing that
> can/should take place in some situations, I do think the RM protocol could help
> make that processing easier - but as I said, that's another issue. </dug>
>  
> The RMS knows from the final ack which messages the RMD "has"; if it knew the the
> RMD<->AD DA, then it would know what to do:
> -          If the DA is InOrder, it knows that it cannot close and then restart a
> new sequence at all without violating the underlying ordering requirements
> -          If the DA is not InOrder then it can close and restart a new sequence
> later, and if so it should resend all messages not in the final ack.
>  
> <JD> These behaviors are somehow out of scope of the spec: there is no requirement
> on dealing with missing messages across sequences.  That is an optimization that
> can indeed rely on out-of-band knowledge of the DA.
>
> <dug> yup - current out of scope or that 'higher level' thing I mentioned </dug>
>  
> But, the RMS does not know the RMD-AD DA; I guess we could propose that the target
> endpoint publish its DA in its policy (or createSequence, whatever), and I
> personally think it would be a good thing even for unrelated reasons - but I
> suspect there could be a lot of opposition - You have to go back to a 2002 version
> of the member submission to find DA in the policy, and I think this was removed
> very much intentionally.  But maybe we could propose it and see?
>  
> A minor point on wording:  I think rather than "MUST not accept" we should say
> "MUST not deliver to the AD" as in the original text below - "accepting" is not
> something that we define anywhere and it could be misconstrued.  Not delivering is
> what matters.
>  
> <JD> Right for the loose terminology. But again, you are opening a can of worms: we
> do NOT want these messages to be acknowledged (not juts "not delivered") as soon as
> the closing is effective. Maybe this would do: ...RM Destination MUST NOT
> acknowledge nor deliver any received messages with a Sequence header for the
> specified sequence, other than those already received at the time the <wsrm:Close>
> element is processed by the RMD
> "-Jacques
>
> <dug> Well, it can still deliver old messages to the AD it just can't ACK new ones.
> For example, if msg 3 out of 5 is missing and a Close() comes in, the RMD can still
> deliver 1 and 2 to the AD (if it hasn't done so already).  It just can't deliver 4
> and 5.   I think 'accept' is the right choice.</dug>
>  
> G.
>  

>  
>
>
> From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
> Sent: Thursday, August 25, 2005 9:36 PM
> To: 'Doug Davis'; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
>  
> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]