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: Rev "d" of Rel52, 57


Title: Rev "d" of Rel52, 57

Rel52 and Rel57 reworded and adjusted to late comments, (tagged "rev d")
though nothing radical:

- Still makes use of Group termination timeouts:
I  really find it hard to overload message ExpiryTime with group termination
semantics: ExpiryTime is about the delivery cycle for messages, which is orthogonal
to how long a group should be active.

- Agree that ExpiryTime should be set, as Bob suggested, based on expected
transport performance and network monitoring (e.g. round-trip timing) and should
normally be opaque to users.
It is a tuning parameter that says: "normally the delivery cycle (transport + RMPs) for
this message should not exceed this time. If it does, this means that the communication
conditions are too bad for doing reliable messaging.
In that case the RMP will not deliver it, and notify the app instead."

- Unlike ExpiryTime, group termination parameters have an application semantics:
In the same way a reliability QoS associated with a group is based on application needs,
(e.g. ordering), limit on group duration is also based on application profiles:
some apps will be able to mark the last message with "end", some will not.
Among these, some will be able to cap the duration of their groups (GroupExpiryTime),
some will only be able to say what idle time can safely be considered as terminating
a group (GroupMaxIdleTime). Finally, some groups are not supposed to terminate ever...
which is fine as long as an implementation can handle the space overhead (group states)
in case of many of these

- So in Rel52 I still propose the 4 termination cases:
They may not make for a concise spec, but they look very implementable to me:
in all cases, Sender and Receiver can synchronize group termination without
need of notification (thanks partially to the Ack semantics (Rel33)).
To me this is by far the most important enhancement.

Regards,

Jacques
<<Time-Rel57d.txt>> <<Time-Rel52d.txt>>


Rel 57: (revision d) Ordering and Missing Message Behavior
---------------------------------------

Proposal:

[notes from author: 
- We also use GroupMaxIdleTime -if specified- for terminating an out-of-order sequence.
- Discarding out-of-order messages of a group, and more generally terminating a 
group, does not mean yet the removal of the group state, as message IDs may still 
be needed for duplicate checks. See Rel52 for this.
- The term "delivery" below has been precisely defined earlier.]


On the Receiver side, as soon as either:
(1) the earliest ExpiryTime of pending (stored) out-of-order messages has expired, or 
(2) GroupMaxIdleTime has been specified, and has expired,
all the pending and future out-of-order messages MUST NOT be delivered. 
The RMP MUST terminate the out-of-order group as early as convenient after this date, 
and out-of-order messages must be discarded. 

On the Sender side, the RMP MUST terminate an ordered group as early as possible after
one of these events occurs, whichever comes first:
(1) a message for the group has not been acknowledged after all retries have
been exhausted, plus a buffer time (e.g. retryinterval).
(2) a message supposed to be sent or resent, has expired, and therefore will not
be sent. 

NOTE: On the Receiver side, out-of-order messages, although well-received, 
will not be delivered and acknowledged before the sequence is complete, which may 
trigger unncessary resending from the Sender. 
The Sender MAY decide to NOT systematically resend a non-acknowledged message, 
in case a previous message in the group has not yet been acknowledged. 



Rel 52: (revision d)(New rules for state persistence, also, related "timing issues") 
-------


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 (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.

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, message IDs
for groups can be stored efficiently as intervals of integers.

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

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, t5) below, it is not necessary to remember 
the ExpiryTime of all messages of a group, as only the maximum of all ExpiryTime values 
is needed.

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 (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).
- 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 
duplicate checks. State removal may occur either at termination time or later,
depending on the following rules. 


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.


Termination (t2): 
-----------------

Triggering event: GroupMaxIdleTime 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(all 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(all ExpiryTime), 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 GroupMaxIdleTime.


Termination (t3): 
----------------

Triggering event: the RMP receives a status="end" message. The group had either
GroupExpiryTime or GroupMaxIdleTime 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 given.

Sender side: 
The group is also known to be complete, and MUST be terminated. 

Subcase t3.2: The group was not complete on receiver side.
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. 
 
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 t4.1: The group was complete on receiver side. 

Receiver side: 
The group MUST be terminated. The time of removal of its state is based on rules for (t2).

Sender side: 
See subcase t3.1 above.

Subcase t4.2: The group was not complete on receiver side. 
Then the RMP should keep the group active: this event, by itself, does not cause the 
termination of the group. 


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. 

See Rel 57 for this case.


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