9 Replies Latest reply on Aug 7, 2007 3:43 AM by tom.baeyens

    Nested node passivation

    csouillard

      I have problems in the following case :

      flow
      sequence A
      target linkName = B_to_A
      sequence B
      source linkName = B_to_A

      With the following execution :
      I am ready to execute sequence A (execute method was called by pvm) but as there is a link dependency on sequence B, I should not execute sequence A (I have to wait for the source execution). So in execute method I return NodeState.WAITING (maybe wrong)
      Then sequence B is executed ans source is executed. So I need to execute sequence A (wake up this execution)
      I tried to call directly execute method but this doesn't work as this out of the control of the pvm...

      Can you tell me if there is a good way to do that ?
      Maybe I am missing someting...

      I will commit as soon as possible a small example showing that.
      Thanks for your help

      Charles

        • 1. Re: Nested node passivation
          csouillard

          I just commited LinkDependencyTest to illustrate (failing). Feel free to tell me what is wrong.

          Charles

          • 2. Re: Nested node passivation
            tom.baeyens

            are links scoped ? if yes, you should use a class that inherits from ExecutionScope to maintain the link statusses instead of a static test member.

            in that case, you're closer to the real implementation. i don't yet have time to dig into the problem.

            probably i will have time this week to implement a flow example.

            • 3. Re: Nested node passivation
              csouillard

              Links are not yet scoped. But this is not the problem I want to illustrate in LinkDependencyTest. If this test is not executes twice in the same time there would not have any problem with links. The problem is How to wake up the execution sleeping due to the Target statement ?
              This execution was passivated (NodeResult.WAITING). Once the source is executed, I want to wake up this execution so I tried to call signal on it but this causes the following problem :

              org.jbpm.JbpmException: Execution(f_s_b) is locked
              at org.jbpm.pvm.ExecutionImpl.signal(ExecutionImpl.java:199)
              at org.jbpm.pvm.ExecutionImpl.signal(ExecutionImpl.java:194)
              at org.jbpm.pvm.LinkDependencyTest$Source.execute(LinkDependencyTest.java:94)
              at org.jbpm.pvm.ExecutionImpl$ExecuteNode.perform(ExecutionImpl.java:300)
              at org.jbpm.pvm.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:435)
              at org.jbpm.pvm.ExecutionImpl.signal(ExecutionImpl.java:202)
              at org.jbpm.pvm.LinkDependencyTest$Flow.execute(LinkDependencyTest.java:60)
              at org.jbpm.pvm.ExecutionImpl$ExecuteNode.perform(ExecutionImpl.java:300)
              .....

              My question is : what is the correct way o wake up a sleeping execution ? I.e. making the execution executing execute method or signal.

              Thanks
              Charles

              • 4. Re: Nested node passivation
                csouillard

                I think this feature is very important as it allows to well understand PVM.
                In addition this is a blocking issue for me... So maybe I can dig into PVM to understand what is wrong (in my test or in PVM) and find a fix ?

                What do you think ?
                Can you give me a first direction to help me ?

                Charles

                • 5. Re: Nested node passivation
                  csouillard

                  I just found a solution to make the LinkDependencyTest successful.
                  I still have a problem : the only way I found to wake up the execution was to call signal.
                  Is there a way to make the pvm calling once more execute method ? This could be a good feature to avoid duplicating code.

                  Charles

                  • 6. Re: Nested node passivation
                    tom.baeyens

                    here are some rough guidelines

                    Check out the current methods on the Execution and ExecutionController

                    The idea is that NodeBehaviour implementations can/should use the ExecutionController methods.

                    If you call as an external client, then you need to call the Execution methods.

                    If a node behaviour is operating on another execution (not the current running execution) then the node behaviour is also allowed to call the external execution methods (as defined in class Execution) on that other execution.

                    • 7. Re: Nested node passivation
                      tom.baeyens

                      i should be able to have a closer look tomorrow morning. in the meantime. think about how you would make it work and compare it to what is there...

                      • 8. Re: Nested node passivation
                        tom.baeyens

                        charles, i'm deleting your flow test as i'm restructuring all the concurrency tests.

                        keep a copy (or fetch from svn) if you want to re-introduce it later.

                        I want to build up the test suite systematically. One step at a time and get a good coverage over all the techniques that are offered and how they are used for implementing process language features.

                        The flow as you build it doesn't fit in there at the moment. Since it is a sophisticated case of a flow. I want to start with first doing child node execution, then some variations. And maybe in the end arrive in the kind of complex scenarios of like you have build.

                        The test suite i'm building out now is not a POC. I want to go step by step. And include as many variations as i can on basic concepts.

                        In case of your flow, I'm not yet sure wether it belongs in pvm or in bpel codebase. PVM should be for showing all the concepts that process languages need. The process languages themselves will combine all the basic concepts to implement the features. Your test is somewhere in the middle. That is why I want to remove it for now and start from the ground up.

                        • 9. Re: Nested node passivation
                          tom.baeyens

                          also, tests shouldn't really take into account all the edge cases. e.g. you can assume that there will always be nested nodes present.

                          it's up to the process languages to define how they want to handle those edge cases.

                          that makes the tests more readable