Websphere MQ 使用 JMS，关闭的连接卡在 MQ

Posted 2023-03-10

【中文标题】Websphere MQ 使用 JMS，关闭的连接卡在 MQ

【英文标题】：Websphere MQ using JMS, closed connections stuck on the MQ

【发布时间】：2010-11-24 18:10:41

【问题描述】：

我在 AIX 服务器下的 OC4J 上部署了一个简单的 JMS 应用程序，在我的应用程序中，我正在监听一些队列并发送到部署在 AS400 服务器下的 Websphere MQ 上的其他队列。

问题是我与这些队列的连接在空闲一段时间并出现错误MQJMS1016 （这不是问题）时被终止/关闭，当这种情况发生时我尝试恢复连接并且它可以工作，但是，旧连接卡在 MQ 上并且在手动终止之前不会终止。

恢复代码如下：

public void recover() 
    cleanup();
    init();


public void cleanup()
    if (session != null) 
        try 
            session .close();
         catch (JMSException e) 
        
    
    if (connection != null) 
        try 
            connection.close();
         catch (JMSException e) 
        
    


public void init()
    // typical initialization of the connection, session and queue...

【问题讨论】：

但是问题是什么，它在哪里“卡住” - 在 session.close() 中？

问题是在 Websphere MQ 端，旧的侦听器/生产者被卡住了，所以我将有额外的工作似乎连接到 MQ。恢复代码运行没有问题

【参考方案1】：

由于孤立的连接（MQ 端的卡住连接）不会影响消息处理（即它们不消耗消息），因此我们保持原样，直到达到 MQ 上允许的最大连接数。

恢复不再起作用，一旦我们到达那个点，MQ 管理员必须手动清理孤立的连接，但是，好消息是搜索这个特定问题导致 IBM 支持站点上报告了一个问题：

check here

【讨论】：

引用的 APAR 只是告诉您如何调整通道以便 WMQ 更快地收割孤儿。虽然这很有帮助，但它仍然只是一种解决方法，不能替代修复根本原因和打印链接异常。

【参考方案2】：

MQJMS1016 是内部错误，表示连接丢失是由于代码或 WMQ 本身的问题。调整频道会有所帮助，但您确实需要解决为什么应用会以足够快的速度喷出孤立连接以耗尽所有可用频道的问题。

我想做的第一件事是检查 WMQ 的版本和正在运行的 WMQ 客户端的版本。如果这是新开发，请确保您使用的是 WMQ v7 客户端，因为 v6 已于 2011 年 9 月结束。v7 客户端与 v6 QMgrs 一起使用，直到您也能够升级它。在您使用 v7 客户端和 QMgr 后，您可以使用相当多的频道调整和重新连接选项。

WMQ v7 客户端下载地址：http://bit.ly/bXM0q3

另外，请注意，上面代码中的重新连接逻辑在尝试之间不会休眠。如果客户端以高速抛出连接请求，它可以使 WMQ 侦听器过载并执行非常有效的 DOS 攻击。建议在两次尝试之间休眠几秒钟。

最后，请在您的 JMSException 捕获块中打印链接的异常。如果您对 JMS 传输提供程序有疑问，JMS 链接异常将包含任何低级错误信息。对于 WMQ，它包含原因代码，例如 2035 MQRC_AUTHORIZATION_ERROR 或 2033 MQRC_NO_MSG_AVAILABLE。这是一个例子：

try 
  .
  . code that might throw a JMSException
  .
 catch (JMSException je) 
  System.err.println("caught "+je);
  Exception e = je.getLinkedException();
  if (e != null) 
    System.err.println("linked exception: "+e);
   else 
    System.err.println("No linked exception found.");
  

如果您在某晚凌晨 2 点收到错误，您的 WMQ 管理员将感谢您提供链接的异常。

【讨论】：

网络被配置为终止任何空闲连接，所以问题对我们来说很清楚，并且链接的异常有点无关紧要（但是，我会检查问题的历史并在我时提供链接的异常有更多的时间）。连接恢复实际上是在 30 秒超时，并且最大连接数达到问题需要几天才能发生（不像我原来的帖子可能建议的那样频繁）最终，我们不得不通过每个发送保持活动消息我们发起的连接。

这是个好消息！值得一提的是，链接异常并不是 WMQ 特有的。任何运输提供商都可以选择将相关信息放在那里。因此，如果它成为一种编码标准，它将有助于任何 JMS 代码。我有很多客户不接受没有它的生产代码。无论哪种方式，很高兴听到 keepalives 现在正在维持连接。