jms 消息未移动 websphere 中的队列
我有一个消息驱动的 bean，它在某些条件下抛出异常。当它抛出异常时，消息不会被处理并放回到队列中。根据我对 MQ 和 WAS（Websphere Application Server）的理解，消息应该在 x 次尝试后被标记为坏消息并从队列中删除。这种情况没有发生，并且该消息仍保留在标记为坏的队列中。
我错过了正确设置 MQ 和/或 WAS 中配置的哪一部分？
（MDB 抛出异常的问题不是这里的重点）
谢谢。
I have a message driven bean that throws exception under certain conditions. When it throws an exception the message is not processed and put back on the queue. From what I understand with MQ and WAS (Websphere Application Server) the message should be marked as bad after x number of tries and removed from the queue. This is not happening and the message remains on the queue marked as bad.
What part of the configuration in MQ and/or WAS have I missed to set correct?
(The issue with the MDB throwing exceptions is NOT the point here)
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
队列上有属性 BOQNAME 和 BOQTHRESH。这些必须设置为要重新排队消息的回退队列的名称以及重新排队消息之前回退次数的阈值。
此外，QMgr 必须能够将消息放入指定的队列中。问题可能包括队列名称拼写错误、撤销队列已满或运行 MDB 的帐户无权将消息放入撤销队列。
如果 MDB 检测到有害消息循环并且无处可重新排队消息，它将停止处理。您仍然会看到该线程，但队列中会缺少一个或多个打开的输入句柄。在这种情况下，必须重新启动应用程序才能恢复它。
避免使用系统的 DLQ 作为回退目标。 DLQ 是 QMgr 将放置来自另一个无法解析到目标队列的 QMgr 的消息的位置。这些消息将附加死信标头，而重新排队的 MDB 消息则不会。这可能会导致您观看 DLQ 的任何自动化操作出现问题。因此，建议每个应用程序都有一个异常队列，而不是 DLQ。
BOQTHRESH 应大于 1 或 2，因为关闭 QMgr 或通道等正常操作可能会导致回退。我通常将 BOQTHRESH 设置为 5 或 10，但也看到有人将其设置得更高。取决于您对重试的容忍度以及回退通常是否是由临时条件（例如填满日志范围）引起的。
On the queue there are attributes BOQNAME and BOQTHRESH. These must be set to the name of the backout queue where the message is to be requeued and the threshold for number of backouts before requeueing the message.
In addition, the QMgr must be able to put the message onto the designated queue. Problems may include misspelling of the queue name, the backout queue being full or the account running the MDB was not authorized to put messages on the backout queue.
If the MDB detects a poison message loop and has nowhere to requeue the message, it stops processing. You will still see the thread but you will be missing one or more open input handles on the queue. The app must be restarted to revive it in this instance.
Avoid using the system's DLQ for the backout destination. The DLQ is where the QMgr will place messages arriving from another QMgr which cannot resolve to a destination queue. These will have a Dead Letter Header attached whereas MDB messages that are requeued will not. This can cause problems with any automation you have watching the DLQ. Therefore, it is advisable to have an exception queue per application that is not the DLQ.
BOQTHRESH should be greater than 1 or 2 because normal operations such as shutdown of the QMgr or channel can result in a backout. I generally set BOQTHRESH to 5 or 10 but have seen people set this much higher. Depends on your tolerance for retries and whether the backouts are typically caused by transient conditions such as filling up log extents.
请参阅这篇 WebSphere 如何处理有害消息 的文章。
它适用于WAS 5，但原理没有改变。
Look at this How WebSphere handles poison messages article.
It applies to WAS 5, but the principles have not changed.