4 Replies Latest reply on Feb 26, 2008 7:00 AM by Alexander Eitner

    Fork --> Join issues

    Alexander Eitner Newbie

      I have a small problem here:

      Processdefinition contains a situation, where a fork has 3 child-taskNodes and just 2 of them will join again:

      TaskNode A -------> Fork

      Fork --------> TaskNode B
      Fork --------> TaskNode C1
      Fork --------> TaskNode C2

      TaskNode B ---------> EndState

      TaskNode C1 ---------> Join
      TaskNode C2 ---------> Join

      Join ---------> TaskNode D


      Now, when executing this path after the fork, the following procedures WORK:

      B .signal()
      C1 .signal()
      C2. signal()

      or

      C1.signal()
      B.signal()
      C2.signal()

      So as long as B has ended before C1 and C2, everything seems to be ok.

      But if C1 and C2 end before B, then the only open task is Task B. But Task D, which should occur after the JOIN, is missing.

      I check all taskInstances of one certain processInstance with

      TaskMgmtInstance taskMgmt = processInstance.getTaskMgmtInstance();
      Collection<TaskInstance> allTaskInstances = taskMgmt.getTaskInstances();


      Searching the forum results in some posts that say:
      - a JOIN is always coupled with a FORK in some way (i guess its the nearest fork then)
      - a JOIN expects exactly the number of incoming tokens that the fork created

      Is this right? But this behaviour wouldn't explain why it works with ended B, but not otherwise...

      Is there any workaround?

      Btw @Kukeltje: I searched in the CVS for unit-tests, but could you give me a hint where to find them? I checked out "jbpm.3".

      Thx in advance
      alex

      thx in advance


        • 1. Re: Fork --> Join issues
          Ronald van Kuijk Master

           

          Is this right?
          Yes, fork-join have to be fulle nested.... 3 from fork -> 3 to join

          But this behaviour wouldn't explain why it works with ended B, but not otherwise...
          The flow you describe is unsupported and thus the behaviour is undefined. Finding an explanation is (imo) therefor not a high priority.

          The tests are in jbpm.3/jpdl/jar/src/test

          • 2. Re: Fork --> Join issues
            pojomonkey Newbie

             

            "QPool.Char" wrote:
            Is this right? But this behaviour wouldn't explain why it works with ended B, but not otherwise...

            Without delving into the code, it makes sense to me.

            If B has completed, then the associated token will have ended.

            Hence, when the other tokens reach the join, all the tokens are accounted for and the parent token can advance.

            If B is not yet complete, then the parent will end up waiting (indefinitely) for the token as, without any further tokens ending at the join, there is no trigger to release the parent token.
            "QPool.Char" wrote:
            Is there any workaround?

            Perhaps a custom node on one of the fork transitions can generate the task?

            • 3. Re: Fork --> Join issues
              Ronald van Kuijk Master

              I would not go for such 'hacks'.... most of the time these 'issues' can be resolved by looking that the process in a different way........

              • 4. Re: Fork --> Join issues
                Alexander Eitner Newbie

                Thank you both for your quick answers.

                I know understand the behaviour of this situation and would agree with kukeltje. I can make a restriction here for the analyst and ask him to design processes in different ways.