Question

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

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

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

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

这样做的正确方法

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

通常情况下，try / catch块会封闭GET并处理像RC=2033这样的暂时性错误，如果意图是程序即使在队列中仍然在运行是空的。但在这种情况下，通常将超时设置为10秒左右。在100ms超时的情况下，如果被修改为继续运行，那么写入的应用程序绝对会使听众感到震惊。

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

因此，关于循环和处理设计，在不知道要求的情况下，不可能回答“正确”的值。关于异常处理，肯定不，因为没有链接的异常处理。

...以及我是否需要提交连接。

取决于。丢失或复制邮件是否可以？如果是，则不需要交易。使用事务处理会话可以防止丢失消息，但不会丢失欺骗。使用XA 2阶段提交可以防止丢失消息和防止丢失。我们的想法是选择满足业务需求和代码的服务类别（通常称为“最多一次”，“至少一次”或“一次且仅一次”）。

无限for循环是从队列中一直接收消息的正确方法，是不是？

这是一种方法。对于高可用性和高吞吐量，通常有两个或更多应用程序实例侦听同一队列。这样，如果一个应用服务器实例发生故障（无论是计划的还是未计划的），其他实例将继续为队列服务。通常，所有这些实例都会在队列上侦听大约10秒的超时时间。

通常情况下，队列上的GET指定MQGMO_FAIL_IF_QUIESCING，当MQ管理员尝试关闭QMgr时，它允许QMgr中断应用程序。如果未指定此选项，则仅关闭QMgr是要求它强制中断未完成的连接，这应该只作为最后的手段来完成。

当消息到达队列时，也可以使MQ触发应用程序启动。当应用程序在JEE服务器上运行时，通常不会这样做，但对于stand = -alone应用程序非常有用。

Answer 2

我会选择多线程应用程序，其中每个线程执行以下操作：

1）连接到队列管理器。

2）为队列创建使用者。

3）设置消息监听器以异步方式接收消息。如果这不适合，则使用receive（）方法进行同步消息接收。

4）完成消息消费后进行清理。

优点：线程从各自的队列接收消息，并且不会因任何原因而被阻止。

Websphere MQ消息无限过程

2 个答案: