[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Discussion Initiation on Minimal Timiing parameters
Tom Rutt wrote: > Tom Rutt wrote: > > I put the new behaviour for the three examples below, without group > expiry time actually I removed the third example from the minutes. What this shows is that the new semantics of ack give the same behaviour whether group parameters are present or not. The only differences in the two examples are when the faults are sent to the sender. > > >> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]