OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]