I'm working on an application that starts several threads from a Servlets' init() method. These threads check periodically for the availability of a local map servers by sending a request and examining the response code.
Lately we have been seeing way too many of this type of request coming to the map servers and I'm wondering if some threads from a previous startup could still be alive.
The Servlets destroy() method calls cancel() on the threads so I think the only possibility is that a non-typical shutdown or crash would somehow leave threads active.
It would be good if you make the threads (threads that you are starting from init of the servlet)as deamon.
Deamon Threads will be dropped automatically when the JVM exits, but is that really what we want in this case? The Thread may be part way through sending a request to the map server, can the map server recover from this?
posted 11 years ago
William : The Servlets destroy() method calls cancel() on the threads so I think the only possibility is that a non-typical shutdown or crash would somehow leave threads active.
Making the thread daemon would at least help in this situation.
I was wondering if this situation could be caused by multiple instances of the servlet being created by Tomcat. The web.xml specifies one initial instance but could Tomcat be creating more? Each instance of this servlet would start another thread to do the mapper checking.
This scenario does not seem too likely. Given the number of requests, there would have to be a hell of a lot of instances of the servlet. One servlets map checker thread sends a request every 30min. We are seeing an average of 5 requests per minute which would equate to something like 150 servlet instances.
Tomcat follows the spec so it will only create one (unless your servlet implements SingleThreadModel). The spec does allow it to take servlets out of service and put them back in when needed. This would cause your destroy and init methods to be called and is a good reason to use a contextListener to start and stop these threads instead of a servlet.
But, when the JVM stops, all threads stop.
SRV.2.2 Number of Instances The servlet declaration which is part of the deployment descriptor of theWeb application containing the servlet, as described in Chapter SRV.13, �Deployment Descriptor�, controls how the servlet container provides instances of the servlet. For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration. However, for a servlet implementing the SingleThreadModel interface, the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance.
[ September 14, 2007: Message edited by: Ben Souther ]
SRV.2.3.4 End of Service The servlet container is not required to keep a servlet loaded for any particular period of time. A servlet instance may be kept active in a servlet container for a period of milliseconds, for the lifetime of the servlet container (which could be a number of days, months, or years), or any amount of time in between. When the servlet container determines that a servlet should be removed from service, it calls the destroy method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state. For example, the container may do this when it wants to conserve memory resources, or when it is being shut down. Before the servlet container calls the destroy method, it must allow any threads that are currently running in the service method of the servlet to complete execution, or exceed a server-defined time limit.
is why you should code your servlets as if the container can create as many as it likes and why you should use ContextListeners when available for startup and shutdown tasks like this.
Thanks to all who have contributed to this thread about threads. I'm convinced that the problem is not caused by some sort of aberrant threading behavior. Not only does it not make sense from the Java perspective but in the last couple of hours I have shut down Tomcat on the three suspect machines and there was no diminution of the mapper requests. So the requests must be coming from somewhere out of our development/production environment.
Thanks again to all who took a stab at this problem. I always learn something about Java when I post to this board even if my original problem is not solved.