.NET 5使用IBMMQDotnetClient消费消息报MQRC_CONNECTION_BROKEN如何解决

问题根因 #

你遇到的是9.2.3版本IBMMQDotnetClient NuGet包在.NET 5+运行时下的已知缺陷：SSL场景下使用短等待间隔消费消息时，内部接收线程的缓冲区拷贝逻辑存在数组越界问题，先抛出ArgumentException异常，随后触发CompCode: 2 Reason: 2195（未知内部错误）、CompCode: 2 Reason: 2009（连接断开）错误。旧.NET Framework客户端不存在该实现缺陷，所以可以正常消费所有消息。 #

最优解决方案 #

直接升级IBMMQDotnetClient NuGet包到9.2.4或更高版本，IBM在后续版本中已经修复了该缓冲区越界问题，同时优化了.NET 5+平台的SSL适配逻辑，升级后不需要修改业务代码即可解决问题。 #

临时规避方案（如果暂时无法升级包） #

• 提前设置MQMessage的最大消息长度，避免动态分配缓冲区时的计算错误，你的单条消息最大为150KB，可预留冗余空间：

var mqMessage = new MQMessage();
// 提前设置最大消息长度为200KB，覆盖业务最大消息大小
mqMessage.MaxMessageSize = 1024 * 200;
MqQueue.Get(mqMessage, getMessageOptions);

• 调整等待间隔配置，不要使用100ms的短等待，将WaitInterval调整为1000ms（1秒）以上，避免高频触发内部接收线程的缓冲区逻辑：

getMessageOptions.WaitInterval = 1000;

• 配置环境变量关闭IBMMQ客户端内部的独立接收线程，强制使用同步拉取模式，从根源避开触发bug的线程逻辑：
  在程序启动前添加系统环境变量：
  set MQDOTNET_DISABLE_RCVTHREAD=true
  或者在代码初始化阶段添加：

  Environment.SetEnvironmentVariable("MQDOTNET_DISABLE_RCVTHREAD", "true");
  

• 不要复用MQMessage实例，每次消费消息都新建独立的MQMessage对象，避免前一次消费的残留数据影响长度计算。

代码优化建议 #

增加异常处理逻辑，遇到连接错误时自动重建连接，避免服务卡住：

try
{
    var mqMessage = new MQMessage();
    mqMessage.MaxMessageSize = 1024 * 200;
    MqQueue.Get(mqMessage, getMessageOptions);
    // 业务消息处理逻辑
    MqQueueManager.Commit();
}
catch (MQException ex)
{
    MqQueueManager.Backout();
    // 2009错误时重建连接
    if (ex.ReasonCode == 2009)
    {
        // 关闭旧的队列、队列管理器实例，重新初始化连接
    }
}

内容的提问来源于stack exchange，提问作者Mr.X