Bug 1013459

Summary: Invalid context used when signaling a process instance.
Product: [Retired] JBoss BPMS Platform 6 Reporter: Marek Baluch <mbaluch>
Component: jBPM CoreAssignee: Maciej Swiderski <mswiders>
Status: CLOSED CURRENTRELEASE QA Contact: Marek Baluch <mbaluch>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.0.0   
Target Milestone: ER5   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-06 20:10:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
log
none
Process definition 1
none
Process definition 1 drl
none
Process definition 2 none

Description Marek Baluch 2013-09-30 06:54:40 UTC
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)

Comment 1 Marek Baluch 2013-09-30 06:55:34 UTC
Created attachment 804923 [details]
Process definition 1

Comment 2 Marek Baluch 2013-09-30 06:55:56 UTC
Created attachment 804924 [details]
Process definition 1 drl

Comment 3 Marek Baluch 2013-09-30 06:56:18 UTC
Created attachment 804925 [details]
Process definition 2

Comment 4 Maciej Swiderski 2013-09-30 13:07:40 UTC
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

Comment 5 Marek Baluch 2013-09-30 13:26:29 UTC
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.

Comment 6 Maciej Swiderski 2013-09-30 14:02:20 UTC
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.

Comment 9 Marek Baluch 2013-09-30 14:17:35 UTC
Maciej yes I agree with that. Extending the catch clause would a nice and fast fix. Thanks.

Comment 11 Marek Baluch 2013-12-04 07:26:27 UTC
Verified on ER5.