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 (http://today.java.net/article/2008/10/21/creating-notifyingblockingthreadpoolexecutor)
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).