Proposed resolution for Rel 52

Title: Proposed resolution for Rel 52

Rel 52: (New rules for persistence)(also, related "timing issues") 

-------

Proposal:

Q1: When can a recipient "forget" about a sequence? How long must an out-of-order message 

be stored prior to giving up on ever delivering it to the application?

Answer: see Rel57.

Q2: How do these time windows relate to the TTL (expiration) of an individual message?

Answer: see Rel50: ExpiryTime does not have any impact on the processing of a received message, 

once accepted by the RMP.

Q3: Within what window will a duplicate be detected? 

[Short Answer:] duplicates will be detected over all past non-expired messages. 

Since by definition, messages that are expired when received will be rejected, there is 

no risk ever to deliver two duplicates to the receiver application, as long as the ID of

non-expired messages (or ID intervals in the case of sequences) can be held in persistent store.

[Long answer]: 

General rule for persisting the ID of a message:

---------------------------------------------

The duplicate elimination feature requires persisting the message ID

(GroupId and optionally the Sequence Number), after the message

has been processed and delivered to the application (state: "available").

The general rule about message ID persistence, is that an RMP

MUST persist the ID of a message until the message expires.

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.

NOTE: Duplicate checks would be made over all past messages of the group, whether expired or not. 

There is no added cost here, as these IDs are remembered as sequence number intervals.

The check will in fact be faster, as not discarding means fewer intervals.

General rules for terminating a group, and for removing the state of a group:

-----------------------------------------------------------------

NOTE: these termination rules apply to both ordered and unordered groups.

NOTE: In all termination cases (t1, t2, t3, t4) below, it is not necessary to remember 

the ExpiryTime of all messages of a group, as only the maximum of all ExpiryTime values 

needs to be maintained.

NOTE:Termination of a group, and removal of its state are two distinct events.

- When a group terminates, both in sender and receiver, no message is expected to be

sent or received for this group anymore. If a message is received after the

termination of a group, with same GroupId as the terminated group, it is considered

by the Receiver as belonging to a new group. 

- Removal of the state of a group occurs either at termination time or later. 

It means that all traces of the group (groupId, current sequence number, as well as

all received message IDs for the group as SequenceNumber intervals) are removed, 

and therefore not available anymore for duplicate checks.

Termination (t1): 

Triggering event: GroupExpiryTime is over.

Receiver side: The group is immediately terminated, and its state is removed from the RMP.

No duplicate check is done against that group ever. If a "late duplicate" arrives,

it would be automatically rejected due to its ExpiryTime, always earlier than GroupExpiryTime.

Sender side: The group is immediately terminated, and its state is removed from the RMP.

Termination (t2): 

Triggering event: GroupMaxIdleTime is over.

Receiver side: The group is immediately terminated. But unlike (t1), some of its 

past messages may not be expired yet. The RMP will keep the max of all ExpiryTimes 

of messages received in the group. 

The max(all ExpiryTime) will determine the date at which the state of the group is removed.

Sender side: GroupMaxIdleTime is counted between two sent messages. If it is over,

the group is immediately terminated, and its state is removed from the RMP.  

Termination (t3): 

Triggering event: the RMP receives a status="end" message. The group had either

GroupExpiryTime or GroupMaxIdleTime specified.

Note that this only tells us that "no greater seq number will be received after", 

but that late messages may still arrive for this group. 

Subcase t3.1: The group was complete on receiver side. 

Receiver side: The group is immediately terminated. 

However, its state is removed according to (t1) or (t2), depending which termination

criterion was given.

Sender side: The group is also known to be complete. If either ordered delivery 

or guaranteed delivery was required, all Acks must have been received. 

Then only the group is terminated.

Subcase t3.2: The group was not complete on receiver side. 

Then the receiver RMP and sender RMP MUST apply rules of (t1) or (t2), depending which one 

of GroupExpiryTime or GroupMaxIdleTime was specified.

Termination (t4): 

Triggering event: the RMP receives a status="end" message. The group had neither

GroupExpiryTime nor GroupMaxIdleTime specified.

Subcase t3.1: The group was complete on receiver side. 

Receiver side: The group is immediately terminated. The date of removal of its state 

is based on rules for (t2), using max(ExpiryTime) of all its messages.

Sender side: The group is also known to be complete. If either ordered delivery 

or guaranteed delivery was required, all Acks must have been received. 

Then only the group is terminated and its state removed.

Subcase t3.2: The group was not complete on receiver side. 

The group is immediately terminated, and its state is removed from both RMPs.