Re: [ws-rx] NEW ISSUE: Remove LastMessage

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Hey Doug,

Comments inlined below.

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.

-Anish
--

Doug Davis wrote:
> 
> Anish,
>   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.

> 
>   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.

> 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.

> 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?

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.

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.

> There are 
> no new resources that
> it can drop based on it.  It must still maintain the ack state in case 
> an AckReq comes in.
> If there are some other bits of data that it can now forget about I 
> would claim that it could have
> forgotten about them even w/o the LastMessage marker.
> 
> thanks
> -Doug
> 
> 
> 
> *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
> 
> 11/02/2005 09:54 PM
> 
> 	
> To
> 	Marc Goodner <mgoodner@microsoft.com>
> cc
> 	Jacques Durand <JDurand@us.fujitsu.com>, Doug Davis/Raleigh/IBM@IBMUS, 
> ws-rx@lists.oasis-open.org
> Subject
> 	Re: [ws-rx] NEW ISSUE: Remove LastMessage
> 
> 
> 	
> 
> 
> 
> 
> 
> Our (Oracle) email server is having some problems (delays) with
> delivering external emails intermittently since yesterday. I'm therefore
> relying on the OASIS email archive [1], which is not very reliable
> (based on the complaints that I have seen on this list -- ironic given
> the work that this TC is doing ;-) ). Apologies if I missed emails in
> this thread that already repeat/refute the argument below.
> 
> I don't think we should remove the LastMessage marker, but not for the
> reasons that Marc is stating (security/consistency). I quite agree with
> Doug on the security/consistency part. The LastMessage marker serves a
> very important purpose:
> 
> Under non-failure/normal operating conditions, there would not be a
> CloseSequence message sent. The Sequence would start with CS/CSR
> messages followed by Seq/SeqAck/SeqNack/ReqForAck messages and end with
> TerminateSequence message. The TerminateSequence message does not
> contain the last sequence number and is a message that can get lost (is
> not reliable).
> 
> If the TerminateSequence message is not received by the RMD and the
> LastMessage marker is *not* present in the last message of the sequence,
> the RMD has to hang around and keep its resources around until it times
> out. Once it times out it is going to assume (incorrectly) an abnormal
> termination of the sequence (and perhaps take corrective action).
> 
> If the TerminateSequence message is not received by the RMD and the
> LastMessage marker *is* present in the last message of the sequence, the
> RMD knows that it is done with the sequence and has to only be around to
> receive the final terminate message (or request for acks/re-ack, if any
> ack was lost) and may free up some of its resources. In this case, the
> loss of the TerminateSequence message does not result in an abnormal
> termination of the sequence on the RMD side on time out and no
> corrective action is necessary on the RMD side.
> 
> If the LastMessage marker is removed, there is a possibility (when the
> TerminateSequence message is lost) that the RMD may abnormally terminate
> the sequence when in fact it is not necessary to do so.
> 
> Hope that makes sense.
> 
> Thx.
> 
> -Anish
> --
> 
> [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/messages.php
> 
> 
> Marc Goodner wrote:
>  > I’m not so sure. I need to think about this some more.
>  >
>  >  
>  >
>  > A couple of observations though. First removing this breaks at least one
>  > point of consistency with the contributed spec. I suggest we think
>  > carefully before doing that. Second I don’t see this as a “protocol
>  > complexity” issue. While the Close operation could completely subsume
>  > the LastMessage marker you can still use this marker today without using
>  > Close at all. That seems valuable to retain as it provides a simpler
>  > protocol interaction capability in normal circmstances.
>  >
>  >  
>  >
>  > I disagree that this should be removed because a security mechanism can
>  > address part of the functionality. I might agree is the composition with
>  > that security mechanism was actually defined. If that is part of the
>  > rationale for this I suggest not doing this until we have that security
>  > composition defined.
>  >
>  >  
>  >
>  > ------------------------------------------------------------------------
>  >
>  > *From:* Jacques Durand [mailto:JDurand@us.fujitsu.com]
>  > *Sent:* Wednesday, November 02, 2005 10:47 AM
>  > *To:* 'Doug Davis'; ws-rx@lists.oasis-open.org
>  > *Subject:* RE: [ws-rx] NEW ISSUE: Remove LastMessage
>  >
>  >  
>  >
>  > +1
>  >
>  > I thought about proposing this too. The new Close operation subsumes
>  > almost completely the LastMessage marker  - the
>  >
>  > added value is not worth the added protocol complexity.
>  >
>  > -Jacques
>  >
>  >  
>  >
>  > ------------------------------------------------------------------------
>  >
>  > *From:* Doug Davis [mailto:dug@us.ibm.com]
>  > *Sent:* Wednesday, November 02, 2005 7:30 AM
>  > *To:* ws-rx@lists.oasis-open.org
>  > *Subject:* [ws-rx] NEW ISSUE: Remove LastMessage
>  >
>  >  
>  >
>  >
>  > Title:Remove LastMessage
>  >
>  > Description:
>  > The LastMessage element, as part of a Sequence header element, appears
>  > superfluous. It seems to serve 2 purposes:
>  > 1 - force a SeqAck to be sent back from the RMD
>  > 2 - force the RMD to reject any messages with a higher message #
>  >
>  > #1 can be done with an AckReq header.  We should avoid having multiple
>  > ways to do the same thing.
>  > #2 is really only an issue if someone tries to hijack the sequence - and
>  > to protect against that we should be using a real security mechanism
>  > like WS-SC/Trust, not the LastMessage element.
>  >
>  > When an RMS is done with a sequence it is free to simply Close or
>  > Terminate it (whether or not it has all of the Acks it wants - but
>  > normally it will wait) - having an additional message exchange to send a
>  > LastMessage is unnecessary.
>  >
>  > Justification: See above.
>  >
>  > Target: core
>  >
>  > Proposal:  Remove all references to LastMessage (and related Fault)
>  >  from the spec [1].  See attached diff/pdf file for the specific changes.
>  >
>  > [1]
>  > 
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf 
> 
>  >
>  >
>  >
>  > Note the protocol flow/example picture was updated too.
>  >
>