[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 221 - discussion carried over from Issue 123
I don't believe we should override the fault already bubbling up with missingReply. If the scope doesn't have a fault handler, or the fault handler itself fails, then the fact that we also end up with a missingReply is a consequence of the first problem. assaf Danny van der Rijn wrote: > (Apologies for the stream-of-consciousness reply..) > > I have, indeed, read Satish's mail. It doesn't change my position. > > Yes, if we remove missingReply, the process/scope _instance itself_ > will never know. > > Nothing in this proposal precludes an _engine _from taking action at > _any_ time in regards to cleaning up open IMAs. > > Chris' 7-points mail looks to me like it's throwing the fault to the > parent scope: > If we do that then like any other fault generated by a fault handler > it would be thrown to the parent scope. > But this isn't what you're proposing, is it? > > I'm also not too happy about your fault scenario - F4 validating that > messageExchanges have closed and throwing missingReply if they > haven't. Imagine: > > S1 > FaultHandler > sequence > doSomeCleanup > rethrow > Sequence > receive > doSomethingThatThrowsFault > reply > > when doSomethingThatThrowsFault throws, we go to doSomeCleanup, then > rethrow. Just as FaultHandler is exiting, we now notice that there's > an open IMA. So we override the rethrow and throw a missingReply fault > instead? Pointing out what modelling error, exactly? That the modeller > wasn't quite paranoid enough to do this: > > S2 > catch missingReply > replyToReceive > S1 > FaultHandler > sequence > doSomeCleanup > rethrow > catch missingReply > replyToReceive > Sequence > receive > doSomethingThatThrowsFault > reply > > Which doesn't even manage to rethrow the fault successfully, but at > least manages to escape having S1's possibly expected fault from > interrupting the control flow. Now we've got the fault handling around > an open receive taking more code to write than the actual code. Not a > situation I'd be happy with. > > I think we might be much better off leaving this "modelling error" to > the elephant. > > Danny > > Alex Yiu wrote: > > > Hi Danny, > > I hope you have also read the email that I forwarded from a > Satish's email. > > If you want to remove "missingReply" fault, do you mean the > process/scope instance will never know there is an error at all? > Only the invoker of this faulty process will see the missing reply > or timeout? > > If that is the case, that sounds weired to me. > > BPEL Engine is a container, while BPEL process is an instance > managed by that container. It is a common practice the container > notify the instance or even trigger some corrective action, if the > instance misbehave. (e.g. If a dangling transaction occurs, a > transaction aware container will signal this situation and may > choose to close the transaction (commit or rollback) on behalf of > component.) > > For variant-[A], it is consistent with existing modelling. As > Chris pointed out in his 7-step description, we are merely adding > step (5) to existing model in order to do checkpoint of > missingReply in a scope lifecycle. > > > Thanks! > > > Regards, > Alex Yiu > > > > Danny van der Rijn wrote: > > I would like to point out that currently, there is no > missingReply fault thrown on scope exit. All the spec has is > the requirement that missingReply is thrown if the process > finishes with an open receive. (Which makes no sense. Which is > why issue 221 exists.) > > This entire 123 to 221 discussion is based on a suggestion > that Yaron made (in the 221 thread), that missingReply be > thrown as soon as it is known that there will be no reply. Now > that we are examining it, I'm wondering whether we should just > remove missingReply altogether, as I believe that neither of > the 2 options that Alex described (and thanks for doing that, > Alex) seem to work out in my head - A is completely > inconsistent with other fault behavior, and B is not very useful. > > Danny > > Alex Yiu wrote: > > > Chris, > > Thank you very much for going through my viewpoints in > such a detailed fashion! > > Selling an idea of this multi-facet semantic is never > easy. :-) ... But, I feel that we are converging. > > I also think your 7-step description is a good way to > depict a lifecycle of a scope instance in case of "normal > completion". That is, no fault happens during step (3) to > step (5). > > If a fault happens during step (3) to step (5), the > following steps for fault handling will take place: > > F1 - marks scope as faulted > F2 - matches and selects a fault handler (it can be the > default one) and uninstall other fault handlers and > termination handler > F3 - executes the activity of the selected fault handler > (A fault may be thrown to the parent during this step. If > so, step F4 will not be reached). > F4 - validates that message exchanges have closed (A > missingReply fault may be thrown to the parent during this > step) [ same logic as in step (5) ] > [No source links will be fired after F4. Instead, DPE may > be triggered.] > > F4 is what we are discussing. One thing to point out is: > F4 is needed no matter whether we have step (5) in the > previous 7-step description. [A new open IMA can be > created during the execution of the fault handler.] > > > Thanks! > > > Regards, > Alex Yiu > > > Chris Keller wrote: > > Thanks for the descriptions Alex. I’m not completely > sold, but let me describe in another way what you are > suggesting. Essentially it is declaring that scopes > have the following lifecycle (where all but step 5 is > what we do today): > > 1 - Scope initialization (variables, partnerLinks, etc) > > 2 - Scope schedules event handlers > > 3 - Scope executes Activity > > 4 – Scope waits for event handlers to complete > > 5 – Scope validates that message exchanges have > completed (no outstanding replies for locally declared > partnerLinks or messageExchange receives) > > 6 – Scope completes > > 7 – Scope source links execute… > > We already do wait for event handlers to finish before > the scope completes so checking that partnerLinks are > completed prior to “completing” seems ok. I don’t > think we have a case where a fault handler actually > waits or checks for anything prior to completing but > now we are saying it would execute step 5 (it’s > actually this point that I am not sure about). If we > do that then like any other fault generated by a fault > handler it would be thrown to the parent scope. > > - Chris > > ------------------------------------------------------------------------ > > *From:* Alex Yiu [mailto:alex.yiu@oracle.com] > *Sent:* Tuesday, December 13, 2005 6:10 PM > *To:* Alex Yiu > *Cc:* Danny van der Rijn; > chris.keller@active-endpoints.com; 'Yuzo Fujishima'; > 'ws bpel tc'; Alex Yiu > *Subject:* Re: [wsbpel] Issue 221 - discussion carried > over from Issue 123 > > > Hi, all, > > [discussion carried over from Issue 123] > > Ok ... let me summarize again on where to throw > missingReply fault (to make sure everyone is on the > same page) > > I believe that there are 2 variant of suggestions on > the table: > > *Variant [A]*: (which I am prefering) > It has two checkpoints: > checkpoint [A1]: S2 (at the end of normal execution) => S2 > checkpoint [A2]: S2 (at the end of fault handler) => S1 > > [** A typical fault propagation flow would be: > > * At the end of normal execution, a missingReply > is thrown by S2 to S2. > * Then, a fault handler (including the default > one) will be triggered, if the missingReply > fault is NOT handled (aka default), the fault > will be propagated to S1. ** ] > > > > *Variant [B]*: > It has only one checkpoint. > checkpoint [B1]: S2 (at the end of normal execution or > fault handler) => S1 > (You guys can think of [B1] is the morphed combination > of [A1]+[A2] plus modification.) > > > Concerns I have on Variant [B] are: > > * It seems to me that S2 does not receive any > fault signal in the case of at the end of normal > execution. _What is the state of S2?_ Is S2 > considered normally completed and up for > compensation? Or, is it faulted? > o If S2 is considered normally completed, > that is very strange. A scope with an > open-unfinished receive and a missing > reply should not be considered completed > by itself. > o If S2 is considered faulted, a fault > signal should be sent to S2 first (which > may in turn propagate to S1, as depicted > above). > * Say, if we go for this variant [b]: > o <onEvent> scenario: S2 belongs to an > <onEvent> construct. Now, one of <onEvent> > S2 instances throws this missingReply > fault directly to S1. What can S1 do? > Perform the compensation on S2? But, > remember we can only do group compensation > of all S2 instances? Can someone justify > why previous successfully completed S2 > need to be affected? > > > > Also, you guys can also think of scopes as components > in a business process. Component S1 makes use of > component S2. If component S2 forgot to send a reply > (or make any other system-level mistake e.g. forgot to > close some system resources), it should be S2 > considered at fault or faulted. If S2 can clean up its > own mess, S2 should handle it first. If S2 cannot > handle, then it will be S1's turn to handle it. > > I hope I point out concerns that I have on Variant [B] > more precisely this time. > I also hope Variant [A] seems a better solution to you > guys now. > > > Thanks! > > > > Regards, > Alex Yiu > > > > Alex Yiu wrote: > > > Hi all, > > I am OK with moving this part of discussion to Issue > 221 also, because I also want to pass Issue 123 > resolution in a timely fashion and the decision on > where to throw missingReplying is taking some > discussion time than expected. > > Thanks! > > Regards, > Alex Yiu > > > Danny van der Rijn wrote: > > I agree with Yuzo and Chris. I still think, though, > that we should save this discussion for 221. 123 only > deals with messageExchange, while 221 holds for any of > the 3 values. > > Chris Keller wrote: > > I support Yuzo’s position completely. A missing reply > at the completion of S2 should be thrown to S1. The > fact that we are saying that the missingReply is > thrown is when the partnerLink or messageExchange goes > out of scope says it all. How does it go out of scope, > it goes out of scope because the scope completed. > After completion we can’t come back into ourselves to > catch a fault. All that said I’d rather not have this > delay 123. I’m ok with leaving the text as it stands > in the 123 proposal and solving the question of which > scope catches the fault in issue 221. > > - Chris > > ------------------------------------------------------------------------ > > *From:* Alex Yiu [mailto:alex.yiu@oracle.com] > *Sent:* Monday, December 12, 2005 11:50 PM > *To:* Yuzo Fujishima > *Cc:* Danny van der Rijn; Chris Keller; 'ws bpel tc'; > Alex Yiu > *Subject:* Re: [wsbpel] Issue 123 - Proposal for vote > > > Hi Yuzo, > > Thanks for following this discussion thread. Really > appreicate it ... :-) > > *[a]* > The main motivations behind "S2-to-S2" for > missingReply fault are: > ==> _Finer-grain reply / compensation_ > > * If the fault is thrown to S1 instead of S2, S1 > cannot do anything to fix the missing reply > situation. Because, one of resources > (partnerLink or messageExchange) used in the > open IMA is already out of scope (S2) and S1 has > no access those out-of-scope resources anymore. > * The missingReply situation may be caused by the > situation where some other faults happened and > the enclosed scope (S2) does not handle those > fault properly. (Please see more analysis of > "programming-error-vs-runtime-error" below.) ... > In the <onEvent> or parallel <forEach> > situation, assuming there are 5 instances > created and 4 of them got executed successfully > without any missingReply situation. But, one of > them ran into this missingReply situation. If we > throw the fault to S1 and if we want to every > compensate the work of S2, all 5 of them need to > be compensated. We cannot compensate just the > faulty instance by itself. On the other hand, if > we throw to S2, we can do a partial compensation > in its fault handler. > > > *[b]* > About "Reason 1" : > "programming-error-vs-runtime-error" consideration: > > I agree with you this is more likely a programming > error, not a true runtime error. That is why Dieter > introduced this exit-on-standard-fault facility to > allow people to stop process in case of this > programming error. > > With or without using this exit-on-standard-fault > facility, as a complete specification, we need to > specify snapshot state of the process - i.e., what > scopes are faulted and not, when the "exit" takes place. > > If you think of the <onEvent> example described above, > S1 should not be faulted, when the "exit" happens. > Similarly, the previous 4 instance of "S2" should not > be faulted either. Only the true missingReply scope > should be faulted. > > I also agree with you that people should not rely on > catching this missingReply fault to do any complicated > business logic. At most, people should just log the > fault and attempt doing the partial compensation, as > described above. (This applies to most of standard > fault catchers). > > I am just promoting scope-modularity. Definitely, not > promoting any weired coding style. If you want, I > think we can add a caution statement along the > intention of the passed resolution of Issue 192 > (Dieter's exitOnStandardFault proposal) to spec to > state that: "If people do not set exitOnStandardFault > to true, it is a good practice to restrict logic of > any standard fault fault handler to some minimalistic > repair work (e.g. error logging and partial > compensation)." > > Actually, the same wisdom applies to most of > conventional programming language. E.g. in Java, if > one got an IOException, SQLException, or Security > permission related Exception, there are only few > things that a Java application programmer can do / > should do (similar to above). > > *[c]* > About "Reason 2: When to judge if a reply is missing": > > Yuzo wrote: > > > we should expect a fault handler to send a reply. > > Yes, I totally agree with you here. :-) > > Our intended behavior are actually very similar. :-) > ... I guess the related text in my previous email > writeup is muddled. Sorry for the not-organized enough > text. > > Let me add some clarification and refinement here: > > ================================== > There are two checkpoints to decide whether a > bpws:missingReply fault needs to be thrown in a scope > (S2): > > 1. After the normal execution of the scope (S2) is > finished but before the scope is considered > completed and the fault handlers of the scope > (S2) are uninstalled, if no fault has been > thrown to the scope (S2) during the normal > execution. > 2. After the execution of a fault handler of the > scope (S2) is finished, if a fault has been > thrown to scope (S2) during the normal execution > of the scope (S2), and that fault triggers the > fault handler of the scope (S2), and no fault > has been thrown by execution of the fault handler > > The bpws:missingReply fault thrown by missingReply > checkpoint logic in the case #1 will be caught by a > fault handler at the scope (S2) which matches > bpws:missingReply fault, if there is one. > > If the triggered fault handler (either by > bpws:missingReply fault or other kinds of fault) does > not generate proper replies to any open IMAs, a > missingReply fault MUST be thrown. This is the case #2 > checkpoint logic. > > Important Notes: > > * In case #2, there is NO an infinite loop > situation, because any faults triggered or > thrown by a fault handler (e.g. <rethrow> > activity) will NOT be caught by any fault > handler of the same scope (S2) and they can only > be caught by its ancestor scopes (e.g. S1). > * If a fault is thrown either during the normal > execution of the scope (S2), checkpoint logic of > case #1 will not be executed. That implies, if > such a fault happens and the scope (S2) does not > have a matching fault handler, this fault will > be propagated to the parent scope (S1) and it > will overshadow overall missingReply logic. > * If a fault is thrown or rethrown during the > execution of a fault handler of the scope (S2), > checkpoint logic of case #2 will not be > executed. That implies, if such a fault happens, > this fault will overshadow missingReply logic of > case #2. > > > Here is a fragment of process definition that > illustrates the relationship of scope S1 and S2 > described above: > ------------------ > <scope name="S1"> > ... > <scope name="S2"> > ... > <partnerLinks> > <partnerLink name="pl1" ... /> > </partnerLinks> > ... > <sequence> > <receive partnerLink="pl1" ... /> > <!-- receive without reply --> > </sequence> > </scope> > ... > </scope> > ------------------ > > Note: The bpws:missingReply fault is thrown by scope > S2 to scope S2 itself. > > ================================== > [I highlighted the clarification changes in *GREEN*.] > > > To summarsize, we agree more than disagree. :-) .... > > Case #2 is where the fault is thrown by S2 to S1. > I am merely adding one more differentiated checkpoint > (case #1) to allow the fault thrown by S2 to S2 to > achieve the semantics of scope-modularity and > finer-grain repair and compensation. (IMHO, that is > very important for <onEvent> cases). > > I hope I have explain my intended behavior better this > time. :-) > More thoughts on this topic ... ? :-) > > > Thanks! > > > Regards, > Alex Yiu > > > > Yuzo Fujishima wrote: > > Alex, > > Alex Yiu wrote: > > > > Hi Danny and Chris, > > Please see inline. > > ... > > > *Q1*: /have the process' faultHandlers been uninstalled?/ > Answer: As I mentioned in the my previous email: > (please see the example) > http://lists.oasis-open.org/archives/wsbpel/200512/msg00050.html > > I prefer the direction of which: the fault is thrown > by scope S2 to scope S2. > > > I am not a big fan of this "S2 to S2" semantics for > the following reasons: > > Reason 1: Credibility of the use case. > > I am not convinced that there are (many) cases where > scope S2 fails to reply without throwing a fault (except > missingReply). If S2 does, it should be a programming > error rather than a runtime error. > > More likely are, in my opinion, the cases where > scope S2 fails to reply due to some fault. > > For such cases, > S2 should define a fault handler to catch the fault and > send a reply there. > > Not catching the cause fault and instead waiting for the > missingReply to occur doesn't seem to be a good > programming > practice. The language should not promote that. > > Reason 2: When to judge if a reply is missing. > > A missingReply should be thrown only after the whole > execution > of the scope S2, including the fault handlers, completed > without sending a reply. (As explained in the example > for Reason 1, > we should expect a fault handler to send a reply.) > Then the natural destination of the missingReply fault > should be > the parent of S2, i.e., S1. > > Yuzo Fujishima > NEC Corporation > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
begin:vcard fn:Assaf Arkin n:Arkin;Assaf org:Intalio adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065 email;internet:arkin@intalio.com title:Chief Architect tel;work:(650) 596-1800 x-mozilla-html:TRUE url:http://www.intalio.com version:2.1 end:vcard
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]