Menu
I'm writing a servlet, which is executed in Java servlet container (eg, JBoss, Jetty, Tomcat, GlassFish).
What are the reasons for a servlet container to interrupt the thread running my HTTP request handler? Will it do that only when shutting down? Will it do that when the client is not responding?
Is it standardized, or is any container free to do what he wishes?
To clarify, I'm not talking about interrupting new threads that I create, only on the servlet container's threads my requests are running on. (Although it'll be interesting if you'll mention what happens to new threads in the answer).
523
The servlet container provides the servlet with easy access to properties of the HTTP request, such as its headers and parameters. When a servlet is called, such as when it is specified by URL, the Web server passes the HTTP request to the servlet container. The container, in turn, passes the request to the servlet.
Most servlet threading problems occur when two or more threads make changes to the same resource. This might mean that two threads try to modify a file, or perhaps several threads all update the value of a shared variable at the same instant. This causes unpredictable behavior and can be very hard to diagnose.
By default, servlets are not thread-safe. The methods in a single servlet instance are usually executed numerous times simultaneously up to the available memory limit. Each execution occurs in a different thread, though only one servlet copy exists in the servlet engine.
A Java servlet container / web server is typically multithreaded. That means, that multiple requests to the same servlet may be executed at the same time.
What are the reasons for a servlet container to interrupt the thread running my HTTP request handler?
That depends on the container itself. It's indeed not standardized in the servlet specification.
Will it do that only when shutting down?
Seems one of the most obvious reasons. Local tests taught me that at least Tomcat 7.0.22 and Glassfish 3.1.1 will abort all the servlet's processing immediately without letting them to continue their task. No exceptions will be thrown at that point.
Will it do that when the client is not responding?
Only when the request headers are not fully arrived. There's a container-specific timeout on the socket connection which is usually 60 seconds. But if the request headers are not fully arrived, then your servlet method won't be entered anyway. Only if the request headers are fully arrived, then your servlet method will be entered.
Then, inside the servlet method; if the client has supplied a request body (e.g. POST) and your servlet's code starts reading the request body by for example request.getParameter() or request.getInputStream(), then it will throw IOException when the client has aborted sending the request body at that point. On the other hand, when you write to the response (and flush/commit it), then also an IOException will be thrown when the client aborts the connection at that point. You can if necessary put it in a try-catch, but you can't do anything more with it than just logging. The usefulness of those loggings is highly quesitonable and will likely only clutter your server logs.
106
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
