Re: [wsrm] Rel 33: some thoughts and proposal...

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

 Peter,

"Furniss, Peter" wrote:

> Replying to one of Sunil's original points as well as later ones (rather
> than split the thread)
>
> > -----Original Message-----
> > From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
> > Sent: 19 November 2003 23:40
> > To: tom@coastin.com
> > Cc: Furniss, Peter; wsrm@lists.oasis-open.org
> > Subject: Re: [wsrm] Rel 33: some thoughts and proposal...
> >
> >
> >
> >
> > Tom Rutt wrote:
> >
> > > Sunil Kunisetty wrote:
> > >
> > > >
> > > >  Peter,
> > > >
> > > >  We are indeed referring to  RM Ack and not Application/Business
> > > > App. We discussed this  in the Oracle F2F and we
> > definitely said the
> > > > latter is outside our realm.  The current proposal
> > > >  for REL 33 is more like a transport Ack and Jacques and I are
> > > > suggesting to make it more like  a RM Ack. So seems like you are
> > > > in agreement with us and
> > your only
> > > > concern is the usage
> > > > of words.
> > > >
> > > >  Before I list the choices, I just want to re-emphasize that this
> > > > (correct usage of words)  issue is  sort of orthogonal as
> > we use the
> > > > same phrase in defining the Ordering semantics also.
>
> So I understood - but one of my points (perhaps obscured) was that the
> use of the phrase in defining the ordering semantics implies only an
> ordering of (delivery) events with respect to each other, but does not
> of itself imply when those deliveries occur relative to the
> communication from the sender. The ordering requirement correctly allows
> that the RMP receipt of the sequence and the delivery occur at
> completely separate times.

 Sure. My point was we are using the same phrase with the same semantics
 in Message Ordering case also. We currently say that in an Ordered sequence
 case a message is "made available to the user/application" if all the previous
 messages in that sequence are received and Acked.

 And hence I'm re-iterating that this particular issue (usage of words) is not
 specifically tied to Expiry time or REL 50. That doesn't mean that I'm not
 suggesting that it shouldn't be changed.

>
>
> > > I think the major differerance that I see is that with the
> > "ack when
> > > made availalble" proposal will result in a message N in an ordered
> > > delivery sequence not being acked until after all messages with
> > > sequence number < N are acked.  Since the sender will
> > understand the
> > > semantics, this will give the correct amount of information to let
> > > them know when they can flush the message from their own retention
> > > mechanisms to guarantee reliability.
> >
> >  Yes, that's correct. And this was the argument I made at the
> > Redwood Shores  F2F when we initially agreed on this semantics.
>
> I don't see how the true sentences in Tom's message link up. For any
> message, the sender
> can flush the message on receipt of the ack - the only requirement on

 Not entirely true. The way REL 52 and 57 are coined, we still need
 to keep the message metadata information (if not the whole message)
 for Acked messages as we are using individual MaxIdleTimes/MsgExpiryTimes
 (max of the individual ones) to compute the Group termination/removal
 conditions. Note that we need this both on the Sender and Receiver side.

 While the new proposal doesn't totally get rid of the problem, it just simplifies it.

> the receiver is that
> it doesn't send the ack until either it has delivered the message or has
> it safe such

 sure. I guess we are all speaking in one voice then. The new proposal
 is more aligned to what you are suggesting here. In the old case,
 a msg. was Acked even when it not ready to be delivered.

>
> that it will be able to deliver the messsage (if other conditions on
> order and expiry
> mean it is still valid)
>
> A complication with "ack when made available" means that the sender has
> got to guess
> whether the non-arrival of an ack means that the message hasn't been
> safely received
> (and so should be resent) or it is a later message that hasn't been
> received.

 Well this is an Issue which is easily solved by keeping tracking of
 Acks for all previously sent messages in that sequence, which he
 has ought to do it anyway.

