8 Replies Latest reply on Jun 12, 2014 11:04 AM by Clay Ferguson

    Problem when searching for active paths (while using "OR" gateway)

    Krzysztof Ziobro Newbie

      Hello I have a problem with one process. Actual process is quite extensive and complicated so I prepared a simple case illustrating the problem (from the business side it may be no sense, but this has only served to show the problem). I suspect that the searching of active paths for the 'join OR gateway' does not work properly.

       

      The situation is as fallows:

      HumanTask with Form2 and HumanTask with Form3 are active - with Reserved state, assigned to the same person. If we complete 'HT with Form2' we get StackOverflowError from checkNodes function from JoinInstance java class. Our investigation shows that the problem occurs when the checkNodes function is triggered for "HT with Form3". In the jbpm6 source, inside checkNodes function there is a comment "special handling for XOR split" and my question is: What is the idea of this special handling? The problem is caused by creating a new map of the visited nodes for this fragment of code...

      jbpm6_join_gateway_problem.png

       

      Wiadomość była edytowana przez: Krzysztof Ziobro

        • 1. Re: Problem when searching for active paths (while using "OR" gateway)
          Clay Ferguson Newbie

          We ran into the same bug and were never able to figure out what "pattern" of gateways cause jBPM to loop up, so what we have done for now is put in the following work-around to detect when the stack is getting ridiculously deep (we just said 30 recursive calls should be a good indicator) and return true form the checkNodes in this pathological case.  This is just a short term workaround until we determine the real fix for the code to make it operate correctly and never be able to go into some sort of circular-reference-style loop.

           

            boolean checkNodes(Set<Long> vistedNodes, Node startAt, Node currentNode, Node lookFor, int level) {

              /* detect abnormally deep call stack and bail with success */

              if (++level > 30) {

              logger.info("******** checkNodes: currentNode: " + currentNode.getName() + " id: " + currentNode.getId());

               return true;
          }

          .... rest of method changes only to pass 'level' into it's recursive calls


          So the above code just increments 'level' every time it calls itself, and bails out from any recursion if the stack gets over 30 calls deep. Source is attached.


          *NOTE: There is similar code in SplitInstance.java, but doesn't look like it is likely to go into infinite/recursion loop like JoinInstance.java definitely does.

          ------------

          To enable this code, run 'mvn install' on the jbpm-flow subproject pom.xml file, to put it in your local maven repository, and then rebuild your project that used jBPM and it will pick up the change from your repository.

          • 2. Re: Problem when searching for active paths (while using "OR" gateway)
            Maciej Swiderski Master

            special handling is to cover process loops on various levels but might be there is an invalid handling of some of the cases. So please file a jira with reproducer that shows the problem, that way we can get it fixed for 6.1.0.Final

             

            HTH

            • 3. Re: Problem when searching for active paths (while using "OR" gateway)
              Maciej Swiderski Master

              I believe the process has incorrect design - from or gateway 1 there are bi directional connection to Form 2 and this is most likely cause of the stack over flow as it goes into infinite loop between these two. Best practice is to separate diverging and converging gateways to it either accept multiple incoming connection or producer multiple outgoing connection but not both at the same time. Anyway, you're able to provide reproducer for this then please do file a jira for it.

              • 4. Re: Problem when searching for active paths (while using "OR" gateway)
                Krzysztof Ziobro Newbie

                Hello Maciej,

                 

                The process doesn't have any bi directional connection. We have our own workflow editor in which outgoing connection from diverging gateway starts with diamond and ends with arrowhead, but this the one direction connection.

                If any human task had two outgoing connection, deploy process in KieBase would be impossible. We are able to depoy this process properly, start instance and receive an error.

                 

                What do you mean by providing reproducer? bpmn2.0 file will be enough?

                • 5. Re: Problem when searching for active paths (while using "OR" gateway)
                  Maciej Swiderski Master

                  Ah ok, it looked like bidirectional sequence flow which was indeed weird.

                   

                  As it comes to reproducer best is to have bpmn2 xml and test case that illustrates where the problem is. Please file jira with these and I'll try to look at it this week so it gets fixed for 6.1

                   

                  HTH

                  • 7. Re: Problem when searching for active paths (while using "OR" gateway)
                    Maciej Swiderski Master

                    fixed on master and 6.1.x branch, if get a chance please give it a try with 6.1.x branch as this is what will become 6.1.0 soon

                    @Clay Ferguson , would great to see if that solves your case as well.

                     

                    With OR gateways, it's quite few scenarios that can be modeled with it and most likely not all are supported and not all will be supported but in case there are some let's try to address them.

                     

                    HTH

                    • 8. Re: Problem when searching for active paths (while using "OR" gateway)
                      Clay Ferguson Newbie

                      @Maciej, thanks for the rapid reply to this issue.  I will try to find time to provide a model that reproduces the problem, hopefully in the next few days.

                       

                      BTW: I don't know what your technical solution was but this 'loop detection' reminds me of a thread-deadlocking code solution I wrote once (and similar situations), and one viable solution to detect a "fatal/endless reentrancy" in a recursive algorithm is to pass in an empty hashmap at the top level of the recursion, and add to the map every time the reentrant/recursive method is called, and then always check it every time also before re-entering the recursive method to see if it's already been called with "identical parameters", because you know identical parameters encountered more than once will indicate infinite recursion is happening.  Maybe there's a better "closed loop detection" type algorithm in Graph Theory, but I don't know if there is.  I know that's not the precise problem here, but it similar enough.

                       

                      Also I will let you know the results of 6.1.x as soon as I have time to try that.