Title: Proposed resolution for Rel 50
I like this proposal.
I would like to reply some questions
raised in the
telecon today, which is "What is the
fundamental
function for ExpiryTime?".
The fundamental function for ExpiryTime, I
believe, is
to enable receiver check duplicate
message(s) even if
it removes old message information.
When we don't want to enforce receiver
keep
all previously received message
inforamtion forever,
we need ExpiryTime. And it should not be
changed
when the message is re-sent.
In this case, receiver have to keep old
message
information until at least the
ExpiryTime.
So it is possible to check duplicate when
the
duplicate message arrived before it's
ExpiryTime.
And after the ExpiryTime has passed,
receiver
may remove the message
information.
In that case, receiver do not have to do
duplicate
check for the message, since receiver just
need
to send back Fault message to let the
sender
know about expiration of the
message.
That would be a critical reason we need
ExpiryTime
as mandatory element,
And I see Sunil's concern, which is
meaningful for broken
sequence use case. Let me clarify the use
case that
Sunil 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 ExpiryTime
that Jacques proposed, but solves problem
Sunil raised.
I do see problems if we change the
sematics of ExpiryTime
itself, 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 be
happen when we allow to remove any
message
which was expired even after the receiver
received
it in time, and sent back
Ack.
In conclution, I believe resolution1
above
solves 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.
