[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Proposed resolution for Rel 50
Iwasa, Good that you have started the discussion on this topic.
Let me express my concern and Oracle's position on this. Unlike Bob's suggestion, we do want ExpiryTime for the
However, we wanted the semantics of ExpiryTime be
Just to recap, we have 3 options as Jacques stated on the call.
So, our preference is (1) and I see some discrepancy in the
usage of it
1) The semantics of ExpiryTime in overloaded.
However, in Rel 52, for the termination conditions
t2 and t4,
This is my primary concern. 2) DuplicateElimination in Singleton/Group-Unordered is different
Here is the example:
Msg1 with Group Id 1 and Seq No 0 is
sent at 12 noon with Msg ExpiryTime
Assume the Msg3 was received at 1.00 pm and
Msg 2 was not received. Since
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
Similar scenario will apply to Singleton case too. Take the same case except that assume it is
now ordered.
At 4.01 pm, the Msg3 won't be deleted from
the persistence cache as per the new
And when a retried Msg 3 arrives at 5.00 pm
with ExpiryTime, it will rejected as
So essentially there is a difference in behavior
of duplicates depending upon whether
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
2) Sender won't know whether a Msg. was really made it available
to the User.
Note that just saying getting an
ack doesn't always mean that the msg was made
-Sunil
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]