Bug 1013459 - Invalid context used when signaling a process instance.
Invalid context used when signaling a process instance.
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ER5
: 6.0.0
Assigned To: Maciej Swiderski
Marek Baluch
Depends On:
  Show dependency treegraph
Reported: 2013-09-30 02:54 EDT by Marek Baluch
Modified: 2014-08-06 16:10 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:10:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
log (4.17 KB, text/x-log)
2013-09-30 02:54 EDT, Marek Baluch
no flags Details
Process definition 1 (9.09 KB, application/xml)
2013-09-30 02:55 EDT, Marek Baluch
no flags Details
Process definition 1 drl (893 bytes, text/plain)
2013-09-30 02:55 EDT, Marek Baluch
no flags Details
Process definition 2 (4.71 KB, application/xml)
2013-09-30 02:56 EDT, Marek Baluch
no flags Details

  None (edit)
Description Marek Baluch 2013-09-30 02:54:40 EDT
Created attachment 804922 [details]

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 02:55:34 EDT
Created attachment 804923 [details]
Process definition 1
Comment 2 Marek Baluch 2013-09-30 02:55:56 EDT
Created attachment 804924 [details]
Process definition 1 drl
Comment 3 Marek Baluch 2013-09-30 02:56:18 EDT
Created attachment 804925 [details]
Process definition 2
Comment 4 Maciej Swiderski 2013-09-30 09:07:40 EDT
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.
Comment 5 Marek Baluch 2013-09-30 09:26:29 EDT
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 10:02:20 EDT
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 10:17:35 EDT
Maciej yes I agree with that. Extending the catch clause would a nice and fast fix. Thanks.
Comment 11 Marek Baluch 2013-12-04 02:26:27 EST
Verified on ER5.

Note You need to log in before you can comment on or make changes to this bug.