[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: > >> Tom Rutt wrote: >> >> I put the new behaviour for the three examples below, without group >> expiry time > In this one I added a new ordered delivery 4 example. This shows that the group expiry parameter caused behaviour which gets the seconde message delivered. The case 2 example faulted on message 2. However the sender knows that message 2 was not delivered, and can work around that by sending its contents in a true new sequence. Thus I believe we have satisfactory behaviour without using the group timing parmeters with respect to the sender being aware of what is delivered. I think the problems of users determining proper group timing parameters ahead of time are sufficient to not warrant the complexity of adding these parameters to the protocol. Changing the semantics of ack to signal delivery does simplify the matter considerably. > > 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. >> > > New ordered example 4 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 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. at 4:00 message 3 expires, it is not delivered and a fault is sent back to the sender (message expiry without delivery.) > > > message 2 is received at 5:00 PM Message 2 is delivered to the receiving user process, and an ack is sent to the sender. > > Group is terminate at 10:pm – terminate group, removed group state > buffer -- ---------------------------------------------------- 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]