OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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

Subject: Re: [wsrm] Task Force Proposal to Resolve Issues Rel 52 and Rel 57

Sorry for the late response.


On 15-Dec-03 11:58, Tom Rutt wrote:

> This is the propsal from myself, Jacques, and Sunil.
> This  proposes exact text changes to resolve the group timing parameter 
> semantics.
> I propose we can make a motion, on Tuesday, to close these issues.
> Please review before the call on Tuesday, and use email to propose any 
> changes to the
> text.
> ------------------

> c) If guaranteed deliver is requested for the group, subsequent messages 
> in the sequence do not need to repeat the group persistence 
> parameter. When guaranteed delivery is mandated for the group, it is 
> RECOMMENDED that the sender repeats the group persistence parameters in 
> each message sent, until the first acknowledgement has been received for 
> the group.  The receiver will continue to use the latest received value 
> for the parameter chosen by the sender to apply to the group, to serve 
> as the trigger for terminating the group. If a subsequent message uses a 
> different group parameter than the one used in a prior message or uses a 
> group termination parameter not sent on the “start” message for the 
It is not clear to me that this optimization saves that much.  In fact, 
it seems to complicate the protocol.  Why not have a single set of rules 
for both guaranteed and not cases, requiring the parameters always be 

> d) In any subsequent message the parameter which was sent in the first 
> message can be changed by sending a new value.  A new value for 
> GroupMaxIdleDuration can either be increased or decreased. The protocol 
> allows change (up or down) of GroupExpiryTime, as long as it is never 
> less than maxExpiryTimeReceived.
This parameter is never mentioned later.  It seems identical to 
"maxExpiryTime received" mentioned below.  Please be consistent.


> e) The sender can explicitly terminate the group by sending a message 
> with status value “END”.  This is regardless to whether a group 
> termination parameter is in use for the group.
Need a new term besides "terminate" for this case.  The differentiation 
mentioned later seems important.

> It is RECOMMENDED that an RMP removes the ID of a singleton message 
> (message with GroupId but no SequenceNumber) from its persistent store 
> after it expires. However, unlike for singletons, it is RECOMMENDED to 
> NOT remove the ID of a message that belongs to a non-singleton group, 
> when the message expires. The reason is, message IDs for groups can be 
> stored efficiently as intervals of integers.
Why are these recommendations made?  Removal of information that may no 
longer be required should be an implementation decision.

> NOTE: When doing duplicate checks for messages of a group, there is no 
> loss of performance in checking over all past message IDs of the group, 
> whether expired or not. The check will in fact be faster, because not 
> discarding expired IDs means fewer intervals to look up.
On the other hand, this may be useful non-normative material.


> A group is complete when all the messages between ‘start’ to ‘end’ are 
> received.
It is not at all clear from the discussion in this proposed section and 
elsewhere in this proposal whether the 'end' message must be sent.  That 
makes everything here ambiguous.


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