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] i066:Proposal to remove LastMessage, but retain LastM essagefunctionality



True but the RMD needs to be in some state w.r.t. the sequence no matter what (w/ or w/o the LM)  - it can not drop knowledge of the sequence until it either times out or it gets a terminate.  Anish's comment about being able to drop the queue but not the other metadata about the seq might be true when the LM marker is there - the issue is whether keeping this feature is worth this one scenario.  Personally, I've never like the idea of sending an empty LM message - it felt a bit like a hack, and I'm inclined to think that if an implementation is going to have issues with the size of an empty queue then we need to worry about the totally unused sequence more than the used/completed/droppedTerminate one - I think that's the more common case.
thanks,
-Doug


Tom Rutt <tom@coastin.com> wrote on 12/01/2005 12:49:28 PM:

> Jacques Durand wrote:
>
> > Bob:
> >
> >  
> >
> > In a LastMessage-less scenario, If RMS got all the acks it was waiting
> > for (having knowledge of what was last message it sent for this
> > sequence)  it has no need to close the sequence: it can terminate it
> > directly.
> >
> I think the point Anish is making is that since terminate is not
> acknowledged, it may never arrive at the RMD.
>
> If Terminate does not arrive at the RMD, the RMD will be in a permanent
> state of connected, unless the sender resends the lost "Terminate".
>
> But the sender would not know it had to resend since terminate is a
> one-way operation.
>
>
>
> Tom Rutt
>
> >  
> >
> > Bottom line is: "someone" (either RMS or RMD) will have to wait for
> > all messages to have been received (or wait for a confirmation of
> > this) to take action for reclaiming resources on RMD side.
> >
> > - With LastMessage, RMD has to remember.
> >
> > - Without LastMessage, RMS has to remember.
> >
> >  
> >
> > Sure there is a final additional TerminateSequence to be sent in
> > second case, but that small overhead is to balance with the increased
> > complexity of the protocol in first case.
> >
> > Note that this overhead in the sequence termination protocol
> > disappears in case the AS happens to knows it was its last message -
> > or cares to signal this to RMS -  only *after*  having sent it, (as
> > opposed to at the time that last message is being sent) which I expect
> > to be by far the most common case. Indeed in that case, an empty
> > additional message with LM will have to be sent.
> >
> >  
> >
> > Jacques
> >
> >  
> >
> > ------------------------------------------------------------------------
> >
> > *From:* Doug Davis [mailto:dug@us.ibm.com]
> > *Sent:* Wednesday, November 30, 2005 10:58 PM
> > *To:* ws-rx@lists.oasis-open.org
> > *Subject:* Re: [ws-rx] i066:Proposal to remove LastMessage, but retain
> > LastMessage functionality
> >
> >  
> >
> >
> > "Bob Freund-Hitachi" <bob.freund@hitachisoftware.com> wrote on
> > 11/30/2005 08:19:14 PM:
> >> The issue 66 requires the the RMS to wait for receipt of all of the
> >> Acks before issuing CloseSequence to safely close the sequence.
> >> However, LastMessage does not require the RMS to do so.
> >> The reason is that LastMessage contains a message number while
> >> CloseSequence does not.
> >> If we were to add an optional last message number element to the
> >> CloseSequence message the functionality of LastMessage would be
> >> preserved should LastMessage be determined to be superfluous.
> >
> > I'm assuming you want to add a lastMessage to Close is so that the RMD
> > will still allow lower numbered messages in - if so then that defeats
> > the purpose of Close since its intention is to prevent ANY new messages
> > from being delivered - in otherwords, the RMS is ok with the gaps that
> > may exist in the sequence.
> > thanks,
> > -Doug
> >
>
>
> --
> ----------------------------------------------------
> Tom Rutt   email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>
>


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