External Task released from lock is provided to other external task clients waiting with asyncResponseTimeout only after 30 seconds of its original lock time.
If I lock an external task for 10 seconds with "lockDuration": 10000 and then submit another external-task/fetchAndLock request with "asyncResponseTimeout": 60000 before lock expires, I will get the released task in response only in 30 seconds (i.e. 20 seconds after lock expiry), instead of 10 seconds (as soon as lock expires). If I submit external-task/fetchAndLock request with "asyncResponseTimeout": 60000 shortly after lock expires, I am getting the task in response with no delay.
Can anyone explain, why there is 30sec lock release threshold for external-task/fetchAndLock with asyncResponseTimeout parameters (especially big ones)?
I would expect to be able to request external-task/fetchAndLock with "asyncResponseTimeout": 600000 (10 min) and would like to get expired locks as soon as they expire. That should allow me to have minimal overhead for polling and still have event-based processing of Tasks (not only new ones, but also the expired ones, from faulty workers).
At the moment, the only way I can make External Task Client to pick up tasks with expired locks is to reduce "asyncResponseTimeout" to amount that I deem to be acceptable delay for fetching such tasks that require different worker. Additionally I do understand that If I have 10-30 different workers, that will have different moment in time when they execute their external-task/fetchAndLock requests, I will increase chances that my subsequent client will execute request right after task lock expiry and such task will be picked sooner, but that approach is not reliable enough to guarantee even distribution of request times throughout the 30 seconds window.
BTW, I am using Camunda BPM: v7.13.0-alpha3.