Tomcat Architecture Overview

Apache Tomcat operates as a robust Servlet container, managing the lifecycle of web applications and handling client requests. Its architecture is fundamentally divided into two core modules: the Connector (Coyote) and the Container (Catalina). This separation of concerns allows Tomcat to decouple network communication protocols from application processing logic.

The Connector (Coyote)

The Connector is responsible for managing external connections. It acts as the bridge between the client and the server's container. Its primary duties include:

• Endpoint: Handles low-level I/O operations, accepting TCP connections. Tomcat supports various I/O models like NIO (non-blocking I/O) and APR (Apache Portable Runtime).
• Processor: Parses the specific application layer protocol (HTTP or AJP), converting byte streams into Request objects.
• Adapter: Bridges the protocol-specific Request to the standard ServletRequest interface, enabling the Container to process requests uniformly regardless of the incoming protocol.

The Container (Catalina)

Catalina manages the processing of requests once they have been parsed by the Connector. It uses a hierarchical structure of containers to delegate responsibility:

• Engine: The top-level container representing the entire Catalina Servlet engine.
• Host: Represents a virtual host, capable of running multiple web applications under different domain names.
• Context: Represents a specific web application, corresponding to a context path.
• Wrapper: Represents an individual Servlet, wrapping the actual instance of the Java class.

Request Processing and Pipeline Design

When a request arrives, the Connector creates Request and Response objects and passes them to the Container. To facilitate flexible processing, Tomcat employs the Pipeline-Valve pattern (a variation of the Chain of Responsibility).

Each container (Engine, Host, Context, Wrapper) has a Pipeline. A Pipeline contains a series of Valves. When a request enters a container, it flows through its Pipeline, executing each Valve in order. The final Valve in every Pipeline (StandardValve) is responsible for invoking the next child container's Pipeline.

Simulating the Pipeline Mechanism

Below is a simplified simulation demonstrating how a processing chain works. This logic mirrors how Tomcat filters and processes requests before reaching the Servlet.

import java.util.ArrayList;
import java.util.List;

// The context object passed through the chain
class RequestContext {
    private String payload;
    private boolean valid = true;

    public RequestContext(String payload) { this.payload = payload; }
    public String getPayload() { return payload; }
    public void setPayload(String payload) { this.payload = payload; }
    public boolean isValid() { return valid; }
    public void invalidate() { this.valid = false; }
}

// Interface for the processing unit (Valve)
interface ProcessingValve {
    void invoke(RequestContext context, ProcessingPipeline pipeline);
}

// The Pipeline orchestrates the flow
class ProcessingPipeline {
    private List<ProcessingValve> valves = new ArrayList<>();
    private int currentIndex = 0;

    public void addValve(ProcessingValve valve) {
        valves.add(valve);
    }

    public void executeNext(RequestContext context) {
        if (currentIndex < valves.size()) {
            ProcessingValve currentValve = valves.get(currentIndex);
            currentIndex++;
            currentValve.invoke(context, this);
        }
    }
}

// Concrete Valve: Security Check
class SecurityValve implements ProcessingValve {
    @Override
    public void invoke(RequestContext context, ProcessingPipeline pipeline) {
        System.out.println("[SecurityValve] Checking request validity...");
        if (context.getPayload().contains("<script>")) {
            System.out.println("[SecurityValve] Malicious content detected. Blocking request.");
            context.invalidate();
            return; // Stop processing
        }
        pipeline.executeNext(context);
    }
}

// Concrete Valve: Logging
class LoggingValve implements ProcessingValve {
    @Override
    public void invoke(RequestContext context, ProcessingPipeline pipeline) {
        System.out.println("[LoggingValve] Request payload: " + context.getPayload());
        pipeline.executeNext(context);
    }
}

public class TomcatPipelineDemo {
    public static void main(String[] args) {
        ProcessingPipeline pipeline = new ProcessingPipeline();
        pipeline.addValve(new SecurityValve());
        pipeline.addValve(new LoggingValve());

        RequestContext req1 = new RequestContext("Hello World");
        System.out.println("--- Processing Request 1 ---");
        pipeline.executeNext(req1);

        RequestContext req2 = new RequestContext("<script>alert(1)</script>");
        System.out.println("\n--- Processing Request 2 ---");
        pipeline.executeNext(req2);
    }
}

JSP Compilation (Jasper)

Tomcat's Jasper engine is responsible for translating JSP files into Servlets. This process occurs either at startup (pre-compilation) or upon the first request (runtime compilation). The generated Servlet extends HttpJspBase and implements the _jspService method, where HTML template text is converted into out.write() calls.

Server Configuration

Tomcat's behavior is controlled primarily through server.xml.

• Server: The root element. It contains a port attribute for the shutdown command.
• Service: Associates one or more Connectors with a single Engine.
• Executor: Defines a shared thread pool that connectors can use to handle requests, improving resource management.
• Connector: Configures the protocol (HTTP/AJP), port, and connection settings like maxThreads and acceptCount.

Performance Tuning via Connectors

To optimize throughput, adjust the thread pool within the Connector definition:

<Connector port="8080" protocol="HTTP/1.1"
           maxThreads="500"
           minSpareThreads="50"
           acceptCount="200"
           connectionTimeout="20000" />

Tomcat Clustering and Session Management

For high availability, multiple Tomcat instances can be placed behind a load balancer like Nginx.

Load Balancing Strategies

• Round Robin: Distributes requests evenly across servers.
• Weighted Round Robin: Routes more traffic to servers with higher hardware specs.
• IP Hash: Ensures requests from a specific IP always go to the same server, maintaining session stickiness.

Session Sharing Solutions

In a cluster, sessions must be accessible across nodes.

1. Session Replication: Tomcat broadcasts session changes to all cluster members using the <Cluster> element in server.xml. This is suitable for small clusters due to network overhead.
2. Persistent Stores: Storing sessions in a database or Redis.
3. SSO (Single Sign-On): Centralizing authentication so session state is less critical to individual app servers.

JVM Tuning

Performance heavily relies on JVM memory settings. Configuration is typically set in catalina.sh or setenv.sh.

JAVA_OPTS="-server -Xms2g -Xmx2g -XX:NewSize=512m -XX:MaxNewSize=512m -XX:+UseG1GC"

• -Xms and -Xmx define the initial and maximum heap size. Setting them equal prevents heap resizing overhead.
• -XX:NewRatio controls the ratio of Young Generation to Old Generation.
• Garbage Collector selection (G1GC, ZGC) depends on latency requirements.

Security Best Practices

• Disable Shutdown Port: Set <Server port="-1"> to prevent remote shutdown commands.
• Enable HTTPS: Configure an SSL certificate in the Connector.
• Remove Default Apps: Delete ROOT, docs, and examples directories to reduce attack surface.