Delay in creating event subscriptions

Camunda 7 Topics Discussion & Questions
1

Hi

We are experiencing the following issue with an embedded camunda workflow engine running on SQL Server.

Below is the process model (To make things easier I have numbered the components and refer to them using their numbers in the description)

Workflow%20Diagram
Workflow%20Diagram1190×302 28.6 KB

Flow:
    - 6 starts a process that does some work and sents out a message/event.
    - When we attempt to correlate the message/event to the process instance, the event subcription for 8 & 9 is NOT yet created in this table `dbo.ACT_RU_EVENT_SUBSCR`.
    - A few miliseconds later we find it there.

Findings so far:

    1. When async after is on for 6, the creation of the event subcription for 8 & 9 is delayed enough to exhibit the behaviour above.
    1. When async after is off for 6, the event subcription is created before we attempt to correlate.

Note: This happens consistenly for each process instance.

I want to keep the async after on for 6 since its a logical unit of work, however because of this issue I cannot.

I would like help in answering the questions below:

1. What causes this behaviour?
2. In the docs, its metioned that the parallel sequence flows from a parallel gateway are actually executed sequentially:
    3.1. What rules are applied to choose which branch/flow gets executed first?
    3.2. Is the entire branch executed or just first node of each outgoing sequence flow from a parallel gateway?
3. Has anyone had this issue before and what was their fix?

Thanks

Regards
Praise

2

Hi @Praise,

technically you don’t need async after task 6, as it has only wait states (event based gateway) after.

You can go either without async after or do an async before if it keeps your logical structure?

Maybe an async before on the start event of your called process helps as well?

A process instances is always executed until all tokens have reached a wait state. The next branch of a parallel gateway is followed until it reaches a wait stated. Then the next branch is picked up. If no token can be moved further, the process instance is saved in the database. If a token ends with a async continuation, the job executor continues the process execution.

The sequence of parallel braches are hard to predict. As camunda is open source, you can have a look at the code by yourself.

3

Hi @Ingo_Richtsmeier

Thank you, using an async before achieves the same semantics.
I have used this to solve the problem.