WebSphere9环境JMS线程卡在proxyMQGET及队列深度过高问题咨询

你遇到的是慢SQL引发的连锁阻塞问题，两类挂起线程都和核心INSERT性能不足直接相关，没有MQCC错误属于正常现象，因为两类阻塞都属于JMS客户端、WebSphere连接池的内部等待逻辑，未触发MQ服务端错误返回，因此不会生成对应错误日志。

两类挂起线程的具体阻塞原因 #

• 卡在com.ibm.mq.jmqi.remote.impl.RemoteProxyQueue.proxyMQGET的线程：Spring DefaultMessageListenerContainer默认调用无参数receive()方法获取MQ消息，该方法没有超时机制，会无限等待服务端返回消息，因此会被WebSphere线程监控判定为疑似挂起。
• 卡在com.ibm.ejs.j2c.FreePool.queueRequest的线程：慢INSERT导致单条消息消费耗时长达1分钟，JMS连接被消费线程长时间占用无法释放，JMS连接池达到上限后新的消费线程只能进入等待队列，你观察到的15-16分钟卡住就是WebSphere J2C连接池的默认等待时长。

落地解决措施 #

• 优先优化慢INSERT：检查目标插入表的冗余索引、行锁竞争、提交批次配置，将单条INSERT耗时降到100ms以内，解决核心吞吐量瓶颈。
• 调整Spring JMS监听器配置：给DefaultMessageListenerContainer添加receiveTimeout属性，建议设置为15000（15秒），超时后线程自动中断等待、回收资源重试，避免无限阻塞。
• 调整WebSphere JMS连接池参数：
  • 将JMS连接池最大连接数调整为和JMS监听器最大并发数一致，避免并发消费时连接资源不足
  • 将连接池等待超时时间从默认的1800秒改为60秒，超时后直接抛出连接获取失败错误，避免线程长时间挂起
• 配置IBM MQ客户端心跳：给MQ JMS连接工厂添加心跳参数，设置间隔为30秒，避免网络静默断开导致的无报错阻塞。

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