Sunil:
inline
-----Original Message-----
From: Sunil Kunisetty
[mailto:]
Sent: Tuesday, November 11, 2003
5:35 PM
To: Iwasa
Cc: Jacques Durand;
Subject: Re: [wsrm] Proposed resolution
for Rel 50
Iwasa,
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
timestamp.
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.
[Jacques
Durand] no, you misunderstood: in t2, MaxIdleTime decides of the group
termination. The use of max(ExpiryTime) is only for removal of the group state
which was still needed a while for dup elimination. (It happens that for t1,
both events are decided by GroupExpiryTime...). Same for t4, where
max(ExpiryTime) would decide only when to remove the state (only affects dup
elimination). In t4, I propose group termination to be effective as soon as a
message is out of order (though Tom Rutt proposes something less drastic).
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?
[Jacques Durand] no, see above...
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.
[Jacques Durand] you mean its
ID.
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].
[Jacques Durand] well, why would
duplicates have different ExpiryTimes? we normally expect duplicates to be
exactly same, though I agree that the formal definition of duplicates is
just same IDs. If tehre is tampering wiith duplicates, that becomes a
security / integrity issue.
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.
[Jacques
Durand] the only (expected) "app-visible" difference, is as you said that
Msg3 will never be delivered to app, because the group is ordered and M2 has
not arrived before GroupExpiryTime. In all cases, retries of Msg3 would
be considered as duplicates until GroupExpiryTime expires. After that,
they would be rejected. For singletons, as there is no GroupExpiryTime, the
limit of ID persistence is ExpiryTime. In all cases, the contract is
fulfilled: never duplicates would be delivered. (granted, for singletons we
might get rid of Mesg3 state a bit earlier than if in a group, as
GroupExpiryTime is usually equal or later than ExpiryTime. But that
does not affect semantics: just an internal optimization issue for dup
check.)
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
AND
ii) It was acked
AND
iii) For a Group
ordered or un-ordered case, the Group is not terminated
AND
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.
-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
----- Original Message -----
From:
Jacques Durand
To: ''
Sent: Saturday, November 08,
2003 12:20 PM
Subject: [wsrm] Proposed
resolution for Rel 50
Rel 50: Semantics of
ExpiryTime:
-------------------------------
Proposal:
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.
NOTE:
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.
