【问题标题】:MQQueueManager constructor hangs if Queue Manager is unavailable and transaction is used如果队列管理器不可用并且使用了事务,则 MQQueueManager 构造函数挂起
【发布时间】:2010-08-23 21:07:27
【问题描述】:

如果队列管理器关闭,我有一个问题,即 MQQueueManager 构造函数的调用挂起。

当我调用 MQQueueManager 的构造函数时,我使用 EnterpriseOptions.Full 打开了一个 TransactionScope。如果 MQ 已关闭(或可能在 QM 关闭时尝试连接),则此调用将挂起。即使事务过期也不会在事务中引发超时异常。

如果我在进行连接时没有打开事务范围,那么在那之后我将永远无法让 MQQueueManager 参与事务。

所以,如果 MQ 可以关闭(确实如此......),当我建立连接时,如何阻止队列挂起。我正在使用 MQ 6.0.2.5 中的托管客户端。

我添加了一些代码以使问题更清楚:

TransactionOptions opt = new TransactionOptions();
opt.IsolationLevel = IsolationLevel.Serializable;
opt.Timeout = new TimeSpan(0, 0, 20);
TransactionScopeOption ScopeOption = TransactionScopeOption.Required;

using (TransactionScope tran = 
    new TransactionScope
        (ScopeOption, 
        opt, 
        EnterpriseServicesInteropOption.Full))
{
    //This line hangs if MQ is down, doesn't backout or throw a 2059.
    var m_qMgr = new MQQueueManager(QueueManager, Channel, Hostname);
    tran.Complete();
}

【问题讨论】:

  • 你能发布一些代码吗?如果我尝试将构造函数调用到 MQQueueManager 并且 Qmgr 停止,我得到一个 2059,根本没有超时。我不确定您所说的 TransactionScope 和 EnterpriseOptions.Full 是什么意思。在 Bing 上搜索会显示此主题,仅此而已。
  • 我在 windows 中使用事务。 2059 的 MQ 写入按预期工作,除非它包含在事务中。我可能会在周一上班时删除代码。

标签: c# transactions ibm-mq


【解决方案1】:

我看到挂起的两种可能性。一是它比WMQ低级,二是WMQ代码可能有未处理的异常。让我们看看这两个。

假设 TCP 在尝试构建套接字时挂起,为什么当 WMQ 启动但不关闭时它会工作?一个答案是 WMQ 侦听器是否在 QMgr 关闭后保持运行。在这种情况下,侦听器接受套接字但没有任何东西可以交给它。如果侦听器以 runmqlsr 而不是作为 QMgr 侦听器对象启动,这很常见。如果使用 inetd 作为监听器,这实际上是不可避免的。您没有提到 QMgr 方面的版本。什么版本的 WMQ 以及监听器是如何启动的? QMgr 在什么平台上运行?

我正在考虑的第二种可能性是配置与选项不匹配。 WMQ 将执行任何客户端安装的 1 阶段提交,但您要求它做的是与作为事务控制器的 Windows 协调。在客户端模式下,这需要扩展事务客户端(又名 XTC)。 XTC 组件是 WMQ 服务器安装的一部分,实际上被授权为 WMQ 服务器。换句话说,如果您为 Windows 主机上的 WMQ 服务器付费,那么您有权在那里安装完整的 WMQ 服务器和/或 XTC 组件。 XTC 组件提供 mqic32xa.dll,它通过 WMQ 客户端连接提供 XA 事务性。

很多时候,不了解许可影响的人会抓取 XA dll 或 Java/JMS XA 类并将它们放到他们的 WMQ 客户端安装中。如果未使用 WMQ 服务器媒体安装 XA 类,这可能会导致不可预知的结果,例如您所看到的。如果 XA 支持文件和 WMQ 客户端安装处于不同的修订包级别,或者更糟糕的是,不同的版本,则尤其如此。

