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

[Doug Bunting <Doug.Bunting@Sun.COM>]

Sorry for the late response.

thanx,
	doug

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 
> group, an INVALID_GROUP_PARAMETER FAULT MUST be returned.
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 
present?

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

...