Bug 798876 - ProcessEventListener reports events in wrong order
ProcessEventListener reports events in wrong order
Status: VERIFIED
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5 (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity urgent
: ---
: BRMS 5.3.0.GA
Assigned To: Kris Verlaenen
Tomas Schlosser
: TestBlocker
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-01 02:12 EST by Tomas Schlosser
Modified: 2012-05-30 20:47 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Schlosser 2012-03-01 02:12:05 EST
Description of problem:
When a ProcessEventListener is added to session, it reports events in a wrong order.


Version-Release number of selected component (if applicable):
BRMS-5.3.0-ER4

How reproducible:
Every time

Steps to Reproduce:
1. add ProcessEventListener
2. start simple process
  
Actual results:
beforeProcessStarted
beforeNodeTriggered
beforeNodeLeft
beforeNodeTriggered
beforeVariableChanged
afterVariableChanged
beforeNodeLeft
beforeNodeTriggered
beforeNodeLeft
beforeNodeTriggered
afterNodeTriggered
afterNodeLeft
beforeNodeLeft
beforeNodeTriggered
afterNodeTriggered
afterNodeLeft
afterNodeTriggered
afterNodeLeft
afterNodeTriggered
afterNodeLeft
afterNodeTriggered
afterProcessStarted


Expected results:
beforeProcessStarted
afterProcessStarted
... the rest of the events

Additional info:
pull request on the way (test case will probably be added to already opened request #52)
Comment 3 Tomas Schlosser 2012-03-01 03:06:02 EST
test case added to pull request #52
Comment 4 Kris Verlaenen 2012-03-01 08:57:32 EST
This is actually expected behavior.  Before and after events are used to derive what events are triggered as the result of the first.  It might make more sense if you visualize it as a tree:

- beforeProcessStarted
  - beforeNodeTriggered
    - beforeNodeLeft
      - beforeNodeTriggered
        - beforeVariableChanged
          afterVariableChanged
        - beforeNodeLeft
          - beforeNodeTriggered
            - beforeNodeLeft
              - beforeNodeTriggered
                afterNodeTriggered
              afterNodeLeft
            - beforeNodeLeft
                beforeNodeTriggered
                afterNodeTriggered
              afterNodeLeft
            afterNodeTriggered
          afterNodeLeft
        afterNodeTriggered
      afterNodeLeft
    afterNodeTriggered
  afterProcessStarted

So in this case, the starting of the process triggers the the next node, which is the left, etc.  But all events in between the beforeProcessStarted and afterProcessStarted occurred as a result of the startProcess(..) invocation, and are therefore logged in between.

Does this make sense?
Comment 5 Lukáš Petrovický 2012-03-01 09:14:48 EST
(In reply to comment #4)
> Does this make sense?

Unfortunately no, it doesn't.  In our opinion, this goes directly against what you as a user expect of these events. 

Before* works very well, but the After* are just plain wrong - you don't want to get AfterProcessStarted at the end of your process - you want to get it immediately after the process starts. Otherwise "AfterProcessStarted" is actually "BeforeProcessEnded".

This is a very important distinction for the semantics of the events. QE is of the opinion that After* events that

a) don't arrive immediately after the situation happens, AND
b) don't even happen in the same order

are useless and harmful.
Comment 6 Kris Verlaenen 2012-04-17 09:52:44 EDT
Updated in community docs:
https://github.com/droolsjbpm/jbpm/commit/89bca815b8efc026dae51cd52afc0077a4f0eb71
Comment 9 Ryan Zhang 2012-04-23 03:36:55 EDT
Update status to ON_QA. Please verify them against ER6.
Comment 10 Tomas Schlosser 2012-04-24 01:35:36 EDT
The bug is documented therefore I'm marking it verified.

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