Process starts on the tomcat/http thread (does not execute async?)

Hi

I can’t figure out how to get asynchroneous job execution. If I invoke

runtimeService.startProcessInstanceById(processId)

then my process is directly executed and not handed off to another thread. This means that the call from the client that triggers this code does not return before the process reaches a waiting state.
This confuses me, as I have the async execution enabled (it is by default with the spring boot starter as far as I can see). Should the call not return and the engine start executing the process in another thread or do I have to handle this myself?

Hi,

You can set you first task in the process model asynchronous. Execution returns as soon as possible and further execution is done in another thread.

Regards
Martin

Ok, thanks. But isn’t there a way of enforcing it on the backend? Leaving it up to the creator of the bpmn seems a little unstable?

What do you mean by enforcing on the BE? (From my point of view it is enforced by the BE. BE is driven by process definition and process definition specifies whether execution is sunchronous or asynchronous)

a little unstable

Where do you see point of instability?

(If you wish to drive process by current process actor use adhoc processes or dynamic processes which are also supported.)

Regards
Martin

I mean, for instance if I have some task that connects to some slow external system, I would like to be sure that that never happens on the http thread since then the user would not get an immediate reply. If I understand correctly what you are saying, you say that whether this happens is dependent on whether the process definition creator ticks the “asynchronous” box on this particular task. So I would have liked to set some flag on my backend telling the engine to always act as if the “asynchronous” flag is set. Do you think I am misunderstanding something in wanting this?

This I don’t understand, could you clarify? :slight_smile:

The process model could look like:

<process start>---------<slow external system call>-------------------<wait on signal>--------<process end>
                                |          /\                                 /\
                                V          |                                   |
                        <external system with immediate answer>----<execution finished>

The best example is HTTP request task in this case. You can call REST API of the external system with immediate response and when external system execution is finished it can send a signal/message to flowable process instance to continue in process execution.

Regards
Martin

Hmm, so what you are saying is that one should make sure to only call external systems able to do the above? I mean I could have a system without a REST interface or anything similar that is just slow to respond. Would the normal way to solve that then be to for instance write my code in the java delegate that calls the system in such a way as not to block the thread?
Or, alternatively, when starting a process, should the developer always ensure to do this on a background thread?
What I do now is just that when a call from my frontend comes in to start a process, I basically just invoke startProcess on the runtime service. Is this bad practice - should I ensure that start process is only called on a background thread?