Inclusive Gateway: Major Performance Issue and Defect

[tidetom]

Hi all,

I've found a major issue with the Inclusive Gateway.  This is a very different issue (and IMO even more pressing/critical) than ACT-1204, ACT-1026, and ACT-1073 (the currently reported items for Inclusive Gateway), in that it would seem to negate the benefits of using the Inclusive Gateway entirely.

First, to set up the scenario:

• We have a set of fairly complex flows, with sub-processes that can sometimes be complex as well.  We use inclusive gateways heavily to determine conditional behavior in these flows.


• It is assumed the reader knows that when an Inclusive Gateway is put into a flow, and it has multiple forks it can take, each fork causes a new activity instruction item to be logged into the Activiti History for that flow.

To summarize the primary issue:

• After the first Inclusive Gateway path taken, every subsequent task created for that path doesn't have an end_time_ set, and therefore never gets a duration_ set.  Perhaps it never officially ends?


• The next task (after each of those Inclusive Gateway tasks), is delayed by a minimum of 1 second (sometimes up to 3.5 second task).  See chart below.

First, to see this for yourself on your own flows, add an Inclusive Gateway with several tasks as forks, join using an Inclusive Gateway, then run this handy query:

SELECT r.slevel "Lev",
       act_name_ || ' [' || act_id_ || '}' act_name_id,
       decode(r.slevel, 1, 0, a.duration_) duration,
       decode(r.slevel, 1, a.duration_, 0) "MainTime",
       a.start_time_,
       a.end_time_,
       substr(p.proc_def_id_, 1, instr(p.proc_def_id_, ':') - 1) process,
       a.proc_inst_id_
FROM   act_hi_actinst a,
       (SELECT LEVEL slevel, t.proc_inst_id_, duration_
        FROM   act_hi_procinst t
        START  WITH super_process_instance_id_ IS NULL
             AND    proc_inst_id_ = '1141690'
        CONNECT BY PRIOR proc_inst_id_ = super_process_instance_id_) r,
       act_hi_procinst p
WHERE  a.proc_inst_id_ = r.proc_inst_id_
AND    p.proc_inst_id_ = a.proc_inst_id_
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The query should give you a nice output, sequencing your history and showing you every task executed (in order) for a process and all of its sub-processes.  For one of our flows, we have the following statistics:

• There are 161 process instructions shown in the history.  Of the 162, 23 are related to Inclusive Gateways.  We only have 5 total Inclusive Gateways in the flow.


