RE: [ws-rx] Issue i066: life without LastMessage (why it's not so bad)

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

Title: RE: [ws-rx] Issue i066: life without LastMessage (why it's not so bad)

Tom:

You are right.
But what you are actually saying is that the only advantage we have with LastMessage is that it allows for overcoming - in a very particular case -  the general unreliability TerminateSequence is afflicted with. That should be another issue as you point out: I notice that any other op message has a "___Response" counterpart, i.e. is a request-response operation, which makes it possible for RMS to achieve some form of reliability for it - e.g. resend until response. TerminateSequence should benefit from the same.

Jacques

-----Original Message-----
From: Tom Rutt2
Sent: Wednesday, November 30, 2005 1:45 PM
To: Jacques Durand
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Issue i066: life without LastMessage (why it's not so bad)

Jacques Durand wrote:

> Here is why we can now achieve *exactly* what LastMessage was doing
> without "LastMessage" (even though we sure do not have any quite
> equivalent operation, Tom)
>
One comment inline

> First, Note that two things are to be distinguished:
> (a) The AS notifying RMS that this message is the last one for the
> sequence.
> (b) The RMS notifying to RMD that this message is the last one to be
> ever sent for the sequence.
>
> We make the case here that (b) is unnecessary, and that (a) + existing
> ops can do the same thing (though (a) is an out-of-scope feature
> anyway for the spec.)
>
> So (b) allows an RMD to:
>
>  (1) reject messages of higher numbers than last. But why would an RMS
> that knows it has sent its last message, keep sending more for this
> sequence? It is the RMS that should enforce that more efficiently than
> the RMD would, i.e. rejecting any further message submitted for this
> sequence after the "last " was indicated by (a).
>
> (2) Automatically terminate and reclaim resources. But with
> LastMessage, RMD has to wait for all gaps to be filled.
> - If some gaps never fill, sequence will have to be terminated another
> way on RMD side. The feature is of no use here. We can do clean
> (accurately acknowledged) termination now with CloseSequence.
>
> - If no gaps, with LastMessage the sequence is automatically
> terminated and acknowledged, and resource reclaimed on RMD side. But
> the same could have been achieved with (a) + TerminateSequence: once
> the RMS knows that a message was last, and after it got the ack for
> all the sequence, "last" included, then RMS automatically sends a
> TerminateSequence message. Although this is useful behavior, it is
> conditioned by AS telling RMS about the "last", which is out of scope
> of the specification. Sure that takes one more run-time message than
> with LastMessage feature, but that takes one less operation to
> implement (and not a simple one !).
>
The problem is that terminateSequence is not a request response
operation. If it had a response, then the rms could resend terminate
after some time (with either a positive response or a fault if the
sequence is already terminated).

This seems to be missing in the current spec.

Tom Rutt.

> So my opinion is, LastMessage is now just a (minor) optimization
> feature for a very special case of termination (known last message and
> no sequence gaps) that can very well be handled otherwise.
>
> Jacques
>

--
----------------------------------------------------
Tom Rutt        email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133