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