• The whole flow takes 53 seconds to execute.  Of the 53 seconds, 36 seconds (68%) are consumed between the start_time_ of Inclusive Gateways, and the start_time_ of the next process instruction (this is the only way duration can be determined, because end_time_ and duration_ aren't set for the Inclusive Gateway).

I have a specific table which shows all 161 generated from the above query, but I think a forum post probably isn't the way to view it.  Instead, I'll put a small sub-segment, from the first (shrunk down to be easier to see):

#    NAME                  DURATION START_TIME  END_TIME    START_TO_START_DURATION  DIFFERENCE
123  Inclusive Gateway     1317     1.33168000  1.34485000  1317                     0
124  Exclusive Gateway     1        1.34485000  1.34486000  1                        0
125  Verify Something      95       1.34486000  1.34581000  95                       0
126  Exclusive Gateway     0        1.34581000  1.34581000  0                        0
127  Inclusive Gateway              1.34581000              3195                     3195
128  Verify Something Else 70       1.37776000  1.37846000  70                       0
129  Inclusive Gateway              1.37846000              2307                     2307
130  Inclusive Gateway              1.40153000              1669                     1669
131  Update Something      27       1.41822000  1.41849000  47                       20
132  Inclusive Gateway              1.41869000              1417                     1417
‍‍‍‍‍‍‍‍‍‍‍‍‍

Note on the columns:

• # - The activity instruction number, out of 161.


• NAME - Taken from the act_name_id in the query above


• DURATION - Taken from the duration_ in the query above


• START_TIME - A simplified version of the start_time_ from the query above (in minutes)


• END_TIME - A simplified version of the end_time_ from the query above (in minutes)


• START_TO_START_DURATION - The "actual" duration between when the current activity instruction and the next activity instruction is executed


• DIFFERENCE - The difference between Activiti's duration_, and the "actual" START_TO_START_DURATION.

You can see in the above, that the Exclusive Gateway executes in 1 millisecond.  I would have thought the inclusive gateway would have been the same… but unfortunately as you can see the first execution takes 1.3 seconds.  All subsequent Inclusive Gateway calls do not have a duration, or an end_time, and the "next" activity instruction starts with a significant performance delay.  From 123 to 132 above, it took about 10 seconds to execute.  Only 203 milliseconds of that 10 seconds was spent executing actual business logic, the remainder was spent in delays caused by Inclusive Gateway.

I can certainly enter this as a JIRA issue as well, but wanted to put into the forum to see if there are any immediate thoughts from the community or Activiti development team.

Thanks in advance for your help!
Tom

[tidetom]

Our team wanted to eliminate if there’s any side effect of things we do, like pause to get the output variables et al, so we have created simple flows with nothing but script tasks. Basically we have 4 flows, each with 5 ScriptTasks controlled by a condition.  The flows are:

• 1. 5 tasks controlled by an inclusive gateway


• 2. 5 tasks controlled by an exclusive gateway


• 3. 5 tasks controlled by a parallel gateway


• 4. 5 tasks controlled by a parallel gateway, followed by an exclusive gateway (emulating Inclusive Gateway functionality)

As expected for exclusive gateway the flow only passed thru one task, for parallel all 5 paths are executed and I set my condition to be true for 3 paths for inclusive gateway and parallelAndExclusive (our old implementation of inclusive gateway) runs.

Results prove: inclusive gateway is buggy.


PROC_DEF_ID_                    SUM(DURATION_) REAL_ELAPSED_TIME MIN(START_TIME_)              MAX(END_TIME_)                  TASKCNT
svc_f_test_igw:1:736265         3253           5.792             23-MAY-12 12.04.28.790000 PM  23-MAY-12 12.04.34.582000 PM    3
svc_f_test_eXgw:1:736261        80             0.08              23-MAY-12 12.04.24.739000 PM  23-MAY-12 12.04.24.819000 PM    1
svc_f_test_pgw:1:736273         162            0.336             23-MAY-12 12.04.36.272000 PM  23-MAY-12 12.04.36.608000 PM    5
svc_f_test_pgwPluseXgw:1:736269 115            0.177             23-MAY-12 12.04.40.701000 PM  23-MAY-12 12.04.40.878000 PM    3

I can provide the ZIP file upon request with the tested BPMN flows, and an output captured using the following query:


SELECT proc_def_id_,
       SUM(duration_),
       extract (second FROM (MAX(end_time_) - MIN(start_time_))) real_elapsed_time,
       MIN(start_time_),
       MAX(end_time_),
       SUM(decode(act_type_, 'scriptTask', 1, 0)) - 2 taskcnt
FROM   act_hi_actinst
GROUP  BY proc_def_id_

All help is very much appreciated. 

Activiti Developers / QA - please let me know if you'd like me to submit a JIRA issue for this item.

Thanks in advance,
Tom

[trademak]

Hi Tom,

Thanks for the detailed description.
Could you create a JIRA and attach a ZIP with a unit test project so that I can run it and try to reproduce it, before I can seek for a solution?

Thanks,

[tidetom]

Hi Tijs,

Good to hear from you, and thank you for the quick reply.  I have added JIRA issue ACT-1231: http://jira.codehaus.org/browse/ACT-1231.

Please let me know if there's anything else I can do to help this item along.

Thanks again,
Tom

[tidetom]

Hi Tijs,

I'm curious if you think this issue might be something that would be fixed in the near term, or longer term?  I don't mean to pressure you, but just ask because given its effect on performance, our team is trying to decide whether to change all of our inclusive gateways back to the equivalent parallel + exclusive gateway combination or not.  Naturally if this is something that will be investigated and potentially fixed in 5.10, then we'd prefer not to go through that effort.  If later than that, then we'd probably go ahead with changing our flows so that inclusive gateways are no longer used.

Thanks in advance,
Tom

[cirerenat]

Should we avoid using Inclusive Gateways until this is addressed? The workaround (parallel + exclusive gateways) seems to make the flows quite crowded and not very clear to the business people.
Regards

[silvioneto]

I've added a comment on [http://jira.codehaus.org/browse/ACT-1231]. I think it's relevant…

[jbarrez]

I don't believe the inclusive gateway needs history enabled. And of course your index remarks is correct.