In our MySQL db we see that all the job requests are going to single lock owner and hence jobs are not moving at all until we set this lock_owner as NULL and make it available for next job in the pipeline. Kindly help us to get this solved as soon as possible.
As of now we are executing the stuck jobs manually.
The locks at OS level looks like below.
Most of the jobs are captured by single lock_owner here: 3f372c61-ad0d-4f98-875a-3f2d761b1d62
Hi Joram,
The lock owner of a job are getting reset by reset thread.
Whenever the job acquisition happens, we can identify the new lock_owner is getting locked to the job but the job execution is not happening(in our case we have call activity to a third party API). We are able to execute the job manually by clicking on execute button in admin.
We usually notice this issue only in parallel gateway so far even though we have set all events and call activities are asynchronous and joining gateway as asynchronous plus exclusive.
You can refer the screen shot below for your reference.
You are running with the async executor enabled on all Flowable instances?–>Yes
How many Flowable instances do you have?–>only one
How long does your job run? Is it a long-running job?–>there are few jobs which runs for few seconds and also there are jobs which run for 6 hours. So we have set the LOCK_EXP time to 24hours since default was only 5minutes.
How is you async executor core and max pool size set?
Having jobs that run for 6 hours is something that we do not recommend. This means that a database transaction will be open for 6 hours. This can lead to various problems due to transactions running too long.