I have read many posts on this site and elsewhere about killing threads in tomcat but none seem to answer my question completely. Hence I start new thread.
I would like to know if I can explicitly timeout a thread in tomcat (the ones I see in the manager application for each connector) via some property in a config file. I ask this for the many situations in which a thread may become stuck (hung).
If there is no such property, I hope a kind guru among you can help me understand the rationale behind the lack of such a timeout property.
If a timeout of such a nature is not possible, is there some way to kill a long running thread. I saw a possible example on "Killing a particular Tomcat thread" but I am not much of a programmer.
The reason that Tomcat lacks a thread timeout capability is that HTTP is not a long-term conversational protocol and shouldn't be spending enough time in application code to need to worry about timeouts.
HTTP requests should be handled as quickly as possible, meaning that the amount of time spent in servlet/JSP code should be kept short. Otherwise, server throughput rates will be be hurt.
An IDE is no substitute for an Intelligent Developer.
Joined: Jul 04, 2011
Thanks for replying.
So, killing the thread is not a good idea and HTTP requests are intended to be short lived.
However, I keep wondering why there isn't a timeout value especially since the hung/stuck thread is such a common problem which can bring down an entire instance. I've found timeouts for almost everything else. (session, db, connector, etc)
There must be a very compelling reason for this. What is the rationale behind the lack of the timeout? If someone could add to the posts I am sure it will be beneficial to all. Especially for those who are managing tomcat or the likes.
There isn't a timeout because the people who wrote the Java EE specifications didn't specify a timeout.
You could look at the website for the Java EE JSRs, but I'm pretty sure the discussions about what to include and what not to include and so on aren't made available to the public, so I doubt you would find anything there about why they decided that. Or why they failed to decide it, if you want to look at it that way.
Or you could invite people to speculate about why the designers might have made (or failed to make) that decision. If you're interested in that, just say so.
Author and all-around good cowpoke
Joined: Mar 22, 2000
However, I keep wondering why there isn't a timeout value especially since the hung/stuck thread is such a common problem which can bring down an entire instance.
Properly designed request handling code will NOT ALLOW getting hung or stuck.
Not a common problem in my experience. Timeouts on the client side, enforced by the browser, result in an exception when the connection is closed.
External termination of threads is a touchy subject. So touchy, in fact, that the Java language/core package spec actually retracted certain thread control functions because they could do more harm than good.
Yes, you should be able patch Tomcat to tie timers to processor threads, but then you have to ask what happens if you time out. You can't predict what any given thread is doing. So you're pretty much left with the alternative of killing what might be a sensitive operation. Which, in turn, might not want to be killed because it's in the middle of a network wait, database transaction series, OS interlock or who knows what.
On the whole, the risks outweigh the rewards. The J2EE model is pretty clear on keeping runtimes to a minimum. Certain processes beyond your direct control can obviously interfere with that, especially database operations and external web service requests. Web Service requests usually time out. Database operations are less co-operative that way, but when they get hung, killing the thread won't really help anyway. They hang hard, typically at the network level.
Actual real-world experience is that most of the time you can predict and anticipate whether a function is going to take a long time or not and design the app accordingly. Partly because CPUs are so fast these days that activities are mostly going to finish very quickly indeed or they're going to take a long time and there's not much gray area between them.
Unfortunately, making an app totally bulletproof, whether in terms of threads, memory, or whatever, is prohibitively expensive. I get a LOT of static from management just because I worry about that kind of stuff more than most people, and even I have to give up at some point. Design so that ordinary processing can be done and that reasonable surges won't bring it down (operating continuously at 100% is NOT a virtue in IT - it's a train wreck in the making). And realize that life in an IT shop occasionally gets exciting.
Sunil Bagul wrote:we had same issue of tomcat http stuck threads and we implemented below solution but before kiling thread make sure it is executing custom code
How To Kill Tomcat HTTP Stuck Thread
Java API Docs wrote:
Deprecated.This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior. Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait. For more information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?.
Like I said, externally halting a thread is not something you should do. It can have severe and unpredictable consequences up to and including crashing the entire Tomcat server.
Also, don't let Bear know you've been placing Java code in JSP scriptlets. It makes him surly.