A birds-eye view on “how web servers work?”

Many times we wonder that how a web container/ web-server (e.g. tomcat or jboss) works? How they handle the incoming http requests coming from all over the world? What are the things which make it happen behind the scene? How java servlet API (i.e. classes like ServletContext, ServletRequest, ServletResponse and Session) fit into picture? These are very important questions/concepts you must know if you are a web-application developer or you aspire to be. In this post, I will try to find out answers for some of above question, if not all. Remain concentrated from here.

Sections in this post:

What are web server, application server and web container?
What are Servlets? How they help?
What is ServletContext? Who creates it?
Where ServletRequest and ServletResponse fits into life cycle?
How Session is managed? Know the cookie?
How thread safety should be ensured?

What are web server, application server and web container?

I will first talk about web servers and application servers. Let me say it in one liner,

“Historically they were different, but these two previously distinct categories slowly merged, and now should be seen as one entity in most of the cases and uses.”

In early days of the Mosaic browser (often described as the first graphical web browser) and hyper-linked content, there evolved a new concept “web server” that served static web page content and images over HTTP protocol. Simple enough. In these days, most of the content was static, and the HTTP 1.0 protocol was just a way to ship files around. But soon the web servers evolved to have CGI capabilities. It means effectively launching a process on each web request to generate dynamic content. By this time, HTTP protocol also matured and web servers became more sophisticated with additional functionality like caching, security, and session management. As the technology further matured, we got company-specific java-based server-side technology from Kiva and NetDynamics, which eventually all merged into JSP (java server pages), which we still use in most applications development today.

web server application server

This was about web-servers. Now let’s talk about application servers.

In a parallel category, the application servers had evolved and existed for a long time. Some companies delivered products for Unix like Tuxedo (transaction-oriented middleware), TopEnd, Encina that were philosophically derived from Mainframe application management and monitoring environments like IMS and CICS. Most of these products specified “closed” product-specific communications protocols to interconnect “fat” clients to servers. In 90′s, these traditional app server products began to embed basic HTTP communication capability, at first via gateways. And sooner the lines began to blur between these two categories.

By the time, web servers got more and more mature with respect to handling higher loads, more concurrency, and better features; Application servers started delivering more and more HTTP-based communication capability. And all this resulted into very thin line between web-servers and application servers.

At this point the line between “app server” and “web server” is a fuzzy one. But people continue to use the terms differently, as a matter of emphasis.

When someone says “web server” you often think HTTP-centric, web UI oriented applications. When someone says “Application server” you may think “heavier loads, enterprise features, transactions and queuing, multi-channel communication (HTTP + more)”. But mostly it is the same product that serves both sets of requirements now-a-days.

That’s all about web servers and application servers. Now move towards third term i.e. web container.

web server servlet container

Web container, specially in java, should be refer to servlet container. A servlet container is the component of a web server that interacts with java servlets. A web container is responsible for managing the life-cycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights and many more such services. Basically, putting together all above facts, servlet container is the runtime environment where your servlet run and it’s life cycle is maintained.

What are Servlets? How they help?

In java, servlets enable you to write server side components which help in generating dynamic content, based on request. Factually, Servlet is an interface defined in javax.servlet package. It declares three essential methods for the life cycle of a servlet – init(), service(), and destroy(). They are implemented by every servlet(either defined in SDK or user-defined) and are invoked at specific times by the server during it’s life cycle.

Servlet classes are loaded to container by it’s class loader dynamically either through lazy-loading or eager loading. Each request is in its own thread, and a servlet object can serve multiple threads at the same time. When it is no longer being used, it is garbage collected by JVM.

Lazy loading servlet

Lazy Loaded Servlet1Lazy Loaded Servlet

Eager loading servlet

Eagerly Loaded Servlet1Eagerly Loaded Servlet

What is ServletContext? Who creates it?

When the servlet container starts up, it will deploy and load all web-applications. When a web application gets loaded, the servlet container will create the ServletContext once per application and keep in server’s memory. The webapp’s web.xml will be parsed and every Servlet, Filter and Listener found in web.xml will be created once and kept in server’s memory as well. When the servlet container shuts down, it will unload all web applications and the ServletContext and all Servlet, Filter and Listener instances will be trashed.

