Glassfish 4.1处理大参数POST请求时触发Timeout Exception的解决方案咨询

我之前帮团队排查过类似的Glassfish大请求超时问题，结合你的日志和测试情况，给你几个具体的排查和调整方向，应该能解决问题：

1. 调整HTTP连接器的POST限制与缓冲区配置 #

Glassfish的默认HTTP配置可能无法处理较大的POST请求，需要修改domain.xml中的相关参数：

• 找到对应网络监听器（比如http-listener-1）所属的<http-service>节点，添加/修改以下配置：

  <http-service>
    <!-- 设置最大POST请求大小为2MB，可根据需求调整 -->
    <property name="post-request-size-limit" value="2097152"/>
    <!-- 延长请求超时时间到120秒 -->
    <property name="request-timeout-in-seconds" value="120"/>
    <!-- 增大缓冲区到32KB，默认可能为8KB -->
    <property name="buffer-size" value="32768"/>
  </http-service>
  

• 同时在对应的<network-listener>节点中确保读取超时足够长：

  <network-listener name="http-listener-1" ...>
    <!-- 120秒超时，单位为毫秒 -->
    <property name="read-timeout" value="120000"/>
  </network-listener>
  

2. 优化Grizzly NIO传输层参数 #

日志中的TemporarySelectorReader超时和Grizzly的NIO临时选择器机制直接相关，除了你已经调整的参数，还可以尝试：

• 在server-config -> Network Config -> Transports -> tcp中，增大max-tmp-selector-threads（默认10，可改为20），避免临时选择器线程不足
• 临时测试禁用临时选择器（不推荐长期使用，但可验证问题）：添加属性use-tmp-selector并设为false
• 进一步增大selector-timeout到30秒，给大请求足够的读取时间

3. 配置Jersey的实体读取超时 #

你的请求还未进入业务代码就超时，可能是Jersey在读取请求实体时触发了超时。可以通过两种方式配置：

• 在web.xml中添加初始化参数：

  <servlet>
    <servlet-name>Jersey Web Application</servlet-name>
    <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
    <!-- 设置Jersey读取超时为120秒 -->
    <init-param>
      <param-name>jersey.config.server.readTimeout</param-name>
      <param-value>120000</param-value>
    </init-param>
  </servlet>
  

• 或者在ApplicationConfig类中通过代码配置：

  @ApplicationPath("/")
  public class ApplicationConfig extends ResourceConfig {
      public ApplicationConfig() {
          register(PropertiesFeature.class);
          // 设置读取超时为120秒
          property(ServerProperties.READ_TIMEOUT, 120000);
      }
  }
  

4. 排查操作系统与网络层面限制 #

大请求超时也可能是底层网络或系统限制导致的：

• Linux系统：检查TCP接收缓冲区大小，执行sysctl net.ipv4.tcp_rmem，如果默认值太小，调整为：

  sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
  

  并写入/etc/sysctl.conf永久生效。
• 防火墙/代理：检查iptables、UFW等防火墙是否有针对大请求的超时规则，若使用反向代理（如Nginx），需确保client_max_body_size和proxy_read_timeout设置足够大。

5. 优化请求传输方式 #

• 确保请求头使用Content-Type: application/json而非application/x-www-form-urlencoded，后者对大参数传输效率更低，更容易触发超时。
• 启用分块传输（Transfer-Encoding: chunked），让请求分块发送，避免一次性发送大数据包导致的超时。

6. 考虑Glassfish版本升级或补丁 #

Glassfish 4.1是2015年发布的旧版本，Grizzly组件存在已知的大请求处理bug。可以尝试：

• 升级到Glassfish 4.1.1（修复了部分Grizzly相关问题）
• 单独升级Glassfish内置的Grizzly版本到兼容的稳定版（如2.3.35）
• 若业务允许，直接升级到Glassfish 5.x或更高版本，获得更稳定的大请求处理能力

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