The service task is triggering a RESTful POST that takes quite some time, at least some 20 minutes. We were quite amazed to see in the receiver of the POST request that it was triggered multiple times though the timer configuration was “every Monday to Friday at 04:00 am”. So we took some measures in this service to prevent being called while it was still processing a request. We used AtomicBooleans for that.
Now, we found out that after in the Camuda project the service task was triggered as one can see at the log:
2020-08-28 16:06:30,706 INFO CyclicTempDataImportDelegate [amundaTaskExecutor-2] ac06049b-e937-11ea-84de-005056aa6a97: Start trigger for temperature data import
2020-08-28 16:06:30,725 INFO RestCallService [amundaTaskExecutor-2] ac06049b-e937-11ea-84de-005056aa6a97: Request to https://blablabla
2020-08-28 16:11:45,720 INFO CyclicTempDataImportDelegate [amundaTaskExecutor-3] ac06049b-e937-11ea-84de-005056aa6a97: Start trigger for temperature data import
Does a service task need to respond in a certain time? Can this be configured? Or what else did I do wrong?
When a service fails, camunda does a retry. By default this happens immediately and 3 times. So it sounds like your first request failed and you see the retry. You can disable/configure the retry behavior.
20 min for a synchronous call is a long time. Timeout will/may occur on both sides: http request and database connection. You can configure these, but that is not camunda specific …
In general, I would avoid the long running request/service task and try to use external service tasks or an asynchronous send/receive task. But that depends on the concrete scenario.
I think the problem here has nothing to do with the retry, but with the set lock time. By default this is 5 minutes. When these 5 minutes have expired, the job is executed again by the engine. So it does not help to change the retry behavior. Instead you can change the time in the configuration. Take a look at the docs: https://docs.camunda.org/manual/7.13/reference/deployment-descriptors/tags/job-executor/
It is still not recommended to call a service that takes 20 minutes synchronously. Instead you should use other patterns as @jangalinski mentioned before.
The service task starts a runnable that does the long during job. When the runnable reaches its end without any harm, it sends the message to the “Temperature Import OK” intermediate message catch event. In case of a Throwable, to the “Temperature import failed” intermediate message catch event.
BTW: the “Log Failure” service tasks throws an exception on purpose so that a system admin has to look after the reason of the Throwable.
