time issues

[Jacques Durand <JDurand@fsw.fujitsu.com>]

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?