[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agreed proposal for rel 52, 57, 82 resolution
Here is what we voted on at the Dec 16 teleconference, with the ammendments implemented. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: This proposal (draft h) is intended to close Rel 52 Rel 57, and Rel 82:
|
This proposal (draft h) was agreed to close Rel 52 Rel 57, and Rel 82: ------- Rel 52: (New rules for state persistence, also, related "timing issues") and Rel 57 Ordering and Missing Message Behavior ------- Rel 82 is on how to terminate a group which is not complete. This should be closed as resolved by this resolution to Rel 52. Rel 57 is addressed as part of T5 of Rel 52 and hence should be closed as resolved by resolution for Rel 52. Add the following text to a subsection which defines the two group termination parameters. This section should replace the existing “RemoveAfter” section of the document. ------- x.x Group termination parameters A request message MAY contain one of the following group termination parameters: - Group Expiry Time – the date and time at which the sender wishes the sequence group to terminate. - Group Max Idle Duration – On the receiver side, if the time interval since the last message was received exceeds the group max idle duration, then the sequence group may be terminated. On the sender side, the same condition applies to the time since the last message was sent. The following assumptions pertain to the two group persistence control parameters: a) the First message in a group (the one with status=start) MUST be used by the sender to indicate that time based group persistence control is in use for the group. - If the first message in the sequence of a group has neither group persistence parameter present, the group will be terminated according to condition t4 or t5. - If the first message has either of the two group persistence parameter present (either GroupExpiryTime, or GroupMaxIdleDuration) then that parameter will be used in the criteria used for terminating the group. - A fault MUST be returned if both group persistence parameters are present in any request. An INVALID_GROUP_PARAMETER fault shall be sent in this case.. - If GroupExpiryTime is in use, the sender must not send a message in that group with an ExpiryTime greater than the GroupExpiryTime. b) The group termination parameter which was sent on the first message in the group MUST have a value sent on all subsequent messages in that group. c) The receiver MUST use the value from message with the highest sequence number received for the group. 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 max(ExpiryTime) of messages received
for the group. The sender will know, when the receiver has replied to a message which contains new group persistence parameter values present, that the receiver has knowledge of the new values. If a reply to the message with the new parameters is not received in time, the sender needs to resend the group persistence parameters through a retry or in a subsequent message of the sequence. An INVALID_GROUP_PARAMETER FAULT MUST be returned if the value is decreased to be less than the max(ExpiryTime) of messages received for the group. ---------------------- Add a new section x.y Group persistence The duplicate elimination feature requires persisting the message ID (GroupId and optionally the Sequence Number), after the message has been processed and delivered (made available) to the application. The general rule about message ID persistence, is that an RMP MUST persist the ID of a message at least until the message expires regardless whether the message has been delivered or not to the application. Informative NOTE: 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 that message IDs for groups can be stored efficiently as intervals of integers. 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. Add the following new section: x.z Group Termination and State Removal Criteria These termination rules apply to both ordered and unordered groups. In all termination cases (t1, t2, t3, t4, t5) described in this section, it is not necessary to remember the ExpiryTime of all messages of a group, as only the max(ExpiryTime) of messages received for the group is needed. A
group is defined as being “complete” when all the messages from ‘start’ to
‘end’ are received. Termination of a group, and removal of its state are two distinct events. o When a group terminates, both in sender and receiver, no message is expected to be sent or received for this group anymore. When a group terminates, all subsequent messages with same group ID would be handled as belonging to a new group, unless they are duplicates of previous messages in the group, in which case they are treated as duplicates within this group. If a message is received after the termination of a group, with same GroupId as the terminated group, it May be considered by the Receiver as belonging to a new group (the Receiver is not required to verify that a new GroupId value has not already been used in a previous group, as this test is impractical). o When the state of a group is removed, any trace of the group (including status, groupId, current sequence number, as well as all received message IDs for the group (e.g. SequenceNumber intervals) are removed, and therefore not available anymore for subsequent duplicate checks. State removal may occur either at termination time or later, depending on the termination rules that follow. x.z.1 Termination (t1): ---------------- Triggering event: GroupExpiryTime is over. Receiver side: The RMP MUST NOT accept any new message for this group and MUST terminate the group. It is RECOMMENDED that its state be removed as soon as possible. No duplicate check needs to be done against that group ever. If a "late duplicate" arrives, it would never be delivered to the next layer, as its ExpiryTime, which is always earlier than GroupExpiryTime, would have expired. Sender side: The group MUST be terminated, and its state removed from the RMP. x.z.2 Termination (t2): ----------------- Triggering event: GroupMaxIdleDuration is over. Receiver side: The group MUST be terminated. But unlike (t1), some of its past messages may not have expired yet, and therefore their ID still be needed for duplicate checks. If we define max(ExpiryTime) as the max of all ExpiryTimes of messages already received for a group, an RMP MUST persist the state of a group even after termination of the group, at least until max(ExpiryTime) is reached, in case duplicate elimination is required. Sender side: The group MUST be terminated, and its state removed from the RMP when the time elapsed since the last sent message (including retries) exceeds GroupMaxIdleDuration. x.z.3 Termination (t3): ---------------- Triggering event: the RMP receives a status="end" message. The group had either GroupExpiryTime or GroupMaxIdleDuration specified. Subcase t3.1: The group was complete on receiver side.
Receiver side: The group MUST be terminated. However, its state is removed according to (t1) or (t2), depending which termination criterion was specified for the group. Sender side: The group is also known to be complete, and MUST be terminated and state is removed. Subcase t3.2: The group was not complete on receiver side. In this case, the group is not yet terminated. Indeed, an "end" status only tells that "no greater seq number will ever be received after", but late messages may still arrive for this group. Sender and Receiver Side: Then the Receiver RMP and Sender RMP MUST apply termination rules of (t1) or (t2), depending which one of GroupExpiryTime or GroupMaxIdleDuration was specified x.z.4 Termination (t4): ----------------
Triggering event: the RMP receives a status="end" message. The group had neither GroupExpiryTime nor GroupMaxIdleDuration specified. Subcase t4.1: The group was complete on receiver side. Receiver side: The group MUST be terminated. The time of removal of its state is determined by the max(ExpiryTime) received of the Group. Sender side: The group is also known to be complete, and MUST be terminated and the group state removed. Subcase t4.2: The group was not complete on receiver side. Receiver side: In this subcase, the RMP should keep the group processing active: this event, by itself, does not cause the termination of the group. The group can terminate in two ways: a) When the group becomes complete, or b) When the max(ExpiryTime) received of the Group is reached. In either case a) or b), the time of group state removal is based on the max(ExpiryTime) received of the group. Sender side: The group is terminated either when: a) all the messages in the group are acknowledged, or b) the expiry time of all the messages sent passes. When the expiry time of all messages sent passes, the sender group state is removed. x.z.5 Termination (t5): ----------------
Triggering event: In an ordered group, a message expires before delivery: Either the message expires in an out-of-order sequence on the Receiver side, or a non-acknowledged message expires on the Sender side. Receiving side: Triggering event for Termination: In an ordered group, a buffered message expires before delivery. For state removal: - If the group does not have termination parameter, then it will be removed when the max(ExpiryTime) received of the group passes. - If the group uses GroupExpiryTime, then removal criteria as defined in t1 will apply. - if the group uses GroupMaxIdleDuration, then removal criteria as defined in t2 will apply. Sender Side: Triggering event for Termination: A non-acknowledged message expires on the Sender side. For state removal - If the group does not have termination parameter, then it will be removed when the max(ExpiryTime) sent for the group passes.. - If the group uses GroupExpiryTime, then removal criteria as defined in t1 will apply. - if the group uses GroupMaxIdleDuration, then removal criteria as defined in t2 will apply. --------end of proposal to resolve r52 and r57 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]