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] NEW ISSUE: Remove LastMessage



Anish,
  comment inline.
thanks
-Doug

Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 11/28/2005 09:48:10 PM:

> I thought this issue arose because of the addition of the Close message
> and I'm not sure why the Close message changes anything wrt LastMessage
> marker.


I actually agree.  I don't think Close changes the need for (or lack of a need
for) LastMessage but if it help convince others then ok  ;-)

> >   I think your argument actually adds to the reasons why it should be
> > removed  :-)
> > You're placing some additional semantics on the LastMessage marker that
> > are not in the
> > spec and removing this marker would remove the possibility of others
> > reading too much
> > into it too.
> You are right that the spec does not explicitly say that but it seems
> like a corollary to what the spec says.

Not to me - and this ambiguity is part of the reason to remove it.

> >   The LastMessage marker has no impact on the termination of the
> > sequence.  Even
> > if the RMD gets a LastMessage marker but not a Terminate, and it chooses
> > to timeout
> > the sequence, its still an abnormal termination.
>
> Quite true, because the RMS may not have received all the Acks. But the
> RMD may not bother to do anything about it and leave it to the RMS to
> take correctly action, if necessary. Why is it that only the RMS can
> initiate corrective action (as you state below)? Wouldn't that depend on
> the application/context.

Any corrective action an RMD can take (which I think is limited to
closing or terminating a sequence) is not based on the LastMessage tag/marker.

> > The only non-abnormal
> > termination
> > is when the RMD receives a Terminate from the RMS.  And,either way, the
> > RMD needs
> > to keep the sequence state around until it gets a Terminate or it
> > decides to terminate it
> > on its own.  Receipt of a LastMessage does not change this.  
>
> But the RMD can relinquish the message store/queue at this point. All it
> has to remember is the Seq Number for the LastMessage.

What the RMD needs to remember isn't dependent on LastMessage.  Let's say
the RMS sends messages 1, 2 and 3 but 3 is lost.  The RMD will remember that
1 and 2 arrived. Upon receipt of an AckReq (w/LastMessage=3) what will it do
with this knowledge?  Nothing. It will still send back an Ack with message
numbers 1 and 2.  Knowing that the RMS sent any message # higher than 2 doesn't
change the state information of what the RMD needs to keep around.  How much
of each message the RMD needs to remember (just state vs entire message content)
is more tied to the InOrder flag - so it needs to remember the entire message
until the time it can actually deliver the message to the RMD's app.  Again,
LastMessage has no impact on this.

> > Ultimately,
> > its up to the
> > RMS to decide whether or not a sequence needs to have some kind of error
> > recovery
> > done, not the RMD, and this would be based on the Acks it receives and
> > not the delivery
> > of a Terminate (or LastMessage marker)  to the RMD.
> >
> >   As to freeing up some resources, the LastMessage doesn't change this
> > either. The data
> > an RMD retains isn't dependent on the LastMessage.  You seem to indicate
> > that the RMD
> > can free up some stuff base on this marker - this isn't true.  
>
> Any reason not to relinquish the message store, close
> connections/sessions, commit transactions etc?

Perhaps but its not based on LastMessage but rather other information,
like which messages have arrived and been delivered (as mentioned above).

> I'm assuming that the motivation for getting rid of LastMessage marker
> is so that the RMS is not forced to send an additional empty message
> when it is done. For some applications, it is not clear which the last
> message with payload is, until it has finished sending that message.

I don't think it matters.  If after message #3 is sent, the RMS decides
that that really was the last message then it can send a Terminate once it
receives the Ack for all messages (1-3).  Having to send an additional message
to say 'tag message 3 as the last one' doesn't change any message processing
logic on either side.  In either case the RMD will still need to maintain the
exact same state information.  I'm claiming that any information that you
think the RMD can relinquish upon receipt of the LastMessage could have
been dropped before the receipt of the LastMessage marker.

> What if we were to make the LastMessage marker optional? Allow RMS to
> include it and the RMD can optimize things based on the marker if it
> wishes to do so, but not require the RMS to always send it.

I still don't see what optimizations you think the RMD can do with it?
I don't think there are any - which is why I think its a useless feature.


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