If a runnable hangs while running in a threadpoolexecutor, is there a way to find out that it has hung and kill the runnable? Will the getActiveCount method consider a runnable that's hanging as "actively executing"?
There is no safe way to kill a thread which is busy (other than running it in another process and killing it) You can detect if a thread is taking to long by waiting for the result with a timeout. You can also add a task to cancel the task after a timeout, however this will only interrupt a thread's task, not kill it.
You are better off determining why the task "hangs" and fixing the code so it doesn't.
When you start a task you store Thread.currentThread() is a share variable. You can then take a getStackTrace() periodically to determine what it is doing and log it.
Related
I am submitting callables to executorService (fixedThreadPool).
and storing the reference of the thread in callable object.
now the problem here is, in these threads, I am calling someone else's callback method(consider we have a jar with one interface and that interface's implementation is done by the targeted product), so basically I have no control on what other product is doing in that thread.
so sometimes what happens is due to some socket connection issues this thread gets stuck for an indefinite time and now, here is the issue I do not want to wait for that thread to end I want to kill that thread gracefully.
I tried with thread.interrupt() but it is only able to interrupt blocked, waiting and sleeping threads. The runnable or working thread can not be interrupted by this.
(Note: I am able to kill this thread forcefully using thread.stop() but as that is not recommended I do not want to do that, I am searching for a graceful solution)
now let us say it is ok that I am not able to kill this thread due to some limitations but the problem here is if I call future.cancel(true) on my future task I am not able to free this thread from my executor pool, basically I can not reuse that executor task anymore(here basically I have a static reference of executor service which has been reused in the loop), I have even tried using executorService.shutdown and shutdownNow nothing was able to free that thread from executor service.
so is there any way to kill this thread gracefully and free it from executor service.
Here is my situation:
I have a ThreadPoolExecutor on whose Threads I make a HTTP call to a server via SSL. Sometimes, I get a NullPointerException because the client cannot decrypt the server response and the thread just hangs there indefinitely causing a livelock in the pool. Does anybody know a good way to target a specific thread in the pool, check how long it's been running and kill/interrupt it if it's been running for longer than say 3 minutes?
Any suggestions welcome.
If you keep a reference to that thread, then you can call interrupt() method on it in order to interrupt it. for example:
Thread t = new Theard(r);
t.interrupt();
(r is runnable, a job)
With Spring aop you can count the time passed from the moment that start method was triggered.
Another solution is to use your own thread factory, in the factory make sure to interrupt each thread after 3 minutes.
Another approach is to use: ScheduledThreadPoolExecutor
set your task to run for a period of time, and let it end gracefully after one execution.
I have been reading a lot on this but I am not sure what's the most elegant way of handling my usecase. I have an application that starts a background scheduled thread using ScheduledThreadPoolExecutor. This scheduled thread in-turn has an ExecutorService of pool size 20. Each new thread submitted to this pool will inturn again have an ExecutorService of pool size, lets say 50. The lowest level thread doesn't do much other than looping through some standard tasks, each task taking anywhere from a second to 10 seconds.
As this is a background agent application performing background tasks, We should be able to stop them cleanly any time we want. The problem is I am not sure how to trickle down the an interuption/shutdown signal 3 level down to the lowest thread so I can break out of the loop and shutdown all the threads neatly.
I was looking into Runtime.addShutdownHook() but I wasn't exactly sure how it will be useful in my usecase. I was also looking into checking for isInterrupted() at the lowest possible Thread level but than I wasn't sure if Ctrl + C or kill -9 / kill -15 command actually is transformed to an interrupted signal inside the application. And if so, how would it trickle down 3 levels of threads, or would I have to manually interrupt each thread inside the Runtime.addShutdownHook().
I am trying to find a solution that is most elegant and safe.
The interrupted flag has nothing to do with native OS-level signals sent to the process hosting the JVM. You can set the interrupted flag on any thread by calling thread.interrupt().
For your problem I would suggest accumulating all your ExecutorServices into a global collection so that you may call shutdownNow() on each upon termination. If you use a gentle-enough signal to terminate your process, the shutdown hooks should be executed and there you can try to shut down your executor services. Note, however, that each task you submit must be interruptible, which means that it must respoond to the setting of the interrupted flag by actually finishing its work. This will not happen implicitly.
I must add that I find your solution with numerous executor services quite odd. A single, properly configured thread pool should be all you need in addition to the scheduled executor.
I had a quick question, in Java, is it better to let a thread run continuously after it is done being used, or is it better to try and .interrupt() the thread?
My thought is this: Lets say I create threads by a loop so that I can have 100 threads all doing a separate process that does not interrupt the GUI (on the main thread), then the process is finished on all of the threads. Do I stop the threads, or do I just let them continue being open, even though they are not technically doing anything?
My guess is that it would be best to kill the threads so they do not take any resources from the rest of the program. Any ideas?
When a thread has "finish processing", i.e., exits from the run method, the thread will terminate itself and there's no need to interrupt.
How to shutdown all threads created with ExecutorService after the
executor.awaitTermination(1, TimeUnit.DAYS);
is finished?
That's the max time threads can work, and if, in some case, any of them does not finish current task, shut it down and start again.
If awaitTermination returns true, then all the threads have been shutdown.
If awaitTermination returns false, then some of the threads are obviously not responding to interruption*, and apart from exiting the java process, there is not much you can do...
*If the tasks run by the threads are yours, make sure they respond to interruption by exiting quickly and awaitTermination will return promptly.
There is no easy way to do it. You can use a ThreadFactory which will create daemon threads, then run awaitTermination in the main thread, followed by shutdownNow. This will (hopefully) shut down the whole JVM, and there is little to nothing better than that in the given situation. Executing System.exit() is an even more drastic measure.
Note that interrupting or even stopping threads doesn't guarantee that they will actually terminate.
You can call System.exit(1) to stop the application. If you dont want to exit then you should design your tasks so that they react to Thread.interrupt properly, there is no other way.