Backend Development 20 min read

Understanding Tomcat: Architecture, Components, Lifecycle, Connectors, and Asynchronous Servlets

This article provides a comprehensive overview of Tomcat, covering its role as a Java web server, internal components such as Server, Service, Connector and Container, lifecycle management, deployment methods, connector implementations (BIO, NIO, APR), Comet support, and asynchronous servlet processing, with code examples for thread handling.

Top Architect
Top Architect
Top Architect
Understanding Tomcat: Architecture, Components, Lifecycle, Connectors, and Asynchronous Servlets

What is Tomcat

Tomcat is an open‑source Java web application server that implements part of the Java EE specifications, including Servlet, JSP, JSTL, and WebSocket. It provides only the web container portion of Java EE, unlike full‑stack servers such as GlassFish.

Servlet Container

Tomcat is composed of several key components:

Server : the top‑level object that manages multiple Services and listens on the shutdown port.

Service : groups a set of Connectors with a single Container hierarchy, each Service runs in the same JVM.

Connector : bridges external protocols (HTTP, AJP) to the internal Container, listening on configured ports.

Container (Catalina) : the core servlet container that manages the lifecycle of servlets.

Loader : wraps a Java ClassLoader to load classes for web applications.

Realm : provides authentication and role management for web apps.

JMX : enables remote monitoring and management of Tomcat components.

Jasper : the JSP engine that compiles JSP pages into servlet classes.

Pipeline and Valve : a chain of processing elements that can intercept requests and responses.

Naming : JNDI support for resource lookup and configuration.

Container Hierarchy

The Container hierarchy consists of Engine → Host → Context → Wrapper. The Engine is the top‑level servlet container, Hosts represent virtual hosts, Contexts correspond to individual web applications, and Wrappers encapsulate individual servlets.

Lifecycle Management

Tomcat defines twelve lifecycle states (New, Initializing, Initialized, Starting, Started, etc.) and corresponding methods (initInternal, startInternal, stopInternal, destroyInternal). State transitions trigger events that listeners can react to, and the configuration files (e.g., server.xml ) can declare listeners for custom handling.

Startup Process

Startup begins with the start.sh script, which invokes Bootstrap.main() . The Bootstrap loads and starts the Catalina class, which parses server.xml via Digester , creates the container hierarchy, and calls StandardServer.init() and StandardServer.start() . The server then listens on the shutdown port (default 8005) for termination commands.

Web Application Deployment

Deployment can be configured by:

Defining <Host> with an appBase attribute in server.xml (default $catalina.base/webapps/ ).

Defining <Context> with a docBase to point to the application location.

Placing custom Context XML files under $catalina.base/EngineName/HostName/ .

During startup, HostConfig scans the appBase directory, parses each application's META-INF/context.xml , creates a StandardContext , and adds it to the Host.

Connector Types

Tomcat supports three connector implementations, selectable in server.xml :

BIO (Java IO): blocking I/O.

NIO (Java NIO): non‑blocking I/O with selector‑based multiplexing.

APR (Apache Portable Runtime): native I/O via JNI, offering features like sendfile and epoll .

Each connector differs in support for I/O multiplexing, thread usage, and request/response handling characteristics.

NIO Processing Classes

The NIO connector uses several core classes:

Acceptor : accepts new connections and registers them with a PollerEvent .

Poller : monitors registered sockets for readability using a Selector and dispatches ready events to a thread pool.

CoyoteAdapter : adapts the connector to the container, creating Request and Response objects and invoking the pipeline.

Mapper : resolves URL mappings to the appropriate servlet.

Key NIO connector parameters (e.g., thread pool size, poller settings) are shown in the accompanying diagram.

Comet Support

Comet enables server‑push by keeping an HTTP connection open. In Tomcat, a servlet that implements CometProcessor receives callbacks:

Begin : initialize request/response objects.

Read : data is available for reading.

End : connection closed or data stream finished.

Error : an exception or timeout occurs.

Proper handling includes closing the CometEvent and ensuring thread‑safety.

Asynchronous Servlet

Traditional servlet processing ties a request thread to the entire request‑response cycle, which can exhaust thread pools for long‑running operations. Asynchronous servlets allow the container thread to return to the pool after calling request.startAsync() , while the business logic continues in a separate thread that later completes the response via the saved AsyncContext .

Lifecycle callbacks such as onStartAsync , onComplete , onError , and onTimeout enable custom handling of async events.

Code Example: Parallel Container Startup

List<Future<Void>> results = new ArrayList<Future<Void>>();
for (int i = 0; i < children.length; i++) {
    results.add(startStopExecutor.submit(new StartChild(children[i])));
}
boolean fail = false;
for (Future<Void> result : results) {
    try {
        result.get();
    } catch (Exception e) {
        log.error(sm.getString("containerBase.threadedStartFailed"), e);
        fail = true;
    }
}

This snippet demonstrates how Tomcat can start child containers concurrently using a thread pool and collect any failures.

Conclusion

The article consolidates essential knowledge about Tomcat’s architecture, component responsibilities, lifecycle, deployment strategies, connector options, and advanced features such as Comet and asynchronous servlets, providing a solid reference for backend developers and architects.

JavaConnectorBackend Developmentweb serverTomcatAsynchronous ServletServlet Container
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.