OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrm] Proposed resolution for Rel 50


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 -----
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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]