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.

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

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.

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

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

@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.