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

Bug 1066632

Summary: Simulation: Unexpected path in simulation results for catch intermediate event
Product: [Retired] JBoss BPMS Platform 6 Reporter: Sona Mala <smala>
Component: jBPM DesignerAssignee: Maciej Swiderski <mswiders>
Status: CLOSED CURRENTRELEASE QA Contact: Sona Mala <smala>
Severity: high Docs Contact:
Priority: medium    
Version: 6.0.1CC: kverlaen, mswiders, rrajasek
Target Milestone: ER2   
Target Release: 6.0.1   
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:03:44 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
BPMN2 definition
none
#1: Simulation result - throw event and catch event was executed
none
#2: Runtime result - just throw event is executed
none
#3: Simulation result - process is completed
none
#4: Runtime result - process wait in catch event none

Description Sona Mala 2014-02-18 18:32:13 UTC
Created attachment 864675 [details]
BPMN2 definition

Description of problem:
I compared behaviour of Business central and Simulation engine for attached process. I found out some incompatibilities.

I am not able to get attached screenshot (#1) of path from simulation results in runtime of process. I have got just attached screenshot of completed process (#2).

May be there is some misunderstanding of catch intermediate event execution.
BPMN2 specification says "Once the Event occurs, it is consumed."

I am not sure if both events (entering into event node and send a signal) are needed for leaving an event node. 

But I am certain that simulation engine should have same behaviour as runtime.



The other problem is that if no signal coming then catch intermediate event should wait and never end.

This is a reason why I set probabilities 20 : 80. It means that simulation invoke just 2 throw event but there are 8 wait mechanism. Still 6 process instances never ends. Still simulation results gives me just completed paths (#3) and no incomplete path (#4).

Comment 1 Sona Mala 2014-02-18 18:35:52 UTC
Created attachment 864676 [details]
#1: Simulation result - throw event and catch event was executed

Comment 2 Sona Mala 2014-02-18 18:37:16 UTC
Created attachment 864678 [details]
#2: Runtime result - just throw event is executed

Comment 3 Sona Mala 2014-02-18 18:38:11 UTC
Created attachment 864679 [details]
#3: Simulation result - process is completed

Comment 4 Sona Mala 2014-02-18 18:39:07 UTC
Created attachment 864689 [details]
#4: Runtime result - process wait in catch event

Comment 5 Sona Mala 2014-02-18 18:45:04 UTC
Please there is a mistake in description. there should be:

   "I am not sure if both events (entering into event node and getting a signal) are needed for leaving an event node."

Comment 6 Maciej Swiderski 2014-02-19 20:01:46 UTC
actually the problem was the the event (throw -> catch) correlation was not taking into consideration that these two event can be active for single process instance. Enhancement was added to take into account such situation.

droolsjbpm-integration
master:
https://github.com/droolsjbpm/droolsjbpm-integration/commit/a4eccba695d83a462818c853f35508378b030843

6.0.x:
https://github.com/droolsjbpm/droolsjbpm-integration/commit/6842a2f758b01f0aff9f9a69df7e623736f0fe34

Comment 7 Sona Mala 2014-03-11 15:09:23 UTC
Please, can you describe behaviour of signal event which is thrown by Throw Intermediate Event? I mean how long is such event valid (if it affects another instances which run before/after instance which throws this event).

For 6.0.1 er2 bpms: screnshots #3 is not equal to screenshot #4. I need more background information to verify this issue.

Comment 8 Maciej Swiderski 2014-03-11 17:00:33 UTC
Sona,

throw events in simulation will not affect anything as it is not actually throwing the event. It only simulates it and by that will try to find matching catch event in same process definition. So if it can find it till directly follow the path outgoing of catch event.

Although on runtime it might affect other process instances that can be waiting for such an event. Difference between runtime and simulation is quite big - runtime has much more information at hand. Like it can "query" for process instances that waits for given event. Simulation is scoped only to single process definition and thus cannot have such advanced capabilities.

In screenshot #3 you can see that the simulation went through the catch event and that is expected behavior as it only simulates given wait time on catch event and considers that such event will come after calculated amount of time - given as simulation property on the catch event.

Does that makes things clearer?

Comment 9 Sona Mala 2014-03-17 16:30:28 UTC
I understand that simulation engine does not know if a throw event is fired in others process instances. I think that simulation engine can assume that some throw event is fired in particular time by another process instance.


This solution can hide some bottleneck (any instance does not throw expected event).