[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] New proposal for i019 and i1028
I agree with Chris' comments. The concept of "filling" a sequence bothers me as well. It seems to complicate the implementation of an RMD. To pick one example; suppose the RMD has agreed to provide an "*; in-order" DA to the destination application? What should it do when it receives a SequenceFill from the RMS? The only thing I can imagine is that it should terminate the sequence, since there it knows that there is no way it will be able to fulfill its DA (thinking about it, this applies to canceled messages as well). This implies that the RMS should not use SequenceCancel or SequenceFill if it know that the RMD is providing a DA of "*; in-order" for the effected sequence. This gets us back to the sticky problem of the RMS' knowledge of the DA and changing its behavior accordingly. - g > -----Original Message----- > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] > Sent: Wednesday, September 14, 2005 4:52 PM > To: ws-rx@lists.oasis-open.org > Subject: RE: [ws-rx] New proposal for i019 and i1028 > > Stefan, > > Please see my inlined comments. > > Cheers, > > Christopher Ferris > STSM, Emerging e-business Industry Architecture > email: chrisfer@us.ibm.com > blog: http://webpages.charter.net/chrisfer/blog.html > phone: +1 508 377 9295 > > "Stefan Batres" <stefanba@microsoft.com> wrote on 09/14/2005 > 05:03:27 PM: > > > Doug, > > > > Thank you for your careful review of this proposal. I have some > > comments > regarding some of the > > points you make and I?m also including answers to some of > the detailed > questions you?ve made. > > > > I will propose a new issue relating to gaps. > > > > Cancel relates to i019 and i028 to the same degree as Close does > > because > it addresses them in the > > same way; by providing a mechanism that an RMS can use to end a > > sequence > with a final and accurate > > ack set. Attached is an example of how to do this using Cancel. > > Cancel and Close don't address the issues in the same way by > any stretch of the imagination. > For one thing, the Microsoft proposal does not, as far as I > can tell, address the substance of issues i019 and i028 which > address providing the RMS with an accurate final account of > the state as perceived by the RMD following a terminal fault. > > > > > Cancel addresses a superset of the issues addressed by > Close; i019, i028 > and the yet-to-be-named > > issue related to gaps. > > > > I don't expect Cancel to change the protocol at all but > rather to just > add to the protocol. In > > fact, it could plausibly be its own document (I not > advocating for or > against that, I'm just > > making a point). > > If Cancel doesn't change the protocol, then neither does > Doug's Close by > that definition. > > > > > I acknowledge that the amount of sequence state Cancel adds is a > concern. I think the benefits of > > It *should* be a concern. > > > factoring the mechanisms used to end sequences and resolve doubt > independently outweigh these > > Let's be clear. Doug's Close proposal does not end a Sequence. > TerminateSequence is still required > to terminate a Sequence. Furthermore, your proposal doesn't resolve > in-doubt status at all > so far as I understand it. In fact, quite the opposite. It > requires that > the RMS take action > on messages that are explicitly in-doubt to "cancel" them. > I'm not at all > convinced that, from > a practical perspective, it is a sound proposal. > > For instance, what happens to a message that is in-doubt > (there is no ack > for it in the SeqAck) for which > an RMS sends a Cancel, yet the RMD finally receives the > message before > receiving the Cancel? > > > concerns. This clean factoring could potentially allow for > different > levels of support allowing > > for someone to support only sequence termination with a > final accurate > ack set and not incur any > > Your proposal doesn't seem address the final, accurate accounting of > sequence state at all > in the event of a fault that causes one of the endpoints to > prematurely > terminate the sequence, > which is explicitly what i019 and i028 are about. > > > extra state management. I have to say I need to give this > ?different > levels of support? idea some > > further thought since I just thought of this as I read your > comments. > > > > If a new issue is opened and accepted, then, since Cancel addresses > i019, i028 and i0<whatever>, I > > don?t see why we?d need Close as well. > > > > Answers to some of the other detailed questions: > > > > Q: How does an RMD "never accept messages"? > > A: It ignores them. > > > > Q: Is the SeqCancelAck header on all messages that have a > SeqAck header? > > A: No. > > > > Q: What if the SeqCancelAck is lost? Do we need a > CancelAckRequested? > > A: RMS can resend SeqCancel. > > > > Q: How does an RMS know whether a particular message was > filled-in or > cancelled? > > A: The RMS is driving; if it wants to know if a particular > message was > captured or not then it > > should include that message in a SeqCancel before including it in a > SeqFill. > > Too complicated. > > > > > Q: What is the distinction between canceling and gap-filling? > > A: Canceling, by itself, resolves doubt about the transmission of > messages. Gap-filling, by > > itself, fills gaps in the ack set, possibly incurring > doubt. Canceling > followed by gap-filling > > resolves doubt and compacts the sequence state. > > Still doesn't address the scenario I outlined above. Message > is received > before > SeqCancel is received. What is the disposition? > > > > > Q: Does filling a gap remove those messages from future > SeqCancelAck > headers? > > A: Yes. > > Rube Goldberg would be proud:-) > > > > > Thanks again. > > > > --Stefan > > > > From: Doug Davis [mailto:dug@us.ibm.com] > > Sent: Wednesday, September 14, 2005 6:56 AM > > To: ws-rx@lists.oasis-open.org > > Subject: Re: [ws-rx] New proposal for i019 and i1028 > > > > > > Stefan, > > I'm glad that you guys finally see the need for the proposal. I > > must admit though, I don't see how this proposal actually > relates to > > the specified issues. Both issues relate to how an RMS can > get a final > > and accurate accounting of the sequence from the RMD - in one case > > because of a fault and in another because the RMS decides to stop > > using the sequence. This proposal, if viewed as a complete > replacement > > for mine does not address these at all. > > Your proposal focuses more on gap-filling (2 variants of it) and > > neither of these is mentioned in the issues. And as such I > think a new > > issue should be opened and this can be offered up as a potential > > solution for it. Once that is done, I then have some comments and > > questions about it: > > - How does an RMD "never accept messages" that have been > cancelled? > > Does it throw a fault? Ignore them? > > - Does a SeqCancelAck header get carried on all messages > that have a > > SeqAck header? In order for the RMS to get an accurate > view of the > > sequence it would need all of this info each time. > > - If 'no', then are you proposing an CancelAckRequested header as > > well since the SeqCancelAck headers could be lost and > there needs to > > be some way for the RMS to ask for it. > > - The SeqCancel and SeqFill headers are not information - like the > > AckReq and SeqAck headers. As Dan noted in [1] dealing > with these > > headers when piggy-backed on other messages could be > problematic. > > Dan's proposal is that any fault generated by these > headers should > not > > influence the processing of the original message - and > that implies > > that in some cases the fault may be simply dropped. Which is no > > big deal since these headers are mainly informational > anyway. The > > new headers you've introduced are not simply information > though - > they > > are critical to the success resolving doubt. In the > past I said that > > > the Close() in my proposal could be a header - its just a syntax > > difference. You're proposal makes me realize that it > really can't > be. > > The Close(), much like your SeqCancel and SeqFill > headers, are much > > more serious than the informationally piggy-backed > headers we have > > now. And as such they deserve to be treated with more > seriousness. > > - After the RMD receives a SeqFill header how does the RMS > know whether > > > any particular message was 'filled-in' or the message > was just late > > in arriving at the RMD? Does this mean that to fill a > gap, the RMS > > should send a SeqCancel, then wait for a SeqCancelAck, then send > > a SeqFill? Unless the RMS never sent the message, or > doesn't care > > that it go there, I don't see what else it could do. > > - The distinction between Cancelling and Gap-Filling a hole in a > sequence > > seems almost arbitrary and redundant. There is no clear > way for an > > RMS to know which one to use when. > > - As I read it, the distinction between SeqFill and > SeqCancel isn't > clear > > and almost arbitraty. > > - Actually, perhaps you believe that gap-filling is for > cases where the > > > RMS never actually sent the message. And while I don't > dispute this > > might be a valid use-case my initial reaction is that > this should not > > > be something the spec deals with. We've specifically > avoided having > > the spec talk about things outside of what goes on the > wire - things > > like how the DA might influence the protocol - so > following that same > > > logic it doesn't seem right to take into account some processing > > that takes place before the RM logic. If inOrder > processing across > > sequences is out of scope then this feels like it should > be too. But > > > I need to think more about it. > > - You've introduced quite a lot more data for the RMD and RMS to > manage. > > The RMD must now maintain an ACK list and a CancelList - > and both > > must be kept to inform the RMS of the sequence state. > > The RMS must now maintain an ACK list, a CancelList and > a Gap-List - > > and all three must be kept in order for the RMS to have > an accurate > > accounting of what happened to each message. > > And merging/reconciling these lists could be quite > > expensive (remember, we introduced Nacks just because > one list could > > be hard for some impls - imagine what 3 overlapping ones > will do). > > - You claim that the Close proposal introduces another way of > terminating > > a sequence - this is false. Please explain this by > showing me where > in > > the proposal it does this. Terminate does not change at > all. The > > proposal simply allows for the RMS to tell the RMD to > not accept any > > more messages for the sequence - that is very different than > Terminate > > which involved resource reclaimation. > > - There is still no mention of how to know for sure which > Ack received > by > > the RMS is the final one - which is the point of the > Close proposal. > > - Given the only reason for gap-filling in this proposal > is to shrink > the > > SeqAck header, does filling a gap remove it from the > SeqCancelAck? If > > > not, this could also continue to grow. > > - This change means that it is impossible to examine a > SeqAck header > and > > see which messages were delivered, due to gap-filling. > Whilst this > > doesn't break the protocol, it also doesn't help in terms of > debugging > > problems. It doesn't feel right for the SeqAck header > to lie about > > which messages were really received, just so it has less > entries in > it. > > > > Overall, I think this proposal is addressing a very different set > > of issues from the original one proposed - and does so in a > way that > > significantly changes the protocol. I would suggest that > you rework it, > > > as Paul Cotton suggested during one of our previous phone > calls, into a > > form that would allow the TC to see the specific spec > changes you want. > > > I think that will draw out even more questions than what > I've listed > above. > > And, once that happens I think it will be even more obvious > that this is > > > a separate issue from the other proposal so please open a > new issue with > > > the use-cases this proposal addresses so the TC can get a > more complete > > view of what is driving this. And in the end I suspect > you'll find that > > both could be needed and we should proceed with the other > proposal as > is. > > > > thanks, > > -Doug > > > > [1] > http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archi ves/200509/msg00048.html > > > > > > > "Stefan Batres" <stefanba@microsoft.com> wrote on > 09/13/2005 03:49:46 > PM: > > > > > All, > > > > > > After much discussion Doug has managed to make me understand his > reasons for > > > proposing his Close/FinalAck mechanism for addressing > i019 and i028. > We now agree, > > > an accurate acknowledgement state can be helpful in order > to resolve > doubt and in > > > addition, for cases where a sequence must be ended, that > acknowledgement state must > > > be final. These are preconditions for recovery and the > protocol can > aid in > > > establishing these preconditions. > > > > > > However, we still have an issue with the current proposal [1]. We > think it > > > conflates the notions of resolving doubt and closing sequences. > Attached is an > > > alternate proposal that we believe addresses this issue, > allows for > the exact > > > semantics [1] provides and has other advantages. Details > are in the > document. > > > > > > [1] > http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archi ves/200509/msg00084.html > > > > > > > I look forward to the group?s comments. > > > > > > Thanks, > > > > > > --Stefan > > > [attachment "WSRM-Cancel.doc" deleted by Doug Davis/Raleigh/IBM] > [attachment > > "TerminateWithFinalAccurateAck.jpg" deleted by Christopher B > Ferris/Waltham/IBM] > ________________________________________________________________________________ BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld Santa Clara 27-29 Sep| London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]