Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1149403

Summary: With cancelActivity set to "true" , signal triggered for a boundary catch event on a single instance of embedded subprocess signals other instances too, if the parent process is called from a reusable subprocess
Product: [Retired] JBoss BPMS Platform 6 Reporter: Musharraf Hussain <mhussain>
Component: jBPM CoreAssignee: Kris Verlaenen <kverlaen>
Status: CLOSED NOTABUG QA Contact: Jiri Svitak <jsvitak>
Severity: urgent Docs Contact:
Priority: high    
Version: 6.0.3CC: kverlaen, mbaluch
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-08 10:15:57 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:
Embargoed:
Attachments:
Description Flags
CancelActivity_Bug_BoundaryEvent_repo.zip
none
backup_repo.zip
none
repository_fixed_solution.zip
none
project1-2.0.0-20141005.134707-3.jar
none
Audit log with cancelActivity true
none
Audit log with cancelActivity false none

Description Musharraf Hussain 2014-10-04 12:33:04 UTC
Description of problem:
- Imagine there are two process definitions, (1) ParentCallerProcess.bpmn2 and (2) EmbeddedSubProcessTest.bpmn2 .
- The "ParentCallerProcess" contains the following flow:
~~~
Start -> ReUsableSubProcess [calledElement: project1.EmbeddedSubProcessTest] -> End
~~~
- Now the other "EmbeddedSubProcessTest" has the following process flow where the Embedded Sub-Process contains a User Task, and a Throw Intermediate Signal Event , and at the boundary of this Embedded Sub-Process I am catching the signal thrown from the internal signal event.
~~~
 Start -> [ Embedded Sub-Process ](boundary, Catch Intermediate Signal Event, signal ref: SignalOne) -> End
~~~
- This is how the internal flow of the Embedded Sub-Process looks like.
~~~
       Start -> User Task [name: UserOne] -> [Throw Intermediate Signal Event, signal ref: SignalOne ] -> End
~~~

Now, it has been observed that if multiple process instances are started for "ParentCallerProcess" , and we choose "cancelActivity" property of the boundary catch event to "true" , then in this kind of process flow a signal triggered for a boundary catch event on a single instance of embedded sub-process signals other instances too. i.e. after starting two process instances of ParentCallerProcess or EmbeddedSubProcessTest , we can see two tasks are created. However, if we complete just one task the other one suddenly vanishes from the task menu.

- Note, that if there is no "ParentCallerProcess" created in the KJar, i.e. there is no one to call the EmbeddedSubProcessTest process within the same runtime, this issue does not occur.

- For this specific use case we have used Singleton ksession strategy, but even while building the Business Central project using Request strategy too the same issue can be observed.

[WORKAROUND] As per my observation, this issue does not occur if the "cancelActivity" property of the boundary catch event in the process EmbeddedSubProcessTest was set to "true". If we put it to "false" then this issue does not occur.

Version-Release number of selected component (if applicable):
- jBPM 6.0.x

How reproducible:
- Use the attached "CancelActivity_Bug_BoundaryEvent_repo.zip" bare repository or the pre-built kjar from my Business Central project "backup_repo.zip" to replicate the issue.

Steps to Reproduce:
1. Extract the contents (.niogit folder) from the "CancelActivity_Bug_BoundaryEvent_repo.zip"  archive and place it under "jboss-eap-6.1/bin/" location of BPMS 6.0.3 installation. Optionally you can use the pre built KJar packaged inside "backup_repo.zip" archive to import into the artifact repository through Business Central.
2. Build the project which has the following G.A.V. details "org.kie.example:project1:2.0.0-SNAPSHOT" . If the KJar archived in "backup_repo.zip" file is imported as artifact , then you need to deploy it as a New Deployment Unit, and you can choose Singleton or Request strategy.
3. Start two process instances from any of the process definitions available in Business Central.
4. Make sure you have a user login for "annguyen" in Business Central , and once logged it with this user two tasks for UserOne is available. Try to complete any of them.

Actual results:
- Both the task vanishes from Task list if you just complete one of them.

Expected results:
- One one of the tasks should be completed.

Additional info:
- Please also try the workaround by setting "cancelActivity" to "true" for the boundary event in the embedded subprocess.

Comment 1 Musharraf Hussain 2014-10-04 12:35:18 UTC
Created attachment 943875 [details]
CancelActivity_Bug_BoundaryEvent_repo.zip

Comment 2 Musharraf Hussain 2014-10-04 12:36:24 UTC
Created attachment 943876 [details]
backup_repo.zip

Comment 5 Musharraf Hussain 2014-10-05 14:08:10 UTC
Created attachment 944043 [details]
repository_fixed_solution.zip

Comment 6 Musharraf Hussain 2014-10-05 14:08:37 UTC
Created attachment 944044 [details]
project1-2.0.0-20141005.134707-3.jar

Comment 7 Kris Verlaenen 2014-10-07 20:39:39 UTC
It is true that this behavior is not visible when cancelActivity is set to false, but is because in that case the second embedded subprocess is not completed (because it will reach the (none) end node but since the task node is still active, it will not terminate), and therefore the child process instance is not completed and the task is not aborted).  

Attached audit log views of both cases, which might help explain the difference.

Comment 8 Kris Verlaenen 2014-10-07 20:40:14 UTC
Created attachment 944744 [details]
Audit log with cancelActivity true

Comment 9 Kris Verlaenen 2014-10-07 20:40:44 UTC
Created attachment 944745 [details]
Audit log with cancelActivity false

Comment 10 Musharraf Hussain 2014-10-08 10:15:57 UTC
Hello Kris,

Thank you very much for your explanation as the reason behind this behaviour is clear now. I am happy to close this case now as it is not a bug.


Regards,
Musharraf Hussain