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: Discussion Initiation on Minimal Timiing parameters


The proposal from Jacques for Rel 52 includes the following:

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 application, 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: Except for an ordered group that is out-of-order (see 
this case in Rel52), 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 immediately terminated, and its state is 
removed from the RMP when either (1) the time elapsed since the last 
sent message (including retries) exceeds GroupMaxIdleTime, or (2) for an 
ordered group, a message has failed to be successfullydelivered (as 
described in Rel 57), whichever occurs first.

Termination (t3):

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

Note that such an event only tells that "no greater seq number will ever 
be received after", but late messages may still arrive for this group.

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.

However, if guaranteed delivery was required, all sent messages must 
either have been acknowledged, or been faulted, before termination.

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 oneof 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 date 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.

This event, by itself, does not cause the termination of the group.


Now lets try for argument sake to simplify, and assume all we have is 
t4. Would this work for the ordered examples from our last face to face 
meeting?

(please give your analysis of the following examples to any proposed 
solution to simplifying the four termination cases above.)

Ordered example 1

group expiry 10pm

1 – exp4pm (start) sent at 0 pm

2 – exp8pm (continue) sent at 0 pm

3 – exp 4pm (end) sent at 0 pm

receive 1 - at 1pm ack and made avialble to user

recieve 3 – 1.05 pm then ack and buffered (not made available yet, 
waiting for 2 until group persistence removed due to termination 
conditions firing, do not terminate at 4Pm

2 is never received.

Group is terminate at 10:pm – terminate group, removed 3 from group 
persistence buffer (i.e, will not be made available to user)

Ordered example 2

without GroupExpiryTime and without GroupIdleInterval

1 – exp4pm (start) sent at 0 pm –

2 – exp8pm (continue) sent at 0 pm –

3 – exp 4pm (end) sent at 0 pm

receive 1 - at 1pm ack, derived get=4pm then make avialable to user -

recieve 3 – 1.05 pm then ack – derived get=4pm, and buffered (not made 
available yet, waiting for 2

4pm – group terminated, 3 removed from messageOrder queue, will not be 
made avalable

receive 2 – at 6:00 PM – acked and start new sequence. Derived get=8pm, 
will be buffered waiting for 1

8pm – terminate new sequence, remove 2 from buffer will not be made 
available to user.

Ordered example 2 has the problem that the sender has all three messages 
acked, however 2 was not made available.

Ordered example 3

GroupExpiryTime 8:00pm

1 – exp4pm (start) sent at 0 pm –

2 – exp8pm (continue) sent at 0 pm –

3 – exp 4pm (end) sent at 0 pm

receive 1 - at 1pm ack, derived get=4pm then make avialable to user -

recieve 3 – 1.05 pm then ack – derived get=4pm, and buffered (not made 
available yet, waiting for 2

8pm – group terminated, 3 removed from messageOrder queue, will not be 
made available to use.

8pm – terminate new sequence, remove 2 from buffer will not be made 
available to user.

receive 2 – at 9:00 PM – expired, not acked and do not start new sequence.

-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133





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