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: Re: [wsrm] Proposed resolution for Rel 50


 Good that you have started the discussion on this topic.
 I was also planning to send a mail just before I saw yours.
 So instead I'm replying to your email.

 Let me express my concern and Oracle's position on this.

 Unlike Bob's suggestion, we do want ExpiryTime for the
 reasons you have mentioned too, i.e., for persistence
 primarily and for DuplicateElimination as a fallout.

 However, we wanted the semantics of ExpiryTime be
 what it means, i.e., this message will expire after this

 Just to recap, we have 3 options as Jacques stated on the call.
 1) ExpiryTime will have the same semantics of TTL in
     our previous version.
 2) His current proposal on Rel 50 dated  Fri, 7 Nov 2003 19:20:08 -0800
 3) No ExpiryTime at all.

 So, our preference is (1) and I see some discrepancy in the  usage of it
 in different current proposals. Mainly, I see 2 inconsistencies:

 1) The semantics of ExpiryTime in overloaded.
     In Rel 50, we are saying that ExpiryTime is nothing but
     RejectMeIfYouReceiveMeAfterThisTime, i.e., this is to
     reject it it was delayed at the transport layer and nothing
     to do with it's life span once received.

     However, in Rel 52, for the termination conditions t2 and t4,
     we are using max of ExpiryTime of individual messages  to figure out
     the GroupExpiryTime if the latter is not present. So here we are using the
     real semantics of ExpiryTime and not RejectMeIfYouReceiveMeAfterThisTime.
     If it is for only to check the transport lag only, why are we using here then?

     This is my primary concern.

 2) DuplicateElimination in Singleton/Group-Unordered is different
     than DuplicateElimination in a Group-Ordered case.

     Here is the example:
     Say you are in Group-Unordered case.

     Msg1 with  Group Id 1 and Seq No 0 is sent at 12 noon with Msg ExpiryTime
     at 4.00 pm and GroupExpiryTime at 10.00 pm.
     Msg2 with  Group Id 1 and Seq No 1 is sent at 12.01 noon with Msg ExpiryTime
     at 8.00 pm and GroupExpiryTime at 10.00 pm.
     Msg3 with  Group Id 1 and Seq No 2 is sent at 12.02 noon with Msg ExpiryTime
     at 4.00 pm and GroupExpiryTime at 10.00 pm.

     Assume the Msg3 was received at 1.00 pm and Msg 2 was not received. Since
     this is a Group-UnOrdered case, the Msg will be acked, persisted and made
     available to the user.

     At 4.01 pm, the Msg3  is removed from the persistence store.

     Assume somehow the Receiver receives the same message (Msg3) at 5.00 pm
     with a different ExpiryTime say 6.00 pm. Obviously this won't be discarded, rather
     accepted. [Note that we had Rel 38 that says Tiemstamps have to be the
     same during retries -First of all, Timestamp is gone, and secondly, we don't say any
     thing about ExpiryTime during Retries, so Retries can have different ExpiryTimes].

     Similar scenario will apply to Singleton case too.

     Take the same case except that assume it is now ordered.
     When Msg 3 arrives at 1..0 pm, it will be acked, persisted and buffered (at the RMP
     layer itself) since Msg 2 doesn't arrive.

     At 4.01 pm, the Msg3 won't be deleted from the persistence cache as per the new
     proposal (since the GroupExpiryTime is 10.00 pm).

     And when a retried Msg 3 arrives at 5.00 pm with ExpiryTime, it will rejected as
     a duplicate as the previous Msg3 still exists in the persistence cache.

     So essentially there is a difference in behavior of duplicates depending upon whether
     it is Singleton, Group-UnOrdered or Group Ordered.

  These inconsistencies that trouble me.

  So lets take a step back and see what are the issues with the actual TimeToLive semantics.

  1) Periodic checking for Msg expires: As I said on the call, we could solve this by having the
      checks only twice. Once during "acceptance" stage and other during "make it available" stage.

  2) Sender won't know whether a Msg. was really made it available to the User.
      As we agreed at the F2F (on thursday), the way to solve this is by saying that
      Sender will only assume that a msg. was really made it available is when
         i) It's not expired
         ii) It was acked
         iii) For a Group ordered or un-ordered case, the Group is not terminated
         iii) And in a group-ordered case, all preceding messages (the ones with lower seq. nos.)
              are acked.

       Note that just saying getting an ack doesn't always mean that the msg was made
       available as they are cases such as Group being expired, Persistence store failure etc..
       Since we don't have async fault notifications, we either assume rules such as above
       or use Poll for all the reply pattern cases as Tom suggested.
 As I said on the call the new proposal does make implementations simpler, but I'm just
 "little" bit worried about the inconsistencies.


