使用C#.Net WCF Rest服务访问IBM MQ时首次请求报错问题

我之前在做WCF REST集成IBM MQ的时候也碰到过类似的时序问题，结合你的描述来看，核心问题应该是WCF的无状态特性、MQ连接/会话的生命周期管理，或者消息请求-响应的同步逻辑不匹配导致的。给你几个具体的排查和修复方向：

1. 确保MQ连接的复用性，避免每次请求新建连接 #

WCF REST默认是InstanceContextMode.PerCall模式——每次请求都会创建一个新的服务实例。如果你的MQ连接（比如MQQueueManager、MQQueue）是在服务实例的构造函数里初始化的，那首次请求时连接刚建立，可能还没完成握手或者队列绑定，导致第一次拉取消息时无响应；而第二次请求时，之前的连接可能还没被GC回收，反而能正常工作。

解决办法：
把MQ连接封装成静态单例或者用依赖注入创建单例实例，确保整个服务生命周期内复用同一个连接：

public static class MQConnectionManager
{
    private static MQQueueManager _queueManager;
    private static readonly object _lockObj = new object();

    public static MQQueueManager GetQueueManager(string queueManagerName, string channelName, string hostName, int port)
    {
        if (_queueManager == null || !_queueManager.IsConnected)
        {
            lock (_lockObj)
            {
                if (_queueManager == null || !_queueManager.IsConnected)
                {
                    var properties = new Hashtable();
                    properties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
                    properties.Add(MQC.HOST_NAME_PROPERTY, hostName);
                    properties.Add(MQC.CHANNEL_PROPERTY, channelName);
                    properties.Add(MQC.PORT_PROPERTY, port);
                    _queueManager = new MQQueueManager(queueManagerName, properties);
                }
            }
        }
        return _queueManager;
    }
}

2. 给MQ消息拉取增加等待与重试逻辑 #

首次请求时，可能你发送请求消息到队列后，立即去响应队列拉取，但此时业务端还没返回响应，或者MQ还没完成消息路由，直接触发MQRC_NO_MSG_AVAIL。而第二次请求时，第一次的响应已经到达队列，所以能拿到结果。

解决办法：
使用MQGMO_WAIT选项让MQGET等待一段时间，而不是立即返回错误，同时增加重试机制：

public MQMessage GetResponseMessage(MQQueue responseQueue, string correlationId)
{
    var gmo = new MQGetMessageOptions();
    gmo.Options |= MQC.MQGMO_WAIT | MQC.MQGMO_MATCH_CORREL_ID;
    gmo.WaitInterval = 5000; // 等待5秒，可根据业务调整
    gmo.MatchOptions = MQC.MQMO_MATCH_CORREL_ID;

    var responseMsg = new MQMessage();
    responseMsg.CorrelationId = Encoding.UTF8.GetBytes(correlationId);

    try
    {
        responseQueue.Get(responseMsg, gmo);
        return responseMsg;
    }
    catch (MQException ex)
    {
        if (ex.ReasonCode == MQC.MQRC_NO_MSG_AVAIL)
        {
            // 这里可以加重试逻辑，比如重试2次
            for (int i = 0; i < 2; i++)
            {
                Thread.Sleep(1000);
                try
                {
                    responseQueue.Get(responseMsg, gmo);
                    return responseMsg;
                }
                catch (MQException retryEx)
                {
                    if (retryEx.ReasonCode != MQC.MQRC_NO_MSG_AVAIL) throw;
                }
            }
            throw new InvalidOperationException("未获取到响应消息");
        }
        throw;
    }
}

3. 检查WCF的并发与实例模式设置 #

WCF的ConcurrencyMode和InstanceContextMode组合可能导致MQ操作的线程安全问题。比如如果设置了ConcurrencyMode.Multiple，多个线程同时操作MQ连接，可能导致消息的CorrelationId匹配错误，或者会话状态混乱。

解决办法：
在服务的ServiceBehavior里明确设置实例和并发模式，确保MQ操作的线程安全：

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]
public class YourRestService : IYourRestService
{
    // 服务实现代码
}

如果需要更高并发，可以用锁保护MQ的Send/Get操作，避免多线程冲突。

4. 查看完整的MQ错误日志 #

你提到MQ里的错误是“Message . . . . : Error on re...”，这是截断的日志，一定要去MQ服务器上查看完整的错误日志（默认是AMQERR01.LOG），里面会有完整的错误代码和描述——比如是否是连接重置、会话异常、权限问题等，这能直接定位根本原因。比如“Error on receive”通常和网络连接或者会话中断有关。

5. 开启WCF服务的预热机制 #

WCF REST服务在IIS托管时，默认是首次请求才启动服务实例和初始化资源，这会导致首次请求时MQ连接的初始化耗时较长，错过消息响应。而ASP.NET Web应用的应用池是持续运行的，不会有这个问题。

解决办法：
在IIS里设置应用池的“启动模式”为AlwaysRunning，同时在服务的Application_Start事件里提前初始化MQ连接，避免首次请求时的冷启动开销。

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