[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]