Re: [wsrm] Rel16 Ordering and Sequencing

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

 In the same context, why is it a MUST for an Ordered Message to
 have Duplicate Elimination?

 I believe we have to address this Resolution along with REL {50,51,52,53}.
 All of them are related in some way or other.

 -Sunil


Scott Werden wrote:

> 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
>
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php