2

I am trying to use a ThreadPoolExecutor/ExecutorService in my application - it is a static global object. I use: Executors.newScheduledThreadPool(corePoolSize) - but I am having problems with shutting down the executorService.

If I don't call shutdown() + awaitTermination() - then my application won't finish -even if all threads are completed.

My application has threads being created by other threads - so I can't put a shutdown() anywhere in the code without blocking further threads to be run.

Is there a way to let java shutdown() the executor service when all threads are completed.

Thanks

-- Also this question is not a duplicate - the daemon fix makes my application exits before all threads are completed (See comment) - What will be a fix for this? Thanks

EKK
  • 171
  • 2
  • 12
  • Not a complete duplicate. Making all threads daemons will make the app finish as soon as the main thread exists, not as soon as the tasks are completed, as the OP asks – GPI Mar 16 '15 at 10:52
  • That's right - I just tried this solution and it exits without completing all the tasks. What would be the fix? – EKK Mar 16 '15 at 11:08
  • A very generic question to help us answer : can you tell in your question how do **you** know you have dispatched all the tasks to the executor ? (Maybe you have a fix number of tasks that dispatch a known number of callables in your executor, or may be each of these "dispatching" tasks can know when they themselves have finished...) – GPI Mar 16 '15 at 11:28
  • If Task1 is launched and kick Task2 and Task3 - at some stage task2 and task3 will be completed - which means their thread will be terminated. Then if task1 does not do anything else than launching task2 and task3 - then task1 will also be completed - so the knowledge of which task is completed is there somewhere - and i don't think i should have to deal with that - Isn't it? – EKK Mar 16 '15 at 11:31
  • If you do awaitTermination, then shutdown, what's the problem? – Bram Mar 16 '15 at 12:58
  • @EKK : no, the logic is not there. From the ExecutorService's point of view, if Task2 is super super super fast and finishes before you even submit Task3, then by your definition, it should stop after Task2. (My example is an exageration, but the concept is : no, the ExecutorService doesn't know if it's done, only "you" can know the definition of "done") – GPI Mar 16 '15 at 13:57
  • The problem is that some threads are kicking other threads after the shutdown is called – EKK Mar 16 '15 at 14:22
  • @GP1 : if all threads are completed and the main thread is at the final line - no more threads can be submitted - then the ExecutorService will never get any more task submitted. At the same time timerTasks (firing another job to the executor) could have been created outside the ExecutorService - and the executor does not know about it. So basically - i can't know if the threads i submitted to the executor are completed - and the executor does not know what is going on outside - so we both don't know... – EKK Mar 16 '15 at 15:05
  • @EKK : if you, the developer can not know, the computer can not know, end of story :(. So I could advise you to use a (Singleton ?) `ConcurrentList` that would track all your Task's Futures and try to `get` them to check if it's done. I could advise you to use an `AtomicInteger` to count the number of active Timers tasks, I could advise you to use a `Semaphore` or `CountDownLatch` so that your threads could signal when they are done collectively... But none of that will be usefull as long as you do not know how to define that you are done... (no more Timers will fire ? All timers are done ?) – GPI Mar 16 '15 at 16:03
  • @GPI: it seems that CachedThreadPool is smart enough to figure it out - look at the example in :http://stackoverflow.com/questions/29098117/shutdown-or-not-shutdown-in-executorservice-java8 – EKK Mar 17 '15 at 12:17
  • It is a simple timeout implementation. But it is not a `ScheduledThreadPool` as you question specifies. If it works for you, then fine (and it means your definition of "done" is : if no task has been submitted for 1 minute, which is The `CachedThreadPool` thread timeout). Be carefull with the corePoolSize though, because if it's not zero, you'll still have live threads. These are all implementation details that may suit you, but you need to be aware of how this translates to your business requirements. – GPI Mar 17 '15 at 12:22
  • Cant you use Runtime.getRuntime().registerShutdownHook() to register your shutdown threads? – Ferrybig Jan 13 '16 at 09:26

0 Answers0