ScheduledThreadPoolExecutor Thread Safety.

Question

Hi,

Are ThreadPoolExecutor and ScheduledThreadPoolExecutor thread-safe?? Now, I have a scenario as under:

• 5 ThreadPoolExecutor(s)
• exec1 (which executes JobA (Job of Level A) : parallelism of 4-5 jobs max),
• exec2 (which executes JobB (made from List inside each JobA) : over 800-3000 jobs per JobA),
• exec3 (which executes and prepares JobC (made from each JobB) : 2-3 jobs per each JobB)),
• exec4 (which executes JobD (1-2 activites per Job)),
• exec5 (which waits for all jobs to be completed and then executes certain activities);

(I hope the above scenario is clear).

Further, all executors are common at the object level. At level A, there are only max 4-5 jobs executing in parallel and preparing for the next level (B) various individual jobs / transactions. Jobs of Level B in turn prepare jobs for level C and Level C prepares jobs for Level D.

Exec5 is a persistor which persists all the data to a DB.

The issue is that jobs are getting lost somewhere at Level C & D i.e., especially when there are many simultaneous threads trying to push newer jobs in subsequent executors task lists asynchronously. None of the RejectionHandlers also received any rejected handlers. Also, I dont face any issues if each of the ThreadPoolExecutors is reduced to a single thread pool executor (1 Thread only). The jobs are inherently very small and hence the parallelism does offer a significant advantage to the activity.

I hope I have been clear.

Please advise. Regards, KT

Answer 1

How are you submitting work to your ExecutorService's? Are you using submit(Callable) or execute(Runnable)? In the former case it is the calling code's responsibility to detect any exceptional conditions by calling get() on the returned Future. Hence if your executors are simply passing work to the next executor and discarding the Future any errors will go undetected.

One workaround is to use execute(Runnable) and override ThreadPoolExecutor's afterExecute(Runnable r, Throwable t) method to raise an alert if called with a non-null Throwable.

An alternative solution would be to wrap the executor in a CompletionService and have a dedicated thread remove completed Futures and "extract" and exceptions.

As an aside this architecture seems quite complicated. Are 5 levels of executor really necessary? Why not start with a single ThreadPoolExecutor that carries out all the required steps? The simpler your design the easier it will be to detect any problems.