Jersey+TomEE服务端遇‘too many follow-up requests’问题求助

First, let's ground this: you're running a modular Jersey-based REST service on TomEE 7.0.3, with Android clients using Retrofit, and you're seeing occasional "too many follow-up requests" errors. You've already checked Retrofit's GitHub issues and this site, suspecting the server, and are using ngrep to trace traffic. Great start—here's how to narrow this down further:

Likely Root Causes & Actionable Debugging Steps #

• TomEE's Keep-Alive Configuration Limits
  This error almost always links to HTTP/1.1 persistent connection (keep-alive) handling. TomEE uses Apache Coyote under the hood, and misconfigured keep-alive settings are a common culprit. Pop open your server.xml and check these parameters:

  • maxKeepAliveRequests: The default value might be too low if your clients are reusing connections heavily. If a client sends more requests over a single keep-alive connection than this limit, the server will throw this error.
  • keepAliveTimeout: If this is set too short, the server might terminate a connection mid-sequence while the client is still sending follow-up requests.
    Try bumping maxKeepAliveRequests (e.g., to 1000) and extending keepAliveTimeout temporarily to see if the error frequency drops.

• Retrofit/OkHttp Connection Pool Misalignment
  Even though you suspect the server, don't rule out a client-side mismatch. Retrofit relies on OkHttp, and if your client's connection pool settings clash with TomEE's, you can hit this error. Verify your OkHttp configuration:

  • Check maxIdleConnections and keepAliveDuration in your ConnectionPool setup. If the client is holding idle connections longer than TomEE allows, or sending more concurrent requests per connection than the server permits, you'll get this error.
  • Ensure all your modular clients are using consistent connection pool settings—with 14+ modules, it's easy to have conflicting configurations across modules.

• Modular Architecture Edge Cases
  With 14+ modules, there might be hidden traffic patterns triggering this. For example:

  • Multiple modules spawning separate Retrofit instances with their own connection pools, leading to more concurrent keep-alive connections than TomEE can handle.
  • Bursty traffic from specific modules that overwhelm the server's per-connection request limit.
    Do a quick audit of all modules that make HTTP calls to ensure they're using a shared, properly configured Retrofit/OkHttp client instance.

• Leverage Your ngrep Data & Server Logs
  Since you're already running ngrep on the server, focus on capturing the full request/response flow when the error fires:

  • Look for patterns: Does the error happen during peak traffic? On specific endpoints? After a series of rapid requests from the same client?
  • Enable debug logging for Jersey (set org.glassfish.jersey to DEBUG in your logging config) and crank up TomEE's access logs to track keep-alive connection usage. This will show you how many requests are being sent over each persistent connection before the error occurs.
  • Check if the error is preceded by unexpected connection resets or partial requests—those can indicate a misbehaving client or network issue.

Quick Validation Tests #

1. Disable Keep-Alive Temporarily: Add a Connection: Close header to all Retrofit requests. If the error disappears entirely, you've confirmed the issue is tied to persistent connection handling.
2. Replicate with a Simple Client: Use curl with the -k (keep-alive) flag to send a sequence of requests to your service. If you can replicate the error this way, you know it's a server-side configuration issue.

内容的提问来源于stack exchange，提问作者Seyed Ali Roshan