time issues

Title: time issues

Tom:

Most of this looks fine to me.

 see comments inline for where I differ.

 

My refined proposal for Group Termination Conditions:

·        For all incoming messages in a group, the receiver checks the 

expiry time of incoming messages, and if not expired, uses the value to 

update a running statistic for the MaxExpiryTimeOfMessagesReceivedInGroup

·        The reliable message MAY contain an optional attributes, 

GroupExpiryTime of GroupId.  Presence of GroupExpiryTime indicates a 

fixed duration group.   All messages in group MUST have expiryTime less 

or equal to GroupExpiryTime

·        The reliable message MAY contain an optional attribute 

GroupMaxIdleDuration, of GroupId. Presence of GroupMaxIdleDuration 

indicates another condition to terminate group. If the receiver detects 

that no message for that group has been received for an interval of time 

equal to the GroupMaxIdleDuration, the group will be terminated

·        Neither of the two optional attributes of GroupId are allowed 

to be present in singleton groups

·        If neither GroupExpiryTime nor GroupMaxIdleDuration is present 

as attributes of GroupId, then the expiryTime of the highest sequenceNo 

sent for that group must be greater or equal to the expiryTime of all 

previous messages in the group.  For such a group, the receiver RMP 

MUST  use the MaxExpiryTimeOfMessagesReceivedInGroup as the 

effectiveGroupExpiryTime for that group.

<JD> I think this is too complex a condition - plus, infinite groups are OK !

(see my draft)

·        The presence and values of both attributes of GroupId must be 

identical for every message sent in the group.

·        If both timing attributes are present, the first criteria that 

fires terminates the group.

·        Presence of status=end always takes precedence to signal 

termination of a group.

<JD> OK, but this works only is the case when all previous messages were received.

(see proposal for detail)

·        When a group is terminated for any of the four reasons 

(status=end, reach GroupExpiryTime, GroupMaxIdleDuration passes without 

a received message, reach effectiveGroupExpiryTime) , all messages and 

group state information are held until the GroupExpiryTime if it is 

present, or until the MaxExpiryTimeOfMessagesReceivedInGroup if the 

GroupExpiryTime is not present.

 <JD> messages are not held, unless out-of-order.

The above rule concerns the "group state" , i.e. its message IDs past record,

for the sake of dup check. (see proposal for detail)

Processing order constraints must be clarified, if we can agree to the 

above.

 <JD> I have sent a "state diagram", that mimmics teh processing algo.

Does it address this?