Red Hat Bugzilla – Bug 1013459
Invalid context used when signaling a process instance.
Last modified: 2014-08-06 16:10:42 EDT
Created attachment 804922 [details] log Description of problem: I have two process definitions with the same signal ('Continue'). When both are waiting for the signal the EventTypes table looks like: mysql> select * from EventTypes; +------------+------------+ | InstanceId | eventTypes | +------------+------------+ | 1 | Continue | | 2 | Continue | +------------+------------+ When I try to signal either one of these instances then I get a message similar to the following: 'java.lang.RuntimeException: Could not find process BPMN2-ConvergingGateway when restoring process instance 2'. JpaProcessPersistenceContext.getProcessInstancesWaitingForEvent() returns both of these instances but one of them does not belong into the context. Looking at the JPASignalManager class there is an attempt made to capture errors when an invalid ksession is used. In this case the exception will not be caught. How to reproduce: 1) create an instance of both definitions (attached) and make them wait for the signal 2) restore one of the sessions and send the "Continue" signal. - the above error should be present in log (see attached log for full stack)
Created attachment 804923 [details] Process definition 1
Created attachment 804924 [details] Process definition 1 drl
Created attachment 804925 [details] Process definition 2
Marek, could you please attach code that is used for this test? Or point me to take a look at it to make sure we have all in sync. Thanks
Maciej, I used the code in the test-jbpm-session-migration/to_6.x branch. I will attach the whole source as it requires some changes.
Alright, now I see what the actual issue is - so there are different RuntimeManagers/kbases used for signal. And since both use the same same they are both tried to be signaled but then the ksession does not have reference to both process definitions. I believe the best would be to extend the catch clause to catch RuntimeExceptions as well and log it instead of failing on it. So information will be given why it failed but others that are possible to be signaled will be triggered. Marek, if you agree with this then no need to attach source of the test.
I quickly created a reproducer which can be found here: http://git.app.eng.bos.redhat.com/?p=jbossqe/brms.git;a=blob;f=test-jbpm-session-migration/to_6.x/src/test/java/org/jboss/qa/bpms/jbpm/BZ1013459.java;h=1c7609479596a498489fe9bd19133b48533e5953;hb=HEAD Just start the main method.
Maciej yes I agree with that. Extending the catch clause would a nice and fast fix. Thanks.
fixed as described above master: https://github.com/droolsjbpm/jbpm/commit/b239649f8a28dd7707702320312fc9300c5e6a22 6.0.x https://github.com/droolsjbpm/jbpm/commit/64ccfae94f81cbdf3b41cee47aae8023bd977ac6
Verified on ER5.