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.
Customer surveys are for companies who didn't pay proper attention to begin with.
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.