views:

286

answers:

2

I'm currently working on a daemon that will be doing A LOT of different tasks. It's multi threaded and is being built to handle almost any kind of internal-error without crashing. Well I'm getting to the point of handling a shutdown request and I'm not sure how I should go about doing it.

I have a shutdown hook setup, and when it's called it sets a variable telling the main daemon loop to stop running. The problem is, this daemon spawns multiple threads and they can take a long time. For instance, one of these threads could be converting a document. Most of them will be quick (I'm guessing under 10 seconds), but there will be threads that can last as long as 10+ minutes.

What I'm thinking of doing right now is when a shutdown hook has been sent, do a loop for like 5 seconds on ThreadGroup.activeCount() with a 500ms (or so) Sleep (all these threads are in a ThreadGroup) and before this loop, I will send a notification to all threads telling them a shutdown request has been called. Then they will have to instantly no matter what they're doing cleanup and shutdown.

Anyone else have any suggestions? I'm interested in what a daemon like MySQL for instance does when it gets told to stop, it stops instantly. What happens if like 10 query's are running that are very slow are being called? Does it wait or does it just end them. I mean servers are really quick, so there really isn't any kind of operation that I shouldn't be able to do in less than a second. You can do A LOT in 1000ms now days.

Thanks

+2  A: 

The java.util.concurrent package provides a number of utilities, such as ThreadPoolExecutor (along with various specialized types of other Executor implementations from the Executors class) and ThreadPoolExecutor.awaitTermination(), which you might want to look into - as they provide the same exact functionality you are looking to implement. This way you can concentrate on implementing the actual functionality of your application/tasks instead of worrying about things like thread and task scheduling.

matt b
I originally was using ThreadPoolExecutor and ended up changing it to something else. Handling threads, etc are working fine. I already have it setup to shutdown the threads, my problem was I didn't like the idea of having to shutdown INSTANTLY and telling my threads to stop. The problem is, there is no way around it if a program needs to shutdown. I guess I was looking for magic. I'll set this as accepted because my question wasn't very descriptive. Thanks!
William
What about calling `awaitTermination()` with a timeout when you receive the shutdown signal, and then killing the threads (with `shutdown()`) if this times out? Do you have a need to process the shutdown within a certain time period?
matt b
Nope, I just want it fast because if the server is shutting down, or something is happening delays aren't that great. I think I'm going to send a call to all threads telling them it's time to shutdown, and they all have like 3 seconds to finish, if they don't I'll kill them and and exit. I guess I was looking for a magic "let time pause, let me threads finish, then come back to the real world" in a second. :) Thanks for the help guys!
William
+1  A: 

Are your thread jobs amenable to interruption via Thread#interrupt()? Do they mostly call on functions that themselves advertise throwing InterruptedException? If so, then the aforementioned java.util.concurrent.ExecutorService#shutdownNow() is the way to go. It will interrupt any running threads and return the list of jobs that were never started.

Similarly, if you hang on to the Futures produced by ExecutorService#submit(), you can use Future#cancel(boolean) and pass true to request that a running job be interrupted.

Unless you're calling on code out of your control that swallows interrupt signals (say, by catching InterruptedException without calling Thread.currentThread().interrupt()), using the built-in cooperative interruption facility is a better choice than introducing your own flags to approximate what's already there.

seh