What is an Application Server?

What is an Application Server — and Why Does it Exist?

A Java method — public Product getProduct(Long id) — knows nothing about TCP sockets, HTTP framing, or concurrent connections. Every one of those concerns has to be handled by something before your code ever gets called, and handled correctly for thousands of simultaneous requests without your business logic knowing any of it happened. An application server (or the lighter-weight servlet container that most modern Java systems actually run) is that something: it owns the network listener, the HTTP protocol parsing, the thread that runs your code, and the lifecycle of your application as a whole, so your controller can be exactly one line of business logic and nothing else.

// BEFORE — handling HTTP without any container at all
try (ServerSocket serverSocket = new ServerSocket(8080)) {
    while (true) {
        Socket client = serverSocket.accept();   // blocks until a connection arrives
        new Thread(() -> {
            try (BufferedReader in = new BufferedReader(new InputStreamReader(client.getInputStream()))) {
                String requestLine = in.readLine();          // "GET /products/123 HTTP/1.1" — parse this yourself
                // ... parse headers, parse the path, extract "123", find the right handler,
                // build a raw HTTP response by hand, manage this thread's lifetime,
                // decide what happens past your configured thread limit, handle
                // malformed requests, handle slow clients holding the socket open ...
            } catch (IOException e) { /* now you're also writing your own error handling */ }
        }).start();   // one raw OS thread per connection, no pooling, no limit
    }
}

// AFTER — the container has already done all of the above by the time this runs
@RestController
public class ProductController {

    private final ProductService productService;

    public ProductController(ProductService productService) {
        this.productService = productService;
    }

    @GetMapping("/products/{id}")
    public Product getProduct(@PathVariable Long id) {
        return productService.findById(id);
        // The container already: accepted the connection, parsed the HTTP request,
        // assigned a pooled thread, ran the filter chain, matched the route, bound
        // "123" to id — and will serialize whatever this returns back to JSON and
        // write the HTTP response. None of that is this method's problem.
    }
}

The Taxonomy — Web Server, Servlet Container, Application Server

These three terms get used loosely, but they describe genuinely different scopes of responsibility, each a superset of the previous one.

Web Server — static content only

// Reads a file from disk, sends it over HTTP. No code execution involved.
// GET /index.html  →  reads /var/www/index.html  →  sends bytes back
// Examples: Nginx, Apache HTTP Server (httpd), IIS serving static files
// Extremely fast for exactly this job — and structurally unable to run your Java code

Servlet Container — adds the ability to run Java code

// Implements the Jakarta Servlet specification: parses the request into an
// HttpServletRequest, finds the matching Servlet, calls service(), takes the
// HttpServletResponse and writes it back.
// Examples: Apache Tomcat, Eclipse Jetty, Undertow

Full Application Server — adds the rest of Jakarta EE

// Everything a servlet container has, plus: EJB, JPA, JTA, JMS, CDI, JAX-RS,
// Jakarta Security — the full enterprise specification stack.
// Examples: WildFly, Payara, IBM WebSphere Liberty, Oracle WebLogic, Apache TomEE

The Life of a Request Inside the Container

Tracing what actually happens between "browser sends bytes" and "your controller method runs" makes the earlier before/after concrete:

Embedded vs External — Where Does the Server Actually Live?

If you've only ever used Spring Boot, the mental model above can feel backwards — you never install a server or copy a file into it, you just run a JAR. That's because Spring Boot packages the servlet container inside your application artifact rather than deploying your artifact into a separately-installed server. Both models run the exact same request lifecycle described above; they differ in where the container process lives and how it's provisioned.

Services the Container Provides Beyond Routing

Connection pooling

// Modern Spring Boot: HikariCP is the default pool, configured directly —
// no JNDI lookup involved at all, because there's no external server to
// register a resource with in the first place.
# application.yml
spring:
  datasource:
    url: jdbc:postgresql://db.internal:5432/shop
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 10000

// Traditional Java EE deployment to an EXTERNAL server: the DataSource is
// configured once in the server, and application code looks it up by name —
// this is what JNDI is actually for, and it's specific to that deployment
// model, not something a Spring Boot embedded app typically does.
@Resource(name = "jdbc/productionDB")
private DataSource dataSource;
// Same WAR, deployed to a dev server or a prod server, each configured with
// its OWN jdbc/productionDB binding pointing at a different database — the
// application code never changes, only the server-side JNDI configuration.

Thread management

Every incoming request needs a thread to execute on. The traditional model — one platform (OS) thread per request, drawn from a bounded pool — is covered here at a high level; the production consequences of that model, and how Virtual Threads change them, are covered next.

Session management & security

The container tracks session state via a cookie-keyed lookup and can enforce authentication/authorization declaratively before your code runs at all. Both topics have dedicated, far deeper coverage in Session Management and Authentication vs Authorization — this page only needs you to know that the container, not your application code, is where these concerns are enforced.

Production Reality — Virtual Threads and Graceful Shutdown

Virtual Threads (Java 21+) rewrite the oldest Tomcat tuning problem

/*
 * The traditional model: Tomcat's default connector caps at maxThreads=200
 * platform threads. Each platform thread costs real OS resources (megabytes
 * of stack, kernel scheduling overhead), so 200 is a genuine ceiling — the
 * 201st concurrent request queues and waits, even if every one of those 200
 * threads is just IDLE, blocked waiting on a slow database call or a remote
 * HTTP call to another service. This is the single most common capacity
 * bottleneck in traditional blocking Java web applications: the app isn't
 * CPU-bound at all, it's thread-pool-bound while doing nothing but waiting.
 *
 * Virtual threads (Project Loom, standard since Java 21) are cheap enough —
 * kilobytes, not megabytes, and scheduled by the JVM rather than the OS —
 * that you can run hundreds of thousands of them. A blocking call on a
 * virtual thread doesn't tie up an OS thread while it waits; the JVM parks
 * the virtual thread and frees the underlying "carrier" platform thread to
 * run other work in the meantime.
 */

# application.properties — enable virtual threads for the embedded Tomcat's
# request-handling executor (Spring Boot 3.2+, requires Java 21+)
spring.threads.virtual.enabled=true

// No code changes required — @RestController methods run exactly as before.
// The capacity conversation changes from "how many platform threads can we
// afford" to "how many blocking I/O calls can our downstream dependencies
// (database, other services) actually sustain" — which was the real
// constraint all along.

Graceful shutdown — the difference that decides whether a rolling deploy drops requests

// Kubernetes sends SIGTERM to a pod before killing it during a rolling
// deployment. Without graceful shutdown, the JVM exits immediately —
// in-flight requests get connection-reset errors, right in the middle of a
// routine deploy.
# application.properties
server.shutdown=graceful
spring.lifecycle.timeout-per-shutdown-phase=20s
// On SIGTERM: the connector stops accepting NEW requests immediately, but
// requests already in flight are allowed to finish (up to the configured
// timeout) before the process actually exits. Combined with a Kubernetes
// readiness probe that flips to "not ready" during this window, the load
// balancer stops routing new traffic to this pod while it finishes existing
// work — the standard shape of a zero-downtime rolling deploy.

Choosing the Right Server

Best Practices and Common Pitfalls

Interview Questions