Backend Development 4 min read

Does Spring Boot’s connectionTimeout Affect Request Time? The Surprising Truth

This article demonstrates how Spring Boot’s connectionTimeout setting influences server‑client connections, using three experiments—controller sleep, HttpURLConnection requests, and raw socket communication—to reveal that the timeout only terminates idle client connections, not the duration of request processing.

Spring Full-Stack Practical Cases
Spring Full-Stack Practical Cases
Spring Full-Stack Practical Cases
Does Spring Boot’s connectionTimeout Affect Request Time? The Surprising Truth

Environment: Spring Boot 2.6.12

application.yml configuration

<code>server:
  port: 8081
  tomcat:
    maxThreads: 10
    maxConnections: 10
    acceptCount: 1
    connectionTimeout: 3000
</code>

Test 1: Controller sleeps longer than connectionTimeout

<code>@RestController
@RequestMapping("/test")
public class TestController {

  @GetMapping("/index")
  public Object index() {
    try {
      System.out.println(Thread.currentThread().getName());
      TimeUnit.SECONDS.sleep(10);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
    return "success";
  }
}
</code>

The program responds normally, showing that the connectionTimeout parameter is unrelated to the actual request processing time.

Test 2: HttpURLConnection request

<code>public class HttpURLConnectionDemo {
  public static void main(String[] args) throws Exception {
    HttpURLConnection con = (HttpURLConnection) new URL("http://localhost:8081/test/index").openConnection();
    con.setDoInput(true);
    con.setDoOutput(true);
    long start = System.currentTimeMillis();
    InputStream is = con.getInputStream();
    Scanner scan = new Scanner(is);
    while (scan.hasNext()) {
      System.out.println("Received: " + scan.next() + "\nTime: " + (System.currentTimeMillis() - start));
    }
    scan.close();
    con.disconnect();
    con = null;
  }
}
</code>

Result:

The conclusion is that connectionTimeout does not depend on the type of client making the request.

Test 3: Socket connection

<code>public class TomcatConnectionTimeoutDemo {
  public static void main(String[] args) throws Exception {
    Socket socket = new Socket("127.0.0.1", 8081);
    long start = System.currentTimeMillis();
    InputStream is = socket.getInputStream();
    is.read();
    System.out.println(System.currentTimeMillis() - start);
  }
}
</code>

Result:

After about 3 seconds the program ends, indicating the connection was closed. The next test adds continuous console input:

<code>public class TomcatConnectionTimeoutDemo {
  public static void main(String[] args) throws Exception {
    Socket socket = new Socket("127.0.0.1", 8081);
    long start = System.currentTimeMillis();
    final OutputStream os = socket.getOutputStream();
    new Thread(() -> {
      Scanner scan = new Scanner(System.in);
      while (scan.hasNext()) {
        String content = scan.next();
        System.out.println("Preparing to send: " + content);
        try {
          os.write(content.getBytes());
          os.flush();
        } catch (IOException e) {
          e.printStackTrace();
        }
      }
    }).start();
    InputStream is = socket.getInputStream();
    is.read();
    System.out.println(System.currentTimeMillis() - start);
  }
}
</code>

Result without any input:

Result with continuous console input:

Conclusion: the connectionTimeout parameter defines the maximum idle time after a client has established a connection; if the client sends no data for longer than the configured timeout, the server closes the connection.

JavaSpring BootHTTPTomcatSocketconnectionTimeout
Spring Full-Stack Practical Cases
Written by

Spring Full-Stack Practical Cases

Full-stack Java development with Vue 2/3 front-end suite; hands-on examples and source code analysis for Spring, Spring Boot 2/3, and Spring Cloud.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.