WebSphere MQ：消息在输入队列和退出队列之间不断切换

这听起来像是同步点问题。如果QMgr在工作单元内重新排队消息时发出COMMIT，则将影响该线程内部同步点下的所有消息。如果应用程序在收到有害消息之前执行了几次PUT或GET调用，则将导致严重的问题。 QMgr不会在程序的控制范围之外发出“ 0”，而只是将消息留在工作单元内的回退队列中，并等待程序发出“ 0”。这可能会导致某些意外行为，例如您看到的消息重新回到输入队列的位置。 如果另一条消息在\“ bad \”消息后面的队列中，并且被同一线程成功处理，则一切工作正常。该应用在新消息上发出“ 0”字样，这也会影响“退出队列”上的有害消息。但是，如果线程不干净地退出（没有显式的断开连接或“ 0”），则事务将回滚，并且有毒消息返回到输入队列。 解决此问题的通常方法是，输入队列中的下一条好消息（如果已批处理事务，则为批消息）将强制执行COMMIT。但是，在某些情况下，拥有线程没有做任何新工作（也许它正在通过Correlation ID执行“ 4”），因此没有任何东西可以推送错误消息。在这些情况下，确保应用程序在结束前发出“ 0”很重要。一种方法是编写代码，以等待间隔执行ѭ4interval到

GET

。如果等待时间间隔到期，则应用程序将获得返回码2033，然后在关闭线程之前发出“ 0”。如果由于任何原因该回复消息确实延迟，则ѭ0将无效。但是，如果消息到达并已被撤消并重新排队，则“ 0”将使其留在“撤消队列”中。 确切了解正在发生什么的一种方法是对有问题的队列进行跟踪。您可以使用内置的跟踪功能-strmqtrc-在V7中，该功能比V6版本多一些。但是，如果要非常精细的控制，则可以使用SupportPac MA0W中的跟踪出口。使用MA0W，您可以确切地看到该程序进行的API调用以及代表该程序进行的API调用。 [EDIT]使用PMR中的一些信息更新响应： 以下是来自WMQ V7信息中心的信息：   MessageConsumers是会话级别以下的单线程，并且   任何重排毒消息   发生在   工作。这不会影响   应用程序的操作，但是   重新排毒消息时   根据交易或   Client_acknowledge会话，   重新排队动作本身不会   承诺直到当前单位   工作由应用程序提交   代码或（如果适用）   应用程序容器代码。\“      因此，对于客户来说，获取有毒信息很重要   在他们犯下后立即犯下   退缩，建议他们   要么利用该应用程序   服务器设施   （ConnectionConsumer）可以提交   立即发送消息，或   转移毒药的另一种机制   队列中的消息。 这是V6和V7信息中心中此信息的链接。由于您正在使用V6客户端，因此您需要参考V6信息中心。请注意，对于V6客户端，即使在使用ConnectionConsumer时，ASF的信息中心也没有提到能够立即提交有害消息。按照我的阅读方式，这意味着您可能需要升级到V7客户端才能获得所需的行为。有兴趣查看PMR是否得出类似建议。