Jacques,
Some comments below:
Jacques Durand wrote:
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
Sure, I understand it is for removal of the group. For my
examples, I was not
distinguishing between the group termination and group removal
case.
My point if it is just used at the time of receive, why is this
parameter ever
used there after, whether it is for removal or termination?
Essentially when
you are trying to compute the group removal life span,
you are using
the max of all message's expiry times. So essentially you are
using the
expiryTime as a message's life span thingy in here, which contradicts
your earlier
usage and assumption.
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.
Correct. ID and any other data associated with that Msg.
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
Not necessarily. Duplicates may or rather must have the same Timestamp,
but not
necessarily the same expiryTime.
For ex., a msg. sent at 12 noon has a expiry time of 4.00 pm.
For some reason,
the Sender never receives an Ack for that msg. inspite of (re)trying
it until 4.00 pm.
So if the Sender has to continue his retries after 4.00 pm, he
obviously has to change
the expiryTime, if not, his retries after 4.00 pm will never
be successful.
is
just same IDs. If tehre is tampering wiith duplicates, that becomes a security
/ integrity
I don't think this classifies as tampering.
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
So are we saying that even for group-unordered cases, all message
IDs of that group
are kept until that group is removed? If so, atleast this problem
will be solved for
the group unordered case (though the issue still persists for
Singleton messages),
but then won't it defeat the whole purpose of group-unordered
optimization it was
suppose to add? Unordered-groups are potentially going to very
very long and it is
not advisable to keep the Message IDs for expired messages.
My main point is what warrants the change when we don't seem to
have any issues
with the old behavior of ExpiryTime (TTL one) as I listed below.
-Sunil
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.
