Request Flow in Tomcat

In modern microservices architectures, user requests originate from various clients like mobile apps or web browsers. These requests are typically routed to backend services. For instance, consider a setup with Server A and Server B, where Server A forwards requests to Server B. This process involves understanding how Tomcat handles such inter-service routing.

Application Deployment Methods

Tomcat supports three primary methods for deploying web applications:

1. WAR File Deployment: Packaging the application as a WAR file.
2. Directory Deployment: Using an unpacked directory structure.

Typically, applications are deployed by placing WAR files or directories in the webapps folder of Tomcat. Configuration in server.xml might look like:

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
           prefix="localhost_access_log" suffix=".txt"
           pattern="%h %l %u %t &quot;%r&quot; %s %b" />
</Host>

• appBase: Specifies the deployment directory.
• unpackWARs: If true, WAR files are automatically extracted.
• autoDeploy: Enables hot deployment.
• Valve: Configures access logging for the virtual host.

3. XML Configurasion Deployment: Applications can be deployed via XML context descriptors, as shown:

<Context path="/MyApp" reloadable="false" docBase="C:\Projects\App\target\classes" />

• path: Defines the URL path for accessing the application.
• reloadable: If true, Tomcat monitors for changes in Java classes and reloads the context.
• docBase: Points to the application directory or WAR file location.

Tomcat does not support direct JAR file deployment in webapps. Each subdirectory in webapps represents an application; JAR files placed there are treated as dependencies, not standalone apps.

Request Processing Mechanism

When a request is initiated, the following steps occur:

1. Data Assembly: The application assembles business data based on the request.

2. Connection Establishment: Data is formated according to HTTP protocol, which includes request line, headers, and body. HTTP operates at the application layer and relies on TCP/UDP for transport.

   Applications use operating system socket APIs, such as tcp_connect(), to establish TCP connections.

3. Data Transmission: Tomcat uses Connectors to handle incoming requests. A Connector is configured in server.xml:

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

Tomcat receives socket connections via Endpoint components. The Connector employs a ProtocolHandler to process requests, with different handlers for various connection types:

• AprEndpoint: Uses Apache Portable Runtime.
• JIoEndpoint: Implements blocking I/O (BIO).
• NioEndpoint: Implements non-blocking I/O (NIO).

In Tomcat 7, both NIO and BIO were available, with BIO as the default. From Tomcat 8 onward, NIO became the default, and BIO was deprecated.

Tomcat Container Hierarchy

Tomcat functions as a Servlet container, with a hierarchical structure:

• Container Interface: Inherits from Lifecycle and includes implementations: Engine, Host, Context, and Wrapper.
• Context Example: As defined in XML, Context is a child of Host, representing a web application context.

<Context path="/HelloWorld" reloadable="false" docBase="D:\Projects\Demo\target\classes" />

• Hierarchy: Engine manages multiple Hosts, each Host contains Contexts, and each Context manages multiple Wrappers. Wrappers are responsible for individual Servlets.

  In server.xml, Host nodes define virtual hosts. If no specific host matches, Tomcat defaults to localhost. This structure enables efficient request routing and management within the container.