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.
Is there any scenario where this is possible?
Thanks for any help or ideas,
This does not mean that your pending map server requests have been properly shut down. you should ensure that the destroy() method can properly shut down the map server request.
If you read through the java.lang.Thread JavaDocs you will see lots of methods such as stop() that have been deprecated because of the difficulty in stopping a running Thread cleanly.
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?
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.
Any thoughts on this?
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 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.