Iwasa wrote:

I like this proposal. I would like to reply some questions raised in thetelecon today, which is "What is the fundamentalfunction for ExpiryTime?". The fundamental function for ExpiryTime, I believe, isto enable receiver check duplicate message(s) even ifit removes old message information. When we don't want to enforce receiver keepall previously received message inforamtion forever,we need ExpiryTime. And it should not be changedwhen the message is re-sent. In this case, receiver have to keep old messageinformation until at least the ExpiryTime.So it is possible to check duplicate when theduplicate message arrived before it's ExpiryTime. And after the ExpiryTime has passed, receivermay remove the message information.In that case, receiver do not have to do duplicatecheck for the message, since receiver just needto send back Fault message to let the senderknow about expiration of the message. That would be a critical reason we need ExpiryTimeas mandatory element, And I see Sunil's concern, which is meaningful for brokensequence use case. Let me clarify the use case thatSunil mentioned. Use case1:    Sender sent four messages with ordered delivery:        GroupId=x.y.z  SequeceNumber=0        GroupId=x.y.z  SequeceNumber=1        GroupId=x.y.z  SequeceNumber=2        GroupId=x.y.z  SequeceNumber=3    Receiver received three messages:        GroupId=x.y.z  SequeceNumber=0        GroupId=x.y.z  SequeceNumber=1        GroupId=x.y.z  SequeceNumber=3    When receiver did not received SeqNum=2 message    forever, receiver have to keep SeqNum=3 message    forever, even if the ExpiryTime is expired,    if the message arrived at receiver by the ExpiryTime. I believe this is Sunil's concern, isn't it? How bout the following resolution: Resolution 1:- Adopt Jacques's proposal for semantics of ExpiryTime as is.- We clarify special error case only for OrderedDelivery like:   In case of one or more message(s) was/were missing in a   sequence, and the next message of the missing message   was expired, the receiver may remove all the following   messages. This resolution doesn't change the semantics of ExpiryTimethat Jacques proposed, but solves problem Sunil raised. I do see problems if we change the sematics of ExpiryTimeitself, since it would be affect to non ordered messages.The use case is: Use case 2:   1. Sender sent one message without ordered delivery,      and the ExpiryTime = 12.00.00   2. Receiver received the message at 11:59:59.       And sent back Ack to the sender.   3. Before the receiver give it to the application,       time was changed to 12.00.01. And receiver       considered it was expired, and removed it.I don't believe this makes sence, and it would behappen when we allow to remove any messagewhich was expired even after the receiver receivedit in time, and sent back Ack. In conclution, I believe resolution1 abovesolves all problems mentioned. Thanks, Iwasa 
----- Original Message -----
Sent: Saturday, November 08, 2003 12:20 PM
Subject: [wsrm] Proposed resolution for Rel 50

Rel 50: Semantics of ExpiryTime:


ExpiryTime indicates the ultimate date after which the receiver RMP will
not accept a message. In order to be accepted by an RMP, a message
must have schema-valid RM headers, and must not have expired.
Only accepted messages are subject to further processing by the RMP.

When receiving a message after its ExpiryTime date, an RMP MUST NOT accept the message.
Once a message has been accepted by the RMP, the fact that the message expires while
being processed by the RMP MUST NOT affect its processing, nor its final availability
status to the receiver application. Such expired messages must still be delivered to
the application, assuming they satisfy other reliability requirements.

Although ExpiryTime will not affect further the processing of accepted messages,
it is useful for an RMP to remember it in order to avoid unnecessary duplicate checks
with future messages, when "at most once" delivery is required.
Given the above definition of ExpiryTime, it is impossible that a received message M
accepted by the RMP, is a duplicate of past messages that are expired at the time M
was accepted.

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