As per java docs, ServletContext defines a set of methods that a servlet uses to communicate with its servlet container, for example, to get the MIME type of a file, dispatch requests, or write to a log file. In the case of a web application marked “distributed” in its deployment descriptor, there will be one context instance for each virtual machine. In this situation, the context cannot be used as a location to share global information (because the information won’t be truly global). Use an external resource like a database instead.

Where ServletRequest and ServletResponse fits into life cycle?

The servlet container is attached to a webserver which listens on HTTP requests on a certain port number, which is usually 80. When a client (user with a web-browser) sends a HTTP request, the servlet container will create new HttpServletRequest and HttpServletResponse objects and pass it through the methods of the already-created Filter and Servlet instances whose URL-pattern matches the request URL, all in the same thread.

The request object provides access to all information of the HTTP request, such as the request headers and the request body. The response object provides facility to control and send the HTTP response the way you want, such as setting headers and the body (usually with HTML content from a JSP file). When the HTTP response is committed and finished, then both the request and response objects will be trashed.

How Session is managed? Know the cookie?

When a client visits the web-app for the first time and/or the HttpSession is to be obtained for the first time by request.getSession(), then the servlet container will create it, generate a long and unique ID (which you can get by session.getId()) and store it in server’s memory. The servlet container will also set a Cookie in the HTTP response with JSESSIONID as cookie name and the unique session ID as cookie value.

As per the HTTP cookie specification (a contract a decent web browser and webserver has to adhere), the client (the web browser) is required to send this cookie back in the subsequent requests as long as the cookie is valid. The servlet container will determine every incoming HTTP request header for the presence of the cookie with the name JSESSIONID and use its value to get the associated HttpSession from server’s memory.

The HttpSession lives until it has not been used for more than the time, a setting you can specify in web.xml, which defaults to 30 minutes. So when the client doesn’t visit the web application anymore for over 30 minutes, then the servlet container will trash the session. Every subsequent request, even though with the cookie specified, will not have access to the same session anymore. The servletcontainer will create a new one.

Existing Session

Existing session

New Session

New session

On the other hand, the session cookie on the client side has a default lifetime which is as long as the browser instance is running. So when the client closes the browser instance (all tabs/windows), then the session will be trashed at the client side. In a new browser instance the cookie associated with the session won’t be sent anymore. A new request.getSession() would return a brand new HttpSession and set a cookie with a brand new session ID.

How thread safety should be ensured?

You should now have learned that Servlets and filters are shared among all requests. That’s the nice thing of Java, it’s multi-threaded and different threads (i.e. HTTP requests) can make use of the same instance. It would otherwise have been too expensive to recreate it on every request.


But you should also realize that you should never assign any request or session scoped data as an instance variable of a servlet or filter. It will be shared among all other requests in other sessions. That’s thread-unsafe! The below example illustrates that:

public class MyServlet extends HttpServlet 
	private Object thisIsNOTThreadSafe; //Don't to this
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException 
		Object thisIsThreadSafe;

		thisIsNOTThreadSafe = request.getParameter("foo"); // BAD!! Shared among all requests!
		thisIsThreadSafe = request.getParameter("foo"); // OK, this is thread safe.

Do not do this. It will result in a bug in software.

That’s all on this topic. Stay tuned for more such posts. Better subscribe the email news letter to get the notification in your inbox.

Happy Learning !!

Recommended link(s):



I have 7 Years of rich experience in java technology. This has only increased my hunger to learn more. In this blog, i will be writing on different topics occasionally, and would love to engage in some meaningful serious discussions with you folks.

You may also like...

