java - Websphere MQ 消息无限进程

Question

我是 Message Queue 的新手。我正在尝试使用以下代码从 MQ 队列获取消息。

我正在创建一个连接并使用该连接从队列中获取每条消息。这样做是否正确以及我是否需要提交连接。

无限循环是一直从队列接收消息的正确方法，对吗？请给我建议。

try {
    createMQConnection(); // getting mq connection
    createMQSession(); // getting mq session
    createMQDestination(); // getting mq destination

    for ( ; ; ) { // infinite loop to receive message from Queue
        consumer = session.createConsumer(mqQueue);
        jmsTextMessage = (JMSTextMessage) consumer.receive(100);
        // Calling application method to process the requested message from queue
    }
} catch (Exception e) {
    throw e;
} finally {
    // closing consumer
    // closing session
    // closing connection
}

Answer 1

Is it right way of doing like this

定义“正确”。根据业务需求，这可能是正确的，也可能很糟糕。例如，如果等待时间为 100 毫秒且消息深度为零，则代码将超时、抛出 2033 错误 (MQRC_NO_MSG_AVAILABLE)、关闭 session 并退出。这是你想要的吗？

通常有一个 try/catch block 包含 GET 并处理 transient 错误，如 RC=2033 如果意图是程序在队列为空时仍保持运行。但在那种情况下，通常将超时设置为 10 秒左右。在 100 毫秒超时的情况下，如果将编写的应用程序修改为保持运行状态，那么它绝对会影响监听器。

此外，异常处理不显示任何用于打印链接异常的代码。 JMS 异常是多级数据结构，其中传输提供商的 native 错误代码位于异常的链接部分。如果错误处理不查看链接的异常，它甚至无法区分 MQRC=2033(无消息)与 MQRC=2035(授权错误)之间的区别。其中一个是短暂的，应该由程序幸存下来，另一个总是致命的。至少，代码应该打印链接异常或者打印一条消息，说明没有找到链接异常。

因此关于循环和处理设计，在不知道需求的情况下不可能回答“正确”的值。关于异常处理，绝对不是正确的，因为不存在链接的异常处理。

...and whether I need to commit the connection.

视情况而定。丢失或重复消息是否可以？如果是这样，则不需要交易。使用事务处理 session 可以防止消息丢失，但不能防止重复。使用 XA 2-Phase Commit 可以防止消息丢失和欺骗。这个想法是选择满足业务需求和相应编码的服务类别(通常称为“至多一次”、“至少一次”或“一次且仅一次”)。

Infinite for-loop is right way to receive messages all the times from the queue, is it right?

这是一种方法。对于高可用性和高吞吐量，通常有两个或更多应用程序实例在同一队列上监听。这样，如果一个应用程序服务器实例出现故障(无论是计划内还是计划外)，其他实例将继续为队列提供服务。一般而言，所有这些实例都会在大约 10 秒的超时时间内监听队列。

通常，队列上的 GET 指定 MQGMO_FAIL_IF_QUIESCING，这允许 QMgr 在 MQ 管理员尝试关闭 QMgr 时中断应用程序。如果未指定此选项，则关闭 QMgr 的唯一方法是要求它强行断开未完成的连接，这只能作为最后的手段。

当消息到达队列时，也可能导致 MQ 触发应用程序启动。当应用程序在 JEE 服务器上运行时，通常不会这样做，但对于独立应用程序非常有用。