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:]
> *Sent:* Tuesday, December 13, 2005 6:10 PM
> *To:* Alex Yiu
> *Cc:* Danny van der Rijn;
> ; '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:]
> *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
