5 Replies Latest reply on Feb 6, 2006 9:01 PM by aguizar

    BPEL while activity implementation

    adrian.andrei

      I noticed, while I was testing a lengthy BPEL process, using a rather generous while loop in term of number of iterations, that the execution stack trace consists in all activities that the BPEL executed so far.

      If my while activity iterates a hundred times, and has an inner activity, called A, the after the 99th iteration the execution stack (seen in an exception trace), consists in all 99th calls of A.

      I think this is not a good idea, since some loops can be quite complex in real life, so the process instance will quickly run out of memory!?

      I am using BPEL extension alpha4. Let me know if you want a stack trace.

      /aa

        • 1. Re: BPEL while activity implementation
          aguizar

          This is a known feature, a consequence of the graph traversal technique used in jBPM derived from the classic chain of responsibility pattern (more details in section 4.4 of the user guide).

          The biggest advantage of this technique is that it deals neatly with multiple transitions going out of a node, or linked activities within a flow structure. It ensures you can backtrack all the way to the activity with multiple outgoing transitions.

          Spawning a thread for each transition is an alternative; unfortunately, it is incompatible with JEE deployments.

          Anyway, a portion of a process that loops hundreds or thousands of times over an activity probably shouldn't be described at the (coarse grained) orchestration level. You'd be better off moving that (fine-grained?) logic to a partner service.

          Can you describe the use case, please?

          • 2. Re: BPEL while activity implementation
            adrian.andrei

            I am not sure that this feature complies with the BPEL specs. I know for sure that it doesn't with the BPML ones. There is not need to keep the stack alive for all activities, just for activites that can be compensated fro instance.

            My use case consists in execution of a sub-process (BPEL) over a possible large number of specific deployments. I wanted to show how one can enjoy the benefits of BPEL (like the compensation) over a large number of deployments. I guess I need to use BPEL just for high-level orchestration logic.

            My posting goal was to see if you intentionally do this, rather then being a by-product of using BPM graph implementation.

            Thanks
            AA



            • 3. Re: BPEL while activity implementation
              aguizar

              BPEL does not mandate any non-functional requirement, so this feature does not violate the spec. BPML? Err... Let's not talk about the dead :-)

              Actually, backtracking is required to implement any graph traversal. Think of the classic maze example taught in computer science courses. To find the exit, you need to be able to "remember" every location you've been before, so that you can walk back and try a different path when you find a dead end.

              The simplest technique to implement backtracking is recursive calls. Business process graphs have light to moderate complexity and are mostly acyclic, so this technique is adequate. Orchestration graphs resemble flow charts, which are highly cyclic. They quickly show the limitations of the simple backtracking technique as in your case.

              Rather than pushing to change the graph implementation at the core of jBPM, with the refactoring that would imply, I will change the while structure so that it does not build on the stack. Can you open another JIRA issue here?

              • 4. Re: BPEL while activity implementation
                adrian.andrei

                Done, http://jira.jboss.com/jira/browse/BPEL-92.

                I used the same approach when I worked on a BPML engine few years ago (graph oriented programming), but the loops (while, until) had inner stacks, so the maximum inner stack size was equal to the number of activities the loop had. Eventually pushed the process instances (BPML allows call) for an eventual compensation!

                It is my favorite programming method, as it allows fast development for quite complex issues. Backtracking, state machines, type 3 grammar parsers, and branch-and-bound are a breeze. But, I noticed over the years that at enterprise level this approach is risky since it requires large stacks - and the data base can be huge, easy run out of memory. Ever since I try to avoid it, and use good old Knuth techniques; also, this method it is incredible difficult to explain (knowledge transfer) to others -- very surprised to notice that.

                I will hit you soon with another suite of issues I found with BPEL implementation, hope you don't mind.

                Regards,
                AA

                • 5. Re: BPEL while activity implementation
                  aguizar

                   

                  I used the same approach when I worked on a BPML engine few years ago (graph oriented programming), but the loops (while, until) had inner stacks, so the maximum inner stack size was equal to the number of activities the loop had. Eventually pushed the process instances (BPML allows call) for an eventual compensation!

                  Exactly! I was thinking of a way to make the call stack return to the loop condition node when it "detected" a token was reentering. Transient variables would do the trick, but the approach you propose seems compelling. I'll try it.

                  Ever since I try to avoid it, and use good old Knuth techniques

                  Blame Tom here ;-)

                  I will hit you soon with another suite of issues I found with BPEL implementation, hope you don't mind

                  Absolutely not :-) On the contrary, thanks for taking the time to report the issues.