Ive tried unsuccessfully to trap the job executor SQL query when this condition occurs - perhaps you may have better luck. Ive not been able to consistently produce the behaviour, particularly when Im logging the DB queries…
I’m afraid the log is not so useful without the SQL statements being logged. The latter would tell us exactly when and how the engine queries for jobs.
Calling up the active job through the REST for the process instance shows a normal looking process (a payload you would expect).
If i try and manually execute the job from the Start Event, it will execute the transaction and then wait at the task (in this case, the service task which is running HTTP-connector). When i manually execute the second job (the service task), I never receive a response from the server. I am using Postman, and it just runs “forever”, never seems to timeout or provide a server error.
There is a lot of HTTP-Connector usage in the process definition. Is there a possible connecting with http-connector using up resources? I have my doubts about this given that the logs show the executor looking for jobs but finding none (even for jobs that are waiting as a start event).
Edit:
Further Context:
Just noticed that if you manually execute a job that is stuck as the Start Event, the execution of the job does not show up in the logs. Is this normal? @thorben
If i try to execute the job a second time (after the job has already been completed), i get a InvalidRequestException and the error shows up in the logs.
For the loggers that we activated, this is normal. Another useful logger is org.camunda.bpm.engine.cmd which logs whenever the engine begins and finishes commands. This logger should write something whenever you start executing a job.
This (and the exceptions in you log file) sounds very much like the HTTP requests take a long time and therefore consume all the job executor’s threads. In this case, the job acquisition thread slows down and acquires less jobs or no jobs at all until jobs can be executed again.
Could you check if your HTTP endpoint is generally slow? You can also configure connect to use a timeout when making requests, so you the jobs should fail in this case and free the execution resources. See HTTP Connector | docs.camunda.org and http://www.baeldung.com/httpclient-timeout (section 4) for an example.
So ran some further tests and doing curl or wget directly from shell of camunda server to the HTTP endpoints that http-connector are connecting to provided consistently fast responses.
So get it working, but unclear what was causing the problem.
I manually deleted all process instances that were running across all definitions except for a few instances that were waiting at the blank start event.
The executor still did not pick up the jobs.
So i restarted the container and upon restart camunda picked-up the jobs and executed them without issues.
Running curl or wget from the camunda container to the endpoints that http-connector was connecting to, results in zero issues; everything connects quickly and as expected.
Most of the tokens that were waiting were in Receive Task and Event Gateways. But this may not be relevant given that the executor did not resolve the problem until server restart. Meaning that the http-connector service tasks could have been causing the problem but there was no indicator of resolution until server restart.
@thorben if jobs are in flight, and the process instance is paused/suspended, does the active job get cancelled or would it remain in queue until completion?
When you delete an active process instance that has a job that is currently executing; Does the Job get cancelled mid execution?
Edit: Did some tests. Looks like if a Job is being executed and the process instance is deleted the job will not be cancelled. I tested this by creating a load of jobs and the HTTP-connector endless response issue occurred (i think). And i deleted some potentially problematic process instances, but the job executor did not pick up the changes. Once i restarted the container, the job executor went back to normal
Edit: Have narrowed the problem down to be related to http-connector requests. Further testing tomorrow related to outside network issues (likely).
@thorben can the httpclient configuration settings be accessed within the connector variable of http-connector? For example using a listener or a script in one of the inputs to modify the timeouts? I looked through the docs, but I could not clearly see where the access could be.
It runs until completion and then fails with an OptimisticLockingException since the job and execution tree was updated in the meantime.
No, same optimistic locking behavior as above.
I don’t think so, but haven’t really looked into this. The config I linked to above is used when the client is built. This only happens once, so you can’t configure the timeout on per-request basis this way. But maybe there’s another way with Apache Http client to do this.
@thorben okay great. We have narrowed it down then to specific use case network connectivity (only re-creatable under certain load conditions cause by camunda.
Any ideas on where to look for potentially modifying the per-request timeouts?