Execution interval of the service task

I would like to know what the execution process is like for asynchronous continuation service tasks.
For example, in the BPMN below, the service task A will check whether an asynchronous bussiness task in the application has been completed. It can through the gateway when it is completed. If not completed, the service task A needs to be executed again.
I observed that a SQL is executed regularly to retrieve the service tasks that need to be run. However, from my testing, it seems that Service Task A is immediately executed again after passing through the gateway, rather than waiting for the next execution of the SQL query.
I would like to know if there is a way to configure it so that Service Task A can be executed during the next pull, instead of being executed immediately.

My project uses Spring Boot + Camunda.

diagram_1.bpmn (3.8 KB)

Service task implement

Application log

I also found that such service tasks can block the execution of other service tasks, leading to starvation for the other service tasks.

It seems that after this service task is completed, it will be immediately delivered to the execution queue instead of waiting for the next SQL query to retrieve tasks.

Hi @ShouJing_Guo.

If you want to wait some time before executing the service task again, it would be better to place a timer intermediate event in the flow leading back to the service task. That way you’re sure to wait for a certain amount of time.

Actually with the async continuation before the service task, it should persist that as a job to the database and only pick it up when the job executor again queries for jobs, but I would not count on that for some timeout.

1 Like

Also here is a link to a post explaining that behavior:

Thank you very much for your reply!
I want to know if there is a setting to prevent Camunda don’t skip the acquisition cycle.

No I believe there’s no such setting.
And as mentioned before, I would anyway not count on such internals but rather use some timer events or other means for your use case.

Thank you for your reply.
Thinking from another perspective, it seems possible to achieve this effect using external task, by customizing a task-pulling thread that fetches tasks at regular intervals.