Configuring Maximum Server Connections in Spring Boot
Fast recall
Quick revision
Core answer
ulimit -n) — each TCP connection consumes one file descriptor, plus descriptors for logs, JAR entries, and sockets. In Docker, the default ulimit -n is 1024-65536 depending on the runtime; set it explicitly for high-connection apps.Whether you distinguish connections from threads, understand NIO lets one thread manage many connections, and know about OS limits
Confusing `max-connections` with `threads.max`; not mentioning file descriptor limits; setting `max-connections` very high without checking `ulimit -n`
Explain NIO's single-thread multiplexing, describe how `accept-count` relates to the Linux kernel's TCP backlog (`net.core.somaxconn`), and mention container-specific fd limits
Interview-ready guide
Interview answer
Two different settings, two different resources
server.tomcat.max-connections=8192— caps TCP connections accepted at the NIO connectorserver.tomcat.threads.max=200— caps worker threads actively processing HTTP requests- They differ because non-blocking I/O makes idle connections nearly free
How Tomcat handles thousands of connections with few threads
- A small number of poller threads (typically 1–2) use
Selector.select()to monitor many open connections for data readiness - Workers only activate when a full HTTP request has arrived
- 8192 connections + 200 threads isn't a contradiction — most are idle keep-alives
The real ceiling is usually the OS, not Tomcat
ulimit -ncaps file descriptors per process; each connection uses one FD (plus logs, JARs, DB sockets)ulimit -n=1024+max-connections=8192= hard cap at ~1000, symptom isToo many open files- Kernel
net.core.somaxconncapsaccept-count— settingaccept-count=500on a box withsomaxconn=128silently caps at 128 - Always verify with
cat /proc/on a running instance/limits
When to actually tune these
- WebSocket or SSE workloads — many long-lived connections, few active
- High keep-alive APIs with many concurrent clients
- Slow-client uploads
- Otherwise leave defaults — the thread pool saturates first
Diagnosing which limit you hit
- Thread saturation:
tomcat.threads.busyat max, latency climbs before errors - Connection saturation:
Connection refusedwhile thread count is moderate
Configuring Maximum Server Connections in Spring Boot
Direct Answer
server.tomcat.max-connections=8192 (default) caps the number of TCP connections Tomcat accepts at the network level via its NIO connector. server.tomcat.accept-count=100 is the OS-level backlog queue for connections waiting to be accepted when Tomcat is busy. Neither equals the thread count — Tomcat uses non-blocking I/O, so a single thread can monitor thousands of idle keep-alive connections, while only actively processing requests occupy worker threads. The real production ceiling is often the OS file descriptor limit (ulimit -n) — each TCP connection consumes one file descriptor, plus descriptors for logs, JAR entries, and sockets. In Docker, the default ulimit -n is 1024-65536 depending on the runtime; set it explicitly for high-connection apps.
Common Mistakes & Pitfalls
Confusing max-connections with threads.max; not mentioning file descriptor limits; setting max-connections very high without checking ulimit -n
Check your understanding
Answer these without looking back at the article.
- How does Tomcat's NIO connector differ from the older BIO connector?
- What does `net.core.somaxconn` control at the Linux kernel level?
- Why does a slow-HTTP attack (Slowloris) exploit connection count rather than threads?
- How would you configure Tomcat to handle 50,000 concurrent WebSocket connections?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.