我是消息队列的新手。我倾向于使用以下代码从 MQ 队列获取消息。
我正在创建一个连接并使用该连接从队列中获取每条消息。这样做是否正确，以及我是否需要提交连接。
无限 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
}
是正确的吗
定义"正确"。根据业务需求，这可能是正确的，也可能是可怕的。 例如，如果等待时间为 100 毫秒，消息深度为零，则代码将超时，引发 2033 错误 (MQRC_NO_MSG_AVAILABLE)，关闭会话并退出。 这就是你想要的吗？
通常有一个try/catch块包围GET，如果目的是即使队列为空，程序仍保持运行，则处理暂时性错误，例如RC=2033。 但在这种情况下，通常将超时设置为 10 秒左右。 在 100 毫秒超时的情况下，如果将编写的应用程序修改为保持运行，它绝对会打击侦听器。
此外，异常处理不显示用于打印链接异常的任何代码。 JMS 异常是多级数据构造，其中传输提供程序的本机错误代码位于异常的链接部分中。 如果错误处理不查看链接的异常，它甚至无法区分MQRC=2033(无消息)与MQRC=2035(授权错误)。 其中一个是短暂的，应该由程序幸存下来，另一个总是致命的。 至少，代码应该打印链接的异常，或者打印一条消息，指出未找到链接的异常。
因此，关于循环和处理设计，如果不了解需求，就不可能回答"正确"的值。 关于异常处理，绝对不对，因为不存在链接的异常处理。
。以及我是否需要提交连接。
取决于。 可以丢失或复制消息吗？ 如果是这样，则不需要事务。 使用事务处理会话可以防止消息丢失，但不能防止重复。 使用 XA 两阶段提交可防止消息丢失和受骗。 这个想法是选择满足业务需求的服务类(通常称为"最多一次"、"至少一次"或"一次且仅一次")，并相应地进行编码。
无限 for 循环是始终从队列接收消息的正确方法，对吗？
这是一种方法。 为了实现高可用性和高吞吐量，通常有两个或多个应用程序实例侦听同一队列。 这样，如果一个应用服务器实例出现故障(无论是计划内还是计划外)，其他实例将继续为队列提供服务。 通常，所有这些实例都会以大约 10 秒的超时时间侦听队列。
另外，队列上的GET指定MQGMO_FAIL_IF_QUIESCING，允许 QMgr 在 MQ 管理员尝试关闭 QMgr 时中断应用程序。 如果未指定此选项，则关闭 QMgr 的唯一方法是要求它强制中断未完成的连接，这只能作为最后的手段进行。
还可以使 MQ 在消息到达队列时触发应用程序启动。 当应用程序在JEE服务器上运行时，通常不会这样做，但对于独立=独立应用程序非常有用。
我会选择多线程应用程序，其中每个线程执行以下操作：
1) 连接到队列管理器。
2) 为队列创建使用者。
3) 设置消息侦听器以异步接收消息。如果这不适合，那么使用 receive() 方法进行同步消息接收。
4) 消息消费完成后进行清理。
这样做的优点：线程从各自的队列接收消息，并且不会因任何原因而被阻止。