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)


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

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)

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

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



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