29 Responses

  1. Deepak Agrawal says:

    Very nice post. Keep it up.

  2. Chaudhary says:


  3. shashank says:

    HI Lokesh,
    You said in your article that “The webapp’s web.xml will be parsed and every Servlet, Filter and Listener found in web.xml will be created once and kept in server’s memory as well.”.Is it that there can be only one instance of servlet,filter and listener classes created(that too only at server startup) and all the threads will make use of that one instance only….

    can you also tell what each thread’s run method logic contains??


    • shashank says:

      If at all servlet class is singleton,what is the point of multithreading where in the threads run concurrently (but indeed waiting for locks to be released by other threads) ……Also wanted to know if at all the methods in the servlet class are synchronised or atleast critical section is synchronised….

      • Lokesh Gupta says:

        Shashank, if you look at servlets, you will notice that they are stateless. They do not store data related to individual http requests at instance level. All they do is to call application logic inside doXXX() methods.

    • Lokesh Gupta says:

      Servlets are created once per container. You can choose eager loading s lazy loading using “load on startup” param. All threads simply execute doGet() or doPost() methods using normal synchronization semantics.

      • shashank says:

        My question is (Consider a big scenario) if there are 100 requests(100 threads)at a time which are waiting to be served by a single servlet,then only request is being served at a point of time,where is the true concurrency

        • Lokesh Gupta says:

          Threads do not execute in sequence. They execute concurrently only. At a time, single servlet will be serving 100s of requests concurrently. And please keep in mind that singleton does not mean sequential execution.

          • shashank says:

            Basically if you need to call a method(doget or dopost which are synchronised) in servlet class and as most of the logic is encpsulated in those methods,then other requests has to wait until the current request is served(ie until lock on doget or dopost is released)

  4. Dinh Tien LUyen says:

    nice post

  5. Abhay says:

    Hi Lokesh,

    A nice Blog. Could you please share some docs or pointers where I can start creating my own web services based applications

  6. Ragini says:


  7. krishna chavhan says:

    Thanks Lokesh!! for One more nice post with pictorial representation.

  8. Shoheb says:

    I have one question. If my browser is requesting same page/URL for multiple times (Something like keep pressing f5 for 3 to 4 time) then which response will be displayed on my browser. The one which comes first or the one which comes last?

  9. Ragini says:

    I have always read a lot about Servlets supporting multithreading. My only concern in to understand how the multiple requests are handled by the servlet. If you can explain this in a bit more detail it would be a great help.


    • Lokesh Gupta says:

      There is absolutely no hidden concept. It’s pure simple multi-threading concept which we know in java. We have a service() method in servlet which all threads execute in their own run() method. Plain and simple.

  10. Krunal Patel says:

    Nice post Lokesh, but i want to more clear about web-server and application server. Now a day’s we are using tomcat to run our local application so can we say that tomcat have both features like web server and app-server? Thanks in advance

    • Lokesh Gupta says:

      Krunal, good question. Let me make it clear with one statement. An application server is which implements all (or most) of the J2EE specifications. [Link: http://docs.oracle.com/javaee/5/api/overview-summary.html

      Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. And it omits most of the J2ee specific standard implementations. So, it should be referred as "Web server" or "Servlet container". [http://tomcat.apache.org/]. I am saying “it should be”. The reason is, if used with plugins and add ons, you can achieve any functionality in Tomcat itself which you get in full fledged application servers. For example, you can use openejb [http://openejb.apache.org/apache-tomee.html] to deploy your EJBs in tomcat. So, with add ons tomcat is application server. Without add ons, tomcat is servlet container or web server.

      An good example of complete application server is JBOSS which has implicit support for EJBs and JMS also (JSP and servlet also).

  11. Rahul Gupta says:

    Innovative mean to express thoughts, Very nice Post !!!

  12. Gaurav says:

    Your posts are really good sir…. Keep sharing…

  13. Anil jaguri says:

    Thanks Lokesh, I haven’t yet gone throught it but will read the full blog this weekend. A very good topic for me.

    Thanks much.

  1. October 9, 2013

    [...] Many times we wonder that how a web container/ web-server (e.g. tomcat or jboss) works? How they handle the incoming http requests coming from all over the world? What are …  [...]

  2. November 21, 2013

    [...] A birds-eye view on “how web servers work?” [...]

Note:- In comment box, please put your code inside [java] ... [/java] OR [xml] ... [/xml] tags otherwise it may not appear/post as intended.

Want to ask any question? Or suggest anything?