Description of problem: We are using the 6.0.1. parent process calls a child process, which in turn calls another child process ( A -> B -> C). the parent process A does no move to next step, child Process (B) shows it is active and in wait state of calling process C. But when we check the status of process C, it was invoked by process B and it is showing as completed. Event-though the sub process C is completed successfully, C's parent process B did not get notification of child process completion. Now B is stuck there, in turn it is not returning the control back to B's parent process A. Please have a look on this post for this problem https://community.jboss.org/thread/243188 Version-Release number of selected component (if applicable): jbpm : jbpm-6.0.1.Final-installer-full.zip jdk : 1.7 database : mysql Running jbpm through jbpm-console How reproducible: added the all demo files and configuration info how it's running on jbpm environment. In attachment, there is README.txt file please go through to reproduce the issue. Steps to Reproduce: 1. please use the attach files. Actual results: once sub-process completed parent process should move forward. Expected results: once sub-process completed parent process is not moving forward and when we see the process in process instance it shows as active and does not get completed. Additional info: Please have a look on this post https://community.jboss.org/thread/243188
Created attachment 925394 [details] Supporting bpmn2 and configuration files
Created attachment 925395 [details] Supporting bpmn2 and configuration files
Please let me know if you need any information from my side Waiting for the response Thanks, Pankaj
fix applied on master (will be 6.2 community and 6.1 product). Was caused by too early flush triggered by task clean up listener jbpm master: https://github.com/droolsjbpm/jbpm/commit/0b160c04a592c8f205185aa57b6dd9a90d93ea0e
additional commit to be included for this BZ jbpm master: https://github.com/droolsjbpm/jbpm/commit/0d018a7f871b6e4bd8a5c0263f570b3b4b481ce3
I have tested this, but the reproducer test fails: https://gitlab.mw.lab.eng.bos.redhat.com/bxms/brms/commit/8f76a0aaac85dcda8f1372b2c00ddd329c876684 I have noticed that the DR3 was built on 2014-09-05 (tag sync-6.2.x-2014.09.05), but the second commit for this bugzilla was added on 2014-09-16. So I am setting back to MODIFIED and will re-test with the next build.
*** Bug 1165466 has been marked as a duplicate of this bug. ***
Hi Tomas, Could you add the test of BZ1165466 (https://bugzilla.redhat.com/show_bug.cgi?id=1165466#c0) to this BZ1128377 test? BZ1165466 is fixed by the same commit of this BZ1128377 but the reproduce scenario is different. So testing both scenarios (BZ1128377 = subprocess scenario, BZ1165466 = signal scenario) would be more robust. Please let me know if you want additional info to test BZ1165466. Thanks! Toshiya
Toshiya, thank you for pointing that out. I have rewritten the test for subprocess scenario and added tests for signal scenario which use different strategies. https://gitlab.mw.lab.eng.bos.redhat.com/bxms/brms/commit/b73892836eb33ba3ce9b45228d78851ce291f880 Verified on BPMS 6.1.0 ER2
*** Bug 1177736 has been marked as a duplicate of this bug. ***
Rajesh, This bugzilla tracks the fix in BPM Suite 6.1.0.ER2. Bugzilla for the same issue tracking the fix in rollup patch #2 is here: https://bugzilla.redhat.com/show_bug.cgi?id=1175897 Therefore removing the bpms‑rollup‑2‑6.0.x flag.