[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. > > > 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 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_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]