Jersey多模块项目TLS通信中Keep-Alive-Timer触发close致请求超时

从你的描述和日志来看，这个问题的核心是TLS连接被Keep-Alive定时器提前关闭，导致第二次协商请求尝试使用已失效的连接，最终触发SocketException，而且请求根本没到接收方的业务代码。结合你的场景（每个请求新建Jersey Client、无TLS时正常），我整理了几个可能的原因和对应的排查/解决思路：

1. 连接池复用与Keep-Alive的冲突 #

虽然你每个请求都新建javax.ws.rs.client.Client实例，但Jersey默认使用的HttpUrlConnector底层依赖HttpURLConnection，而HttpURLConnection默认启用了连接池——即使你新建Client，底层可能还是复用了连接池中的空闲连接。在TLS场景下，Keep-Alive定时器可能在两次请求的间隔内关闭了空闲连接，而第二次请求尝试复用这个已关闭的连接，就会触发异常。

解决思路：

• 强制每次请求后关闭连接，在请求头中添加Connection: close：

  Response response = client.target(negotiationUrl)
      .request()
      .header(HttpHeaders.CONNECTION, "close")
      .post(Entity.json(negotiationPayload));
  

• 禁用Jersey Client的连接池，自定义一个不复用连接的ConnectionManager：

  class NoOpConnectionManager implements HttpUrlConnectionManager {
      @Override
      public HttpURLConnection getConnection(HttpUrlConnectorProvider.ConnectionRequest request) throws IOException {
          return request.openConnection();
      }
  
      @Override
      public void releaseConnection(HttpURLConnection connection) {
          // 不做复用，直接关闭连接
          connection.disconnect();
      }
  }
  
  // 在ClientConfig中配置自定义连接管理器
  ClientConfig config = new ClientConfig();
  config.property(HttpUrlConnectorProvider.CONNECTION_MANAGER, new NoOpConnectionManager());
  Client client = ClientBuilder.newClient(config);
  

2. TLS会话复用导致的连接生命周期异常 #

TLS会话复用会让客户端和服务端复用之前的TLS会话以减少握手开销，但这可能和Keep-Alive的连接生命周期管理冲突——Keep-Alive定时器关闭了连接，但会话复用逻辑还尝试使用这个已失效的连接。

解决思路：

• 禁用TLS会话复用，在Client配置中添加相关属性：

  ClientConfig config = new ClientConfig();
  // 禁用TLS会话创建/复用
  config.property(ClientProperties.SSL_ENABLE_SESSION_CREATION, false);
  Client client = ClientBuilder.newBuilder()
      .sslContext(yourSslContext)
      .hostnameVerifier(yourHostnameVerifier)
      .withConfig(config)
      .build();
  

3. 服务器端/客户端的空闲超时设置过短 #

从日志里的Keep-Alive-Timer, called close()可以看出，连接的空闲时间超过了配置的超时阈值，导致定时器主动关闭连接。如果服务发现和协商阶段的间隔超过了这个阈值，连接就会被提前关闭。

解决思路：

• 客户端：调整HttpURLConnection的Keep-Alive相关系统属性（全局生效，谨慎使用）：

  // 禁用HTTPS的Keep-Alive
  System.setProperty("https.keepAlive", "false");
  // 或者设置空闲超时（单位：毫秒）
  System.setProperty("https.maxIdleTime", "30000"); // 30秒
  

• 服务器端：如果你使用Grizzly作为容器，调整其空闲超时设置：

  HttpServer server = GrizzlyHttpServerFactory.createHttpServer(baseUri, resourceConfig);
  // 设置连接空闲30秒后关闭
  server.getListener("grizzly").getTransport().setIdleTimeout(30000);
  server.getListener("grizzly").getTransport().setReadTimeout(30000);
  server.getListener("grizzly").getTransport().setWriteTimeout(30000);
  

4. 切换到Apache Connector替代默认的HttpUrlConnector #

Jersey默认的HttpUrlConnector对连接池的配置不够透明，而Apache HttpClient的连接池配置更灵活，能更精准地控制连接的生命周期，减少这类隐蔽的连接复用问题。

解决思路：
先引入Apache Connector依赖（根据你的Jersey版本调整）：

<!-- Maven依赖示例 -->
<dependency>
    <groupId>org.glassfish.jersey.connectors</groupId>
    <artifactId>jersey-apache-connector</artifactId>
    <version>${jersey.version}</version>
</dependency>

然后配置自定义的连接池：

PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
// 设置最大总连接数和每路由最大连接数
connectionManager.setMaxTotal(100);
connectionManager.setDefaultMaxPerRoute(20);
// 设置连接空闲5秒后自动验证有效性
connectionManager.setValidateAfterInactivity(5000);

HttpClient httpClient = HttpClientBuilder.create()
    .setConnectionManager(connectionManager)
    .build();

ClientConfig config = new ClientConfig();
config.connectorProvider(new ApacheConnectorProvider());
config.property(ApacheClientProperties.HTTP_CLIENT, httpClient);

// 配置SSL上下文和hostnameVerifier
Client client = ClientBuilder.newBuilder()
    .sslContext(yourSslContext)
    .hostnameVerifier(yourHostnameVerifier)
    .withConfig(config)
    .build();

额外排查点 #

• 检查两次请求的时间间隔：如果服务发现和协商之间的间隔超过了当前的Keep-Alive超时，那连接必然会被关闭，这种情况下要么延长超时，要么强制新建连接。
• 验证Client实例的独立性：确保每个请求确实新建了完全独立的Client，没有共享Client实例或其内部的SSL上下文、连接池资源。

内容的提问来源于stack exchange，提问作者logi0517