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] Rel16 Ordering and Sequencing


Comments <scott></scott> inline....

> -----Original Message-----
> From: iwasa [mailto:kiwasa@jp.fujitsu.com] 
> Sent: Tuesday, July 29, 2003 5:10 AM
> To: wsrm
> Cc: iwasa; iwasa.kazunori@nifty.ne.jp
> Subject: [wsrm] Rel16 Ordering and Sequencing
> 
> 
> Here is a proposed resolution for Rel16,
> which is my action item at last telecon.
> 
> --
> Issues:
> Description: The behavioral semantics of senders and 
> receivers need to be
> further defined with regard to the tracking of sequence 
> numbers for the
> purpose of detecting duplicate or out of order messages. For 
> example: How
> long should a receiver hold on to out-of-sequence messages in 
> anticipation
> of a missing message?"
> REL-11 proposals address some of the sequencing issue.
> REL-6 and REL-17 deal with persistance issues, but not out of sequence
> messages directly.
> [see original spec]
> --
> 
> Proposed resolution:
> Include the following description to the spec at section 2.4.
> --
> When a sender sends multiple messages with Guranteed message ordering,
> the sender is REQUIRED to include MessageOrder element in the message.
> And all messages to be delivered in order MUST have same GroupID
> and MUST have sequence number as a value of SequenceNumber element
> in order of the message to be delivered to receiver's 
> application. (Please
> refer to section 3.3.2 for SequenceNumber element.)
> 
> When the sender uses Guranteed message ordering,
> the sender MUST use Guaranteed message delivery and Guranteed
> duplicate elimination together. In detail, the sender MUST 
> include both
> AckRequested element and DuplicateElimination element, as well as
> the MessageOrder element for Guranteed message ordering.
> 

<scott>
Why are we requiring an ACK on ordered messages? Let's say I have a logging
application (like log4j) that simply logs all events sent to it. This is not
a critical app so if a message gets lost it is OK. But of the ones that are
successfully received, they should be kept in-order. So, no need to ACK, but
there is a need to order them. What is the behavior in this case of a
missing sequence #? Let's say the receiver receives #0,1,3. The receiver
delivers 0 and 1 to the app and hold #3 for its MET (msg expiration time),
waiting on message #2. If #2 does not show up within that time it delivers 3
and considers 2 to be lost.
</scott>

> A receiver that received messages including MessageOrder element
> MUST provide its application layer with those messages
> in order within the same groupID. In detail, the receiver MUST
> follow the following procedure, when it received messages
> with MessageOrder element:
> 1. Confirm the message is including AckRequested element and
>     DuplicateElimination element as well as MessageOrder element.
>     If there is missing eaither/both of the above two elements,
>     the receiver MUST send back [TBD] Fault message to the sender,
>     waste the message, and terminate this procedure.
> 2. The receiver MUST check if the message is duplicating
>     with any message persisted at receiver.
> 3. The receiver MUST persist the message until PersistentDuration
>     [TBD:This parameter must be defined as a configuration parameter]
>     has expired, if the message is not duplicating.

<scott>
I think the receiver must presist the message for at least the MET. If there
is a (local) "persistance duration" parameter and it wishes to persist
longer, that is implementation specific and should not be part of the wsrm
spec.
</scott>

> 4. The receiver MUST generate and send back an Acknowledgement
>     message to the sender. Note the Acknowledgement message
>     MUST be sent back whether it was duplicated or not.
<scott>
See comment above on not requiring an ACK for ordered delivery.
</scott>
> 5. The receiver MUST remove the message if it was duplicating
>     at #3 above, and terminate this procedure.

<scott>
Not sure what you mean by "terminate this procedure". If you are saying that
processing of messages within the Group is discontinued, I disagree with
that. If  this is not what you mean, this needs to be clarified.
</scott>

> 6. The receiver MUST check the SequenceNumber and GroupId
>     to see whether the message is arrived in order within the GroupId.
>     If the message is arrived in order, the receiver MUST provide the
>     message to the application layer. If the message is not arrived
>     in order, the receiver MUST wait until all previous messages
>     is received by receiver and provided to the application layer
>     in order.
> 
> In addition to the above procedure, the receiver MUST check
> messages persisted and didn't provided to the application layer
> until PersistentDuration is expired. If there are those messages,
> the receiver MUST send back [TBD] fault to sender to notify
> those messages are not delivered to the application, even if
> the Acknowledgement messages were returned before. And
> then the receiver MAY remove those messages.
> --

<scott>
I propose that it follow the semantics of guaranteed delivery, if that is
requested in the wsrm header (through the ACKRequested element), otherwise
it continues on silently. I believe we should have guaranteed delivery
orthogonal to ordered delivery.
</scott>

> 
> Please propose any updates to make the above
> sentences more appropriate.
> Thanks,
> 
> Iwasa
> 
> 
> You may leave a Technical Committee at any time by visiting 
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.ph
p


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