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




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