问题描述
||
逻辑流程是这样的
消息发送到输入队列
调用ProcessorMDB的onMessage()。在此方法中,完成了一些操作/验证
如果出现有害消息(应用程序代码无法处理的消息),则会引发RuntimeException。
这应该回滚事务。我们正在日志文件中看到证据。
有一个使用退出队列名称定义的退出阈值
达到阈值后,邮件将发送到退出队列
但是,它立即开始在输入队列和退出队列之间来回移动。
我们正在使用MQMON工具来观察这种奇怪的行为。即使关闭了运行MDB的应用程序服务器,它也将永远持续下去。
我们正在使用Weblogic 10.3.1和WebSphere MQ 6.02
任何帮助将不胜感激,好像我们用尽了所有想法。
解决方法
这听起来像是同步点问题。如果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是否得出类似建议。