Re: [wsrm] Discussion Initiation on Minimal Timiing parameters

[Tom Rutt <tom@coastin.com>]

Tom Rutt wrote:

I put the new behaviour for the three examples below, without group 
expiry time

> 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 

Keeep this for example

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

now -  will make availalable to user then send ack, calculate max expiry 
= 4 pm

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

now - will buffer, and not ack.  Wait for 2 or group expiry.  If 
status=end , know that the group is terminated

>
>
> 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)

message 3 expires , a fault message is returned to sender regarding 
message 3 expiry before delivery.  The group state will be deleted at 
10:pm (max expiry time)

If 2 ever arrives before its expiry time, it will be seen as a new 
group, the message 2 will be buffered,  waiting for 1, but not acked. 

At 8:00 PM the new "group" will be destroyed, and a fault will be send 
re. message 2 (expiry before delivery)

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

same as above, will deliver and then ack message 1, calculate max expiry 
time = 4 pm

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

now- will buffer, and not send ack.  calculate max expiry time = 4 pm.

>
>
> 4pm – group terminated, 3 removed from messageOrder queue, will not be 
> made avalable,  send a fault to sender regarding message 3 exprired  
> before delivery.  Group state removed.
>
> receive 2 – at 6:00 PM – acked and start new sequence. Derived 
> get=8pm, will be buffered waiting for 1 

Now this will be seen as new group, will buffer 2, wating for 1.  Will 
not ack sender.  Max expiry time 8:00 PM

>
>
> 8pm – terminate new sequence, remove 2 from buffer will not be made 
> available to user. Send fault to sender re message 2 expiry before 
> delivery.
>
> Ordered example 2 has the problem that the sender has all three 
> messages acked, however 2 was not made available. 

no longer a problem, proper fault messages will be sent to sender.


I think the above two examples show the same behaviour with the group 
parmeters present, as when they are not present.  The only difference is 
the exact time that the group state is removed and the fault messages 
are sent.

Perhaps we can get along without the group termination parameters.

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