逻辑流程就像这样
任何帮助都会非常感激，看起来我们的想法已经不多了。
答案 0 :(得分：0)
这听起来像是一个同步点问题。如果QMgr在消息在一个工作单元内重新排队时发出COMMIT，则会影响该线程内同步点下的所有消息。如果应用程序在点击有害消息之前执行了多次PUT或GET调用，则会导致严重问题。 QMgr不是在程序控制之外发出COMMIT，而是将消息留在工作单元内的退出队列中，并等待程序发出COMMIT。这可能会导致一些意外行为，例如您在输入队列中返回消息的位置。
如果另一条消息在“坏”后面的队列中并且由相同的线程成功处理，那么一切都很完美。该应用程序在新邮件上发出COMMIT，这也会影响退出队列上的有害消息。但是，如果线程不正确地退出（没有显式断开连接或COMMIT），则回滚事务并将有害消息返回到输入队列。
处理此问题的常用方法是在输入队列中下一个好的消息（或者批处理事务的批处理消息）将强制执行COMMIT。但是在某些情况下，拥有的线程没有新的工作（可能它是通过关联ID执行GET），没有什么可以推送坏消息。在这些情况下，确保应用程序在结束前发出COMMIT非常重要。一种方法是编写代码以GET执行CORRELID并等待一段时间。如果等待间隔到期，应用程序将获得返回代码2033，然后在关闭线程之前发出COMMIT。如果回复邮件由于某种原因合法延迟，则COMMIT将无效。但是如果消息到达并且已经退回并重新排队，则COMMIT将使其保留在退出队列中。
查看确切内容的一种方法是针对相关队列运行跟踪。您可以使用内置跟踪功能 - strmqtrc - 它比in V7有更多选项the V6 version。但是，如果您想要非常精细的控制，可以使用SupportPac MA0W中的跟踪出口。使用MA0W，您可以确切地看到程序和代表它们所做的API调用。
[编辑] 使用PMR中的某些信息更新回复：
以下内容来自WMQ V7信息中心：
MessageConsumers是Session级别下的单线程，并且 任何有毒信息的重新排列 发生在当前单位内 工作。这不会影响 但是，应用程序的操作 当毒药消息被重新排队时 交易或交易 Client_acknowledge会话， 重新排列行动本身不会 承诺直到目前的单位 工作由应用程序提交 代码，或者，如果适用， 应用程序容器代码。“
因此，如果客户有毒药信息很重要 他们之后立即承诺 退出，建议他们 要么使用应用程序 服务器设施 （ConnectionConsumer）可以提交 消息立即，或 另一种移动毒药的机制 来自队列的消息。
以下是V6和V7信息中心中此信息的链接。由于您使用的是V6客户端，因此您需要参考V6信息中心。 请注意，对于V6客户端，即使使用ConnectionConsumer ，ASF的信息中心也没有提及能够立即提交有害消息。我阅读它的方式，这意味着您可能需要升级到V7客户端以获得您正在寻找的行为。有兴趣看看PMR是否会产生类似的建议。