Finding a better way for executing task rejected by ThreadPoolExecutor.


Currently when the thread bounds and queue capacities are reached jobs are executed in JobAcquisitionThread and this thread is blocked until the job is executing.
Problems begin when processes have a lot of long-term task (for example: service task which calls WebServices and response can take about 10 seconds). Those jobs can block
the thread pool for a long time.

In Ronald van Kuijk mentioned that he used own RejectedExecutionHandler implementation (
but i can't find nothing similar for this in codes.

Additionaly, refactoring of JobExecutor threading () has started but this issue still exist in CommonJ JobExecutor (You catch WorkRejectedException and then a new Job is started in JobAcquisitionThread).

Are you going resolve this in the near future ?

In our project this issue is blocking because we will have a lot of long-term service tasks.
I think in current implementation the best way to resolve this will be implementation
own RejectedExecutionHandler and using in it a new command.
This command should unlock job for next execution (like in DecrementJobRetriesCmd, but without decreasing number of retries).


Daniel Meyer (camunda)


Dawid Wrzosek




Fix versions