This question already has answers here:
How do servlets work? Instantiation, sessions, shared variables and multithreading
(8 answers)
Closed 6 years ago.
What I know
A web container creates a new thread per request.
What I don't know
Are new servlet objects created per request?
Why I am asking this is to get an idea on how thread synchronization issues can happen if the same servlet object is used for multiple requests.If the web container creates a new servlet object for each new reqest, then I don't see an issue. But if it uses the same servlet object to serve multiple requests, synchronization issues can happen.
How is this handled in a typical java web container?
A web container creates a new thread per request.
No. It reuses a thread from a thread pool.
Are new servlet objects created per request?
No. A servlet is a singleton. Only one instance is created per web app. Your servlet must be thread-safe, since it's called concurrently by several threads. But that' usually easy, because a servlet is typically stateless.
Are new servlet objects created per request ?
By default, Servlet container creates a single servlet instance and will be used to serve all of the requests in a separate thread. So ensure that your servlet class is thread safe (i.e., your servlet class should not hold any stateful data as instance variables, etc..).
Adding to that, Servlet containers create the servlet instance either during the container start-up or upon the first request received.
You can force the container to create the servlet instance by specifying the load-on-startup in web.xml or #WebServlet(urlPatterns="/xyz", loadOnStartup=1)).
It is generally better to load the servlets (unless you have any special requirements) using load-on-startup so that the first request will not hit with the performance.
In general sense servlets are Singletons, however if you map the same servlet class to different URL mappings using different names, you will have that many instances of same servlet.
Mostly servlets are stateless, if you do make them statefull, then be very careful about shared mutability .
Earlier servlet API used to have SingleThreadModel Interface to impose single thread access at one point of time, that way you could serve only one request at a time, However I see this interface is deprecated in recent APIs as it doesn't solve the concurrency issues fully, like static variables etc.
My understanding of servlet instance is, there is only one instance of the servlet which is reused for multiple requests from multiple clients.
My question is, where the servlet container store these instance and how long the life time of the instance.
Thank in advance!
Where --> RAM/Heap (It's an instance).
How long? --> Till servlet destroy() called (OR) JVM killed. You may refer Servlet life cycle documentation for more details
In memory and in accordance with the Servlet Life Cycle. The linked Tutorial says (in part)
Servlet Life Cycle
The life cycle of a servlet is controlled by the container in which the servlet has been deployed. When a request is mapped to a servlet, the container performs the following steps.
If an instance of the servlet does not exist, the web container
a. Loads the servlet class.
b. Creates an instance of the servlet class.
c. Initializes the servlet instance by calling the init method. Initialization is covered in Initializing a Servlet.
Invokes the service method, passing request and response objects. Service methods are discussed in Writing Service Methods.
If the container needs to remove the servlet, it finalizes the servlet by calling the servlet’s destroy method. Finalization is discussed in Finalizing a Servlet.
The scenario of my problem is:
In my servlet I get a large amount of data from somewhere (not relevant). I have to iterate over all this data and put it in an array, convert it to a JSON object and send it to the client side for viewing. If I do this in a single response it takes a very long time to display the results. Hence, I need to do multithreading.
The created thread needs to keep on adding data to the list while the main thread whenever it gets a request (requests for data keep on coming periodically) sends the present available list.
For instance on first request the response sent is : 1 2 3
Second request : 4 5 6 and so on.
Now I come to actual problem : I don't know how to do multithreading in a servlet. I have looked through numerous resources and examples but it only has confused me further. Some examples have created threads right in doGet which I think is very wrong, some have created them in the init() method but I dont know how can I pass parameters and get results from the thread if it is declared in the init method (It cannot be a global variable). Then there are examples of servletContextListener but I havent found anything useful or that makes sense.
Can anyone please guide to me a reliable source or just give me some sort of pseudo code to get a solution to my problem. It would be extremely helpful if the answers are in context with the aforementioned scenario.
Thanks
The created thread needs to keep on adding data to the list while the
main thread whenever it gets a request (requests for data keep on
coming periodically) sends the present available list.
If I got you correct, you like to get some data as background service and make them ready for clients once they request them(sounds like harvesting data).
Well, creating thread in web-apps, or generally stuffs come with managed environment is different, creating a thread implicitly would cause of memory leak.
One good solution would having a ThreadPool(either by container context/ndi or create it manually).
AND it MUST be created in a manageable manner, where you would control it by environment related events.
ContextListener is your friend, having a context listener class, like this.
public class dear_daemon implements ServletContextListener,Runnable{
ExecutorService the_pool;
Thread the_evil;
/*following get invoked once the context is called*/
public void contextInitialized(ServletContextEvent sce){
/*initialize the thread-pool, and run evil thread*/}
/*following get invoked once the context is destroying*/
public void contextDestroyed(ServletContextEvent sce){eviling=false;
/*stop evil(this) thread(first), then destroy thread pool*/
}
volatile boolean eviling=true;
public void run(){
while(eviling){
/*run Runnable instance which do data fetching using thread-pool*/
}
}
}
And register the listener in web.xml
<listener>
<listener-class>dudes.dear_daemon</listener-class>
</listener>
Having a class(runnable) which do the data fetching, and invoke it by evil thread, each instance using one thread.
The ContextLisstener helps you correctly shutdown and manage init and hult events by container, using the same thing with servlet init is possible, but make sure you do the same thing about hulting with destroy method of servlet.
If you like to do thread-thing about it, make sure you are doing things thread-safe since you have one thing to store data(a list).
If any synchronization is needed(for example ordering the fetched data), make sure you are doing it right, or you will face with deadlocks, or low-performance code.
If any(probably) IO action is needed for getting data, note java IO is blocking, so set appreciated read and connection timeouts, or switch to NIO if you can handle complex NIO stuffs.
If applying these changes make the environment complex, and you like to do alternative solutions, you may simply extract the data fetching from web-profile and run it as a external daemon-service or applciation, where the applciation will pass the fetched data to the server context using calling one of your CGI/Servlet.
I was reading about servlet's life-cycle and got this doubt. Can we call servlet's init and destroy method inside overridden servlet's service method like calling any other java method? Will this affect container's actual flow ?
You certainly can call init and destroy from the service method. Depending on what those methods do, i.e. if they actually destroy the servlet, this is probably unwise.
Say, for example, I have a request that comes in and encounters a problem. I think the easiest way to solve this is to call destroy and then init to "restart" the servlet.
My restart takes non-zero time, another request comes in during that time. This request encounters a problem. It also decides to restart the servlet.
You see where this is going...
I would recommend against fiddling with the servlet lifecycle methods and leave that to the container. If you must call those methods then be very wary of thread synchronisation.
As far as affecting the "container's actual flow" - the container has no way of knowing you called the method and that is why requests keep flooding in. The container will be obliviuous to you calling those methods.
Yes, you can call them, but there is no need to do this. This method used by Servlet containers.
You should use this method if you need to for example initialize internal state.
Methods init() and destroy() defaulty are empty and you should override them to take/release resources (for example).
You can call them and it will not affect servlet lifecycle.
you can call those methods no problem.But they are life cycle methods.Whatever the operations performed by the container that is servlet class instantiation and destroy will not happen at that time.
Whenever called by the container only those operations will happen(object instantiation and destroy)
Basically, how long is an instance of a servlet around for? I am kind of guessing it is session scope. However, I suppose it could have some sort of timeout or garbage collection to remove old instances.
a servlet is created when the application starts (it is deployed on the servlet container) or when it is first accessed (depending on the load-on-startup setting)
when the servlet is instantiated, the init() method of the servlet is called
then the servlet (its one and only instance) handles all requests (its service() method being called by multiple threads). That's why it is not advisable to have any synchronization in it, and you should avoid instance variables of the servlet
when the application is undeployed (the servlet container stops), the destroy() method is called.
The lifecycle is well defined, and exposed through lifecycle methods exposed in init, service, and destroy methods of the Servlet.
And, despite what else is being said here, this is all you can count on from the specification. Basically, you get those three methods and a guarantee that Servlets are not thread safe. That a single servlet MAY be simultaneously accessed by one or more requests.
There is nothing in the specification that limits a servlet to one instance the container, if a container decides to, it can get a request, create a servlet, call it's init, then service, then destroy methods, and set it free for garbage collection.
Individual containers have potentially different implementations.
Most containers do create a single instance. But the specification does not guarantee that, so you shouldn't rely on it.
Also, consider something like Google App Engine. GAE is VERY aggressive is continually expiring and shutting down entire web apps that receive no traffic. If you have a lightly traveled site, you can very well expect the entire app to start up, init all of its services, init any load-on-startup servlets, execute the request, and then shut everything down. So, on GAE it's imperative that you have a very fast application startup in order to maintain any semblance of performance.
So, simply, what you can count on is what the specification says. Individual containers may offer different run time experiences.
A Servlet lives as long as the application does.
A servlet is not bound to a session, it is a service object that is instantiated by the container when needed, and typically is kept alive for the full life of the webapp. It typically responds to requests from several clients (and sessions), even concurrent requests.
That's precisely why your servlet code must be thread safe, and you never store in a servlet field some data associated to a request or a session.
A servlet life cycle can be defined as the entire process from its creation till the destruction. The following are the paths followed by a servlet
The servlet is initialized by calling the init () method.
The servlet calls service() method to process a client's request.
The servlet is terminated by calling the destroy() method.
Finally, servlet is garbage collected by the garbage collector of the
JVM.
More here ..
http://www.dzone.com/links/r/java_ee_servlets_life_cycle.html
when i remember correctly servlets live as Singletons in the Servlet Container (e.g. Tomcat). Im not sure if the first instantiation is lazy, meaning that the Servlet gets constructed only if needed, but im guessing one could check this in the corresponding Servlet Container's Classloader sources.
The Servlet's lifecycle ends and it's destroy() method gets called when the Servlet Container is shut down.
You can check this easily by setting up breakpoints or logging in the appropriate init() and destroy() methods and Constructor then just check when the code gets executed in your debugger/logfile.
hope that helped.
References:
Tomcat's Classloader howto
The servlet (its one and only instance) will handle n number of request in the fashion of separate single thread for every client ie where CGI limitation is overcomed
A servlet object lives in heap of serverside machine as long as application is undeployed or servletConatiner is shutdown the servlet object will not die.
Technically : servletcontainer holds servletobject and servletobject holds servletConfig object
Servletcontainer can only call the 3 methods of its life cycle 1)init() 2)service() 3)destroy()
Actually the Servlet may be destroyed and recreated at any time ! So the other answers kinda describe the whole lifecycle but miss this important detail. From the servlet specification:
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.
[...]
Once the destroy method is called on a servlet instance, the container may not route
other requests to that instance of the servlet. If the container needs to enable the
servlet again, it must do so with a new instance of the servlet’s class.
The lifecycle of a typical servlet running on Tomcat might look something like this:
1.Tomcat receives a request from a client through one of its connectors.
2.Tomcat maps this request to the appropriate Engine for processing. These Engines are contained within other elements, such as Hosts and Servers, which limit the scope of Tomcat's search for the correct Engine.
3.Once the request has been mapped to the appropriate servlet, Tomcat checks to see if that servlet class has been loaded. If it has not, Tomcat compiles the servlet into Java bytecode, which is executable by the JVM, and creates an instance of the servlet.
4.Tomcat initializes the servlet by calling its init method. The servlet includes code that is able to read Tomcat configuration files and act accordingly, as well as declare any resources it might need, so that Tomcat can create them in an orderly, managed fashion.
5.Once the servlet has been initialized, Tomcat can call the servlet's service method to process the request, which will be returned as a response.
6.During the servlet's lifecycle, Tomcat and the servlet can communicate through the use of listener classes, which monitor the servlet for a variety of state changes. Tomcat can retrieve and store these state changes in a variety of ways, and allow other servlets access to them, allowing state to be maintained and accessed by various components of a given context across the span of a single or multiple user sessions. An example of this functionality in action is an e-commerce application that remembers what the user has added to their cart and is able to pass this data to a checkout process.
7.Tomcat calls the servlet's destroy method to smoothly remove the servlet. This action is triggered either by a state change that is being listened for, or by an external command delivered to Tomcat to undeploy the servlet's Context or shut down the server.
Reference:
https://www.mulesoft.com/tcat/tomcat-servlet
life cycle of servlet >
1) load the class.
2) instantiate the servlet.
3) servlet container construct the servlet config interface.
4) container call the init() and pass the servlet config object.
5) httpRequest and httpResponse object created.
6) container call the service() and pass the httpRequest and httpResponse object as argument.
7) process the service method.and if have any other request then follow the step 4 again.
8) other wise container call the distroy().
The servlet's container is attached to a web server that listens for HTTP or HTTPS requests on a certain port number (port 8080 is usually used during development and port 80 in production). When a client (user with a web browser) sends an HTTP request, the servlet container creates new HttpServletRequest and HttpServletResponse objects (for every new request) and passes them through any defined Filter chain and, eventually, the Servlet instance.
In the case of filters, the doFilter() method is invoked. When its code calls chain.doFilter(request, response), the request and response continue on to the next filter, or hit the servlet if there are no remaining filters.
In the case of servlets, the service() method is invoked(by multiple threads for different request). By default, this method determines which one of the doXxx() methods to invoke based off of request.getMethod(). If the determined method is absent from the servlet, then an HTTP 405 error is returned in the response.
The request object provides access to all of the information about the HTTP request, such as its headers and body. The response object provides the ability to control and send the HTTP response the way you want by, for instance, allowing you to set the headers and the body (usually with generated HTML content from a JSP file). When the HTTP response is committed and finished, both the request and response objects are recycled and made for reuse.