How to Fix Java.Net.SocketTimeoutException: Read Timed Out Under Tomcat

When Java reports java.net.SocketTimeoutException: Read timed out, a socket read did not receive data before that read’s configured wait expired. The message alone does not show whether the delay came from a remote service, the network, application work, or the timeout configured by the caller. Trace the failing read first, then adjust only the timeout that governs it.

What java.net.SocketTimeoutException: Read timed out means

A read timeout limits how long a Java socket read waits for data. It is different from a connection timeout, which governs a different phase of communication. A stack trace may show whether the read belongs to an HTTP client, a database driver, or application code; use that call site and the surrounding logs to identify the operation.

The message is not proof that Tomcat failed to answer a client. The Java process that logged it may itself be reading from an upstream service, and the peer may have sent some data before the read that timed out. Correlate the stack trace with request IDs, timestamps, and logs from both sides where available.

Identify which timeout is expiring

Start at the exception’s stack trace and find the first application or library frame that initiated the read. Determine whether it is reading an HTTP response, a database result, or another socket. Then inspect that client’s settings and documentation for its read or response timeout. A browser or frontend timeout is relevant only when the timed-out read is actually controlled by that client.

If Tomcat appears in the call path, establish which process logged the error and which connection it was reading. A timeout configured on an outbound Java client is separate from a Tomcat Connector setting. Do not infer the responsible setting from the exception text alone.

Configure the relevant Tomcat timeout

connectionTimeout is a Tomcat Connector setting, but the exact behavior and defaults depend on the Tomcat version and connector in use. It is not interchangeable with a Java client’s socket read timeout. Review the Tomcat 10.1 Connector configuration documentation, then select the documentation for your deployed Tomcat version and verify that the setting covers the operation identified in the stack trace. The supplied information does not identify a Tomcat version, so no Connector XML change can be recommended safely.

For a Java client that owns a socket, Socket.setSoTimeout configures reads on that socket. This program reads back the configured value:

import java.io.IOException;
import java.net.Socket;

class ReadTimeoutSetup {
    public static void main(String[] args) throws IOException {
        try (Socket socket = new Socket()) {
            socket.setSoTimeout(5000);
            System.out.println("Read timeout: " + socket.getSoTimeout() + " ms");
        }
    }
}

Read timeout: 5000 ms

This example does not connect to a server and does not change Tomcat configuration. Apply a client-side setting only in the component that owns the timed-out read, and confirm the chosen value against that client’s API and operational requirements.

Diagnose network, server, and application delays

Check timestamps and request identifiers across the caller, Tomcat, and any upstream services. Look for a period with no response data, then compare it with network errors, server logs, and application traces. Delayed data can result from network latency, slow application work, a slow database query, resource contention, or concurrent load; these are leads to investigate, not conclusions from the exception alone.

Review CPU, memory, thread, connection-pool, and database metrics for the same interval. Check whether the relevant request reached the application and whether a downstream call or query took longer than usual. If the service is behind a proxy or load balancer, compare its timeout and logs with the client and server timelines. Change one relevant setting at a time and observe whether the specific read completes, while continuing to look for the source of the delay.

Handle long-running requests safely

If work legitimately takes longer than a synchronous request can wait, consider moving it to asynchronous processing: return an accepted response with a job identifier, perform the work separately, and let the client check for completion. This avoids holding a request open for the full duration, but requires application support and a clear way to report failures or progress.

When a longer wait is appropriate, raise only the timeout that governs the identified read and keep related client, proxy, and server limits compatible. Excessively long waits can tie up threads, sockets, or other resources and can conceal a service that is slowing down. Set values from observed request durations and capacity, then monitor both completion rates and resource use.