您的 Windows 服务器中是如何安装 XA 支持的?如果没有来自 WMQ 服务器媒体的任何内容,则您的安装可能无效。无论如何,建议使用最新的 Fix Pack,因为此时 6.0.2.5 已经相当老了。 v6.0.2.9 的修复列表包含几个与 .Net 相关的 APAR,包括 IZ54336,其中显示“在托管 .NET 应用程序尝试 mqconn 期间,服务器上观察到 AMQ9456 协议错误和客户端上的 2018 hconn 错误。”

要为您的应用程序正确安装 WMQ,禁止的方法是获取 WMQ v7.0 服务器媒体并从中安装 WMQ 客户端。选择扩展事务客户端进行安装。完成后,应用最新的 Fix Pack。 .Net 类已集成到 v7 中的 WMQ 基础产品中,并得到完全支持。使用服务器介质可以在安装客户端时提供 XA 支持。除了 v7 是一个更好的 .Net 实现之外,v6 将在 12 个月内结束生命周期,因此现在使用 v7 将使您免于以后的转换或失去支持。 v7 客户端与 v6 QMgr 兼容,但您当然不会获得新的 v7 功能。

您可以从 v6 Server 媒体中执行大致相同的操作,但请务必安装最新的 Fix Pack,以获得所有已应用的 .Net 修复程序的好处。服务流中还提供了一些新的 v7 功能,因此您也可以从中受益。

您可以在http://bit.ly/WMQTrial下载 WMQ 服务器试用版
你可以在http://bit.ly/WMQFixes下载最新的Fix Pack

【讨论】:

  • 我可以向您保证,它已获得正确许可,该软件是从完整的服务器媒体安装的,然后我们已将 6.0.2.5 修复包应用于此代码。所以我们在我们的服务器中正确安装了 IBM WMQ(IBM 为我们安装了它,所以如果他们弄错了,我有什么希望?)至于使用更好版本的服务器,不幸的是,这超出了我的控制范围。
  • 服务器端呢?什么平台、修订包以及侦听器是如何启动的?运行MQLSR?网盘?与 6.0.2.5 有什么关系?有什么理由留在那里而不去客户端的 v7?
  • 我不控制服务器,但我已经向上提出了问题。我发现 amqmdnet.dll 更改了产品版本,但没有更改程序集版本(即具有相同版本的两个不同 DLL,即 .Net no no)。我至少有领先优势...
  • 6.0.2.5 修订包未在客户端正确应用。已建议进一步升级,但过时的版本导致连接问题。
【解决方案2】:

MQQueueManager 构造函数具有接受属性哈希表的重载。根据我的经验,从 .NET 应用程序调用 MQ 时,您需要将 TRANSPORT_PROPERTY 设置为 TRANSPORT_MQSERIES_MANAGED。

例如

 // set up the connection settings for the queue manager.
 var settings = new Hashtable {{MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED}};
 var qm = new MQQueueManager("yourQueueManagerName", settings);

你可以找到更多关于这个属性here的信息。

我希望这会有所帮助。我非常了解与 MQ 战斗的痛苦。

【讨论】:

  • 托管客户端不支持 XA 事务。不过欣赏输入。我现在正在盯着哈希表看是否有一些我需要设置的魔法开关...
  • 哦,好的,如果您需要 XA 事务,那么 TRANSPORT_MQSERIES_MANAGED 不是适合您的 TRANSPORT_PROPERTY :) 您可能还需要考虑将队列管理器作为单独线程上的任务构建和打开,所以你可以设置一个超时,这样即使 MQ 客户端没有超时,任务也会。它不能治愈疾病,但可能有助于控制症状?
  • 我们正在讨论这个问题,但我担心杀死线程可能会破坏 MQ API。我正在尝试读取一些跟踪信息,我知道一旦发生这种情况,它就会在等待时被阻止,但我不知道为什么或是否是我的错。
猜你喜欢
  • 1970-01-01
  • 2018-01-08
  • 2011-10-14
  • 2018-10-10
  • 2021-03-01
  • 1970-01-01
  • 1970-01-01
  • 2018-01-11
  • 1970-01-01
相关资源
最近更新 更多