Unlocking Tomcat: A Deep Dive into Java Application Server Architecture

Java Application Server Classification

Since the early 2000s, Java application servers have progressed through three main stages: traditional J2EE application servers, servlet containers/Web servers, and reactive micro‑service platforms.

1. J2EE Application Servers

These servers fully implement the J2EE specifications, supporting EJB, JMS, JTA, Servlet, JSF, and more. They offer extensive configuration and optimization capabilities, making them suitable for large, centralized enterprise applications. Examples include IBM WebSphere (commercial) and JBoss (open‑source, a reduced‑feature version of the commercial offering).

2. Servlet Containers and Web Servers

While historically part of larger J2EE servers, servlet containers such as Tomcat, Resin, Jetty, and Undertow have become the dominant components for modern web applications. They provide the HTTP service layer, leaving business logic to lightweight frameworks like Spring Boot. Tomcat remains the most widely used, with Jetty and Undertow serving embedded or specialized scenarios.

3. Reactive Micro‑service Platforms

These platforms bypass traditional servlet specifications to provide high‑throughput HTTP services directly. Examples include Vert.x and Play Framework, which are designed for event‑driven, high‑concurrency workloads. The article focuses on servlet‑based solutions, noting that reactive options are less common in the current Chinese market.

Servlet Container Working Principle

A servlet container provides the core HTTP service for web applications and SOA. It consists of two main parts: the connector (handling I/O) and the container (implementing the Servlet specification).

The connector reads network requests, converts them into Servlet‑compliant Request objects, and forwards responses to the client. It abstracts protocol differences (HTTP, AJP, HTTPS) so the container always works with a standard request object.

Parse deployment descriptors (web.xml) or annotations to build internal request handling components.

Receive calls from the connector (mapping is performed by the connector).

Process requests according to the Servlet specification, including filter chains.

The connector typically uses two thread pools: one for accepting connections and another for processing requests. The mapping result is a specific Servlet, not an entire web application.

Tomcat Components and Request Process

1. Core Components

Tomcat’s architecture includes a naming service for component management, the Coyote connector, and the Jasper JSP engine. The top‑level Catalina implements the container, while Engine‑Host‑Context‑Wrapper forms a hierarchical structure:

Engine : the overall container.

Host : virtual host support.

Context : a single web application.

Wrapper : an individual servlet within the context.

Tomcat supports HTTP, AJP, and HTTP/2 at the application layer, and NIO, NIO2, and APR at the transport layer (BIO is deprecated). Thread pools are divided into acceptor and worker pools, with the worker pool size tuned based on benchmark testing.

2. Servlet Container Sub‑components

Key sub‑components include HostConfig (scans web apps and creates Context objects) and ContextConfig (processes servlet specifications, creates servlets and filters). Tomcat also provides a Valve mechanism, similar to servlet filters but with deeper integration into the server lifecycle.

3. Request Processing Flow

The request flow follows a simple sequence: the connector receives the request, the mapper determines the target servlet, the wrapper invokes the servlet, and any configured filters or valves process the request/response. A timing diagram (illustrated in the original slides) shows the interaction between the connector, mapper, and servlet.

Tomcat Optimization Overview

Performance tuning focuses on four main areas: thread pools, protocols, JVM settings, and I/O configuration.

Thread Pools : Separate acceptor and worker pools; acceptor size usually matches CPU cores, while worker pool size should be determined by load testing.

Protocols : Enable HTTP GZIP compression, consider using APR for native performance, and configure AJP when a front‑end web server (e.g., Apache) is present.

JVM : Adjust heap size and select appropriate garbage‑collection algorithms based on throughput vs. latency requirements.

I/O : Use NIO (default) or APR; newer Tomcat versions have dropped BIO support.

Effective tuning requires benchmarking in the target environment, as optimal settings vary with hardware, workload, and application characteristics.