nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Event handler - decrease fetch time

racadent

Hi,

Is there any way to tell Activiti to fetch events (signals and messages) more frequent? I have messages in Activiti which are triggered by application and Activiti needs certain amount of time (0.x seconds) to fetch them and execute.

Can I configure that time with different value?

I know it could be overhead for the db, but current value doesn't fit our business logic.

Find more posts tagged with

Comments

trademak

Hi,

Signals and messages are handled directly, but depending on the way you use it, the handling of the message and signal can more or less time.
Do you also pass an executionId, or or only the signal or message name?
How many process instances can be waiting for a signal in your case?
Also, by default no index is created on the event name in the event subscription table (ACT_RU_EVENT_SUBSCR).

Best regards,

racadent

I have very simple diagram and I will try to describe, because I could not upload attachment:

Start message event->Event gateway->2 events (e1, e2)-> both events go to End event.

And I have a small test:

<br>&nbsp; for (int i = 0; i<5;i++) {<br>&nbsp;&nbsp; System.out.println("Message triggered: " + dformat.format(new Date().getTime()));<br>&nbsp;&nbsp; runtimeService.startProcessInstanceByMessage("r_msg"); //start with message name<br>&nbsp;&nbsp; System.out.println("Message finished, now trigger the event e1: " + dformat.format(new Date().getTime()));<br>&nbsp;&nbsp; runtimeService.signalEventReceived("e1"); //trigger event e1<br>&nbsp;&nbsp; System.out.println("Event finished: " + dformat.format(new Date().getTime()) + "\n");<br>&nbsp; }<br>

I get the following output:

<br>Message triggered: 2013-02-28 12:42:06,223<br>Message finished, now trigger the event e1: 2013-02-28 12:42:06,824<br>Event finished: 2013-02-28 12:42:07,054<br><br>Message triggered: 2013-02-28 12:42:07,054<br>Message finished, now trigger the event e1: 2013-02-28 12:42:07,254<br>Event finished: 2013-02-28 12:42:07,461<br><br>Message triggered: 2013-02-28 12:42:07,461<br>Message finished, now trigger the event e1: 2013-02-28 12:42:07,672<br>Event finished: 2013-02-28 12:42:07,893<br><br>Message triggered: 2013-02-28 12:42:07,893<br>Message finished, now trigger the event e1: 2013-02-28 12:42:08,107<br>Event finished: 2013-02-28 12:42:08,334<br><br>Message triggered: 2013-02-28 12:42:08,334<br>Message finished, now trigger the event e1: 2013-02-28 12:42:08,541<br>Event finished: 2013-02-28 12:42:08,756<br><br>

As you can see Activiti needs ~200ms to start message and another ~200ms to trigger the event!?.
There are no more process instances that are waiting for the event and I have also created index on the EVENT_NAME_ column in ACT_RU_EVENT_SUBSCR. Mashine has quite good performanse (i7,6gb).

Also, when I query to the db directly and do select * from ACT_RU_EVENT_SUBSCR where EVENT_NAME_ = 'r_msg' I get:

(1 row(s) affected)<br><br> SQL Server Execution Times:<br>&nbsp;&nbsp; CPU time = 0 ms,&nbsp; elapsed time = 0 ms.<br><br>

jbarrez

Such micro benchmarks are hard to say anything about … it could very well be a problem with the connection pooling … The only way to really know where time is spent, is attaching a profiler.

racadent

Ok and my question is: do I have the problem (with ~200ms response) or it is usual Activiti behavior?

I suppose from your answer that I have a problem (db, hardware…).

racadent

Yes, connection pool was missing. Thanks a lot!

jbarrez

And that was just a random guess from me