In a Tomcat server.xml <Connector>, what does the connectionTimeout attribute actually time out, and how does keepAliveTimeout differ from it?

## Two different silences Both attributes answer the same shape of question — *how long will Tomcat tolerate a connection on which nothing is happening?* — but they cover different moments in the connection's life, and confusing them is the reason people are surprised that a "20 second timeout" did not stop a 90-second request. **connectionTimeout** applies immediately after the socket is accepted. Tomcat is waiting for the client to say what it wants — the request line, for example `GET /orders HTTP/1.1`. If the client connects and then says nothing, this timer closes the connection. The documented default is 60000 milliseconds; the `server.xml` that ships with Tomcat overrides it to `20000`. **keepAliveTimeout** applies after a response has been written on a persistent connection. The exchange is over, the socket stays open, and Tomcat waits for the client to send another request on it. If nothing arrives within this window, Tomcat closes the connection to reclaim the resource. When the attribute is absent, its value is the connector's `connectionTimeout`. ```xml <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" keepAliveTimeout="20000" maxKeepAliveRequests="100" redirectPort="8443"/> ``` ## What neither of them does Neither attribute limits **request processing time**. Once the request has been read and handed to a servlet, no connector timer is counting: a servlet blocked for two minutes on a database call keeps its request thread for two minutes. That is exactly the gap that lets a slow dependency exhaust the thread pool while every connector timeout looks correctly configured. Bounding that work is the application's job — connect and read timeouts on the HTTP or JDBC clients your code calls — not the connector's. The one connector-level exception is `asyncTimeout` (default 30000 ms), which applies to requests that have entered asynchronous mode via `AsyncContext`; there is no container thread parked on those, so the container itself has to decide when to give up. ## Why the keep-alive window is a capacity decision A long `keepAliveTimeout` means idle connections linger. On the NIO connector that is comparatively cheap — an idle connection is polled, not owned by a thread — but it still consumes a socket and counts against `maxConnections`. A short one closes connections that a client was about to reuse, forcing a new TCP (and for HTTPS, a new TLS) setup on the next request. The answer depends heavily on **who the client is**. Behind a reverse proxy, the connections are a small, fixed set from a pool that will reuse them constantly, so a generous keep-alive window is nearly free and avoids repeated handshakes. Facing the public internet directly, the connection population is huge and mostly abandoned, and a short window protects `maxConnections`. `maxKeepAliveRequests` (default 100) is the companion knob: it caps how many requests one connection may serve before Tomcat closes it, which is how a server periodically forces clients to rebalance across instances. ## The classic mismatch with the proxy in front There is a well-known race whenever a pooled client sits in front of a keep-alive server. If Tomcat's `keepAliveTimeout` is *shorter* than the idle timeout of the proxy's upstream connection pool, the proxy will occasionally pick a connection that Tomcat has already decided to close, write a request onto it, and get a reset. The symptom is a small, maddening rate of failed requests concentrated just after quiet periods. The rule of thumb on the Tomcat side is that the server's idle window should be at least as long as the client pool's, so the *client* is the party that retires idle connections rather than discovering closed ones. If you cannot control both ends, the alternative is a client that retries an idempotent request when the failure occurs before any response byte was read. ## Reading a stalled connection When you are told "requests hang", the timeout attributes tell you which stage to look at. A connection that is accepted and then closed after exactly `connectionTimeout` milliseconds with no access-log entry means the client never sent a complete request line — a health checker that opens a socket and closes it, a TLS client talking to a plaintext connector, or a port scanner. A connection that dies after `keepAliveTimeout` with the log showing a successful response earlier is normal housekeeping, not an error, and should not be alerted on.