>
>
> The thing about words was about trying to find a weasel wording that
> could be used by
> an RMP that stores all the messages for later delivery and by making
> counter-intuitive
> statements as to who the user/next-level was could do the reasonable
> thing but still fit
> within the "ack when made available" statement. It would have to say
> that "deliver to the
> user", for the purposes of this requirement, meant "write to saved
> queue" and was distinct
> from the operation of "deliver to the user" which occurred when stuff
> was taken off the
> queue.  But when it was talking about ordering, and probably about
> expiry, "deliver to the user"
> meant taking stuff off the queue.
>
> I don't believe you can use the same phrase for the ordering requirement
> and the ack point
>

 So what would be your proposal & suggestion  then?

>
> Peter
>
> ------------------------------------------
> Peter Furniss
> Chief Scientist, Choreology Ltd
>
>    Cohesions 1.0 (TM)
>    Business transaction management software for application coordination
>
> web: http://www.choreology.com
> email:  peter.furniss@choreology.com
> phone:  +44 870 739 0066  <-- new, from 4 August 2003
> mobile: +44 7951 536168
>
> > > I think that this will go a long way to achieving the
> > requirements for
> > > reliable messaging.
> >
> >  I believe so.
> >
> > >
> > >
> > > Tom Rutt
> > >
> > > Tom Rutt
> > >
> > > >
> > > >
> > > >  So let me list the choice of words:
> > > >    1) "make it available to the application/user".
> > > >    2) "make it available to the next layer".
> > > >    3) "RMP passing responsibility for the message to the user"
> > > >       [I copied this from the Tom's meeting minutes as
> > Pete W. saying so]
> > > >    4) "Transferring the responsibility to the next layer".
> > > >       [i vaguely recollect someone saying it in the call.]
> > > >
> > > >  Does any one have any other suggestions? In the above list, I
> > > > prefer option 2 with a comment  that the next layer could be the
> > > > application user itself.
>
> > > >  Thoughts?
> > > >
> > > >  -Sunil
> > > >
> > > > "Furniss, Peter" wrote:
> > > >
> > > >>  I'll try and state what was worrying me about this on the call
> > > >> last night:Although the concept "make available to the
> > > >> application/user" can usefully be used to specify the
> > meaning of a
> > > >> sequence, that doesn't imply that it will necessarily happen
> > > >> synchronously to the communication. Perhaps best explained by
> > > >> scenario:an RM receiver receives incoming work overnight and
> > > >> delivers items when they are asked for by the human-driven
> > > >> application during the day. If messages arrive as part of a
> > > >> sequence, the software will only offer them to the user in the
> > > >> right order. It therefore fulfils the sequence requirement of
> > > >> making them available in order, but the time of making
> > available is
> > > >> invariably while the RMP is out of communication with the
> > > >> sender.Now you can try and get round that by claiming that the
> > > >> storage of the message in the queue in circumstances that would
> > > >> permit its later delivery (i.e. all prior msgs received) is the
> > > >> point of "making it available to the user", but that is
> > distinctly
> > > >> artificial and confusing. If you don't bend the rules like that,
> > > >> then the proposed change would mean that *none* of the messages
> > > >> received during any connection session (even if they
> > weren't part of
> > > >> sequences) could be ack'ed until the next night.But the
> > phrase used
> > > >> often last night was that the ack should be sent when
> > the receiver
> > > >> can assure the sender that the receiver now has
> > responsibility for
> > > >> the message, and the sender is absolved of its
> > responsibility. But
> > > >> that can occur on a message-by-message basis and has
> > nothing to do
> > > >> with whether the message is yet delivered or deliverable to the
> > > >> user. Actually, I think the fix to the original problem
> > here is to
> > > >> understand Ack correctly at the sender side - it's just
> > a RM ack, and
> > > >> means the responsibility has been transferred. There is the
> > > >> possibility of another acknowlegement - the message has been
> > > >> delivered, but that's at a higher level - and may itself
> > be sent back
> > > >> queued.
> > > >>
> > > >> Peter
> > > >>
> > > >> ------------------------------------------
> > > >> Peter Furniss
> > > >> Chief Scientist, Choreology Ltd
> > > >>
> > > >>    Cohesions 1.0 (TM)
> > > >>    Business transaction management software for application
> > > >> coordination
> > > >>
> > > >> web: http://www.choreology.com <http://www.choreology.com/>
> > > >> email:  peter.furniss@choreology.com
> > > >> phone:  +44 870 739 0066  <-- new, from 4 August 2003
> > > >> mobile: +44 7951 536168
> > > >>
> > > >>     -----Original Message-----
> > > >>     *From:* Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
> > > >>     *Sent:* 18 November 2003 22:10
> > > >>     *To:* 'wsrm@lists.oasis-open.org'
> > > >>     *Subject:* [wsrm] Rel 33: some thoughts and proposal...
> > > >>
> > > >>     All:
> > > >>     Sorry for a late notification, but here is a
> > proposal for Rel 33
> > > >>     where a change in
> > > >>     the current semantics for Acknowledgements is proposed.
> > > >>     This is in the light of other issues that we are currently
> > > >>     trying to solve these days.
> > > >>
> > > >>     We would appreciate having at least the opportunity
> > to present it
> > > >>     to the TC at this meeting, if enough time...
> > > >>     Again, apologies for late notice but that is  a very recent
> > > >>     conclusion of ours,
> > > >>     and we'd like at least to get early feedback if possible.
> > > >>
> > > >>     Jacques
> > > >>
> > -----------------------------------------------------------------
> > > >>     We'd like to propose a change in the semantics of sending an
> > > >>     Acknowledgment.
> > > >>     Instead of sending the Ack when the message is
> > received, the Ack.
> > > >>     would be sent
> > > >>     when the message is made available to the server-side
> > > >>     application/user.
> > > >>     After some discussion related to
> > faults/notifications, we believe
> > > >>     this would help
> > > >>     significantly to get both Sender/Receiver aligned,
> > > >>     and also reduce the need for additional faults and
> > notifications,
> > > >>     always problematic
> > > >>     (e.g. if polling needed).
> > > >>     The advantages we see with the new proposal are:
> > > >>     - More consistent semantically because the message is made
> > > >>     available to
> > > >>     the user once acked, no more when buffered.
> > > >>     - Solves the async. failure notification problems.
> > > >>     - Makes Rel 50, Rel 52, and Rel 57 simpler.
> > > >>     - the main difference is for ordered groups, for pending
> > > >>     out-of-order sequence.
> > > >>     - all semantics of RM features (guaranteed delivery,
> > dup elim,
> > > >>     ordering) would now be
> > > >>     about conditions of delivery to application.
> > > >>     We have considered cases where Acks of received
> > messages would be
> > > >>     delayed
> > > >>     due to out-of-order sequences (not made available to
> > app yet).
> > > >>     To jot some memories back, this was decision we made
> > at the first
> > > >>     F2F
> > > >>     at Redwood Shores and was reverted back later as it
> > may have payload
> > > >>     affect during retries. We believe this is a
> > performance issue and
> > > >>     a trade-off on a functional behavior for a performance one.
> > > >>     Performance can be handled without problem (see below)
> > > >>     -------- detail:
> > > >>     For implementations that are concerned about
> > performance hit, an
> > > >>     optimization
> > > >>     they could use is to only retry the lowest un-acked
> > message in a
> > > >>     grouped
> > > >>     ordered case, i.e., if msgs. 1,2,3 are sent and Sender hasn't
> > > >>     received
> > > >>     acks. for 2 and 3, the Sender should not retry 3
> > until they get
> > > >>     an ack. for 2.
> > > >>     For RMP impl. that doesn't worry about retries throttling the
> > > >>     Receiver,
> > > >>     they might still send parallel retries. Either approach won't
> > > >>     have any effect
> > > >>     on the end user behavior.
> > > >>
> > >
> > > --
> > > ----------------------------------------------------
> > > Tom Rutt                email: tom@coastin.com;
> > trutt@fsw.fujitsu.com
> > > Tel: +1 732 801 5744          Fax: +1 732 774 5133
> > >
> > > To unsubscribe from this mailing list (and be removed from
> > the roster
> > > of the OASIS TC), go to
> > >
> > http://www.oasis->
> open.org/apps/org/workgroup/wsrm/members/leave_workgr
> > > oup.php.
> >
> >
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.