Weblogic MDB 实例变为零并且队列中的消息未被拾取

发布于 2024-11-10 11:40:09 字数 105 浏览 6 评论 0原文

我有一个 MDB 通过本地绑定从 MQ 队列读取。有时我们会注意到来自 MQ 队列的消息没有被拾取队列深度增加到 50000 并且实例数量变为零。执行线程总数为25。一台物理机中有8台托管服务器。

I have a MDB reading from a MQ Queue through local binding. Sometimes we notice that the messages from the MQ Queue is not picked up Queue depth increases to 50000 and the number of instances become zero. Total number of execute threads is 25. There are 8 managed servers in a physical machine.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

时常饿 2024-11-17 11:40:09

这听起来像是有毒消息问题。如果队列中的消息无法传送(例如无效标头或未知格式),则 WMQ JMS 类将尝试将其重新排队。首先,他们将在队列的 BOQNAME 和 BOQTHRESH 属性中查找值。如果存在这些,一旦回退计数超过 BOQTHRESH,消息将被放置在 BOQNAME 中指定的队列中。如果重新排队到此队列时出现问题,则消息将被放置在死信队列中。如果无法完成此操作,MDB 将停止接收消息。

重新排队消息可能会出现几个问题:

  • BOQNAME 队列或 DLQ 不存在
  • 重新排队目标队列存在,但 ID 消费消息无权访问
  • 该队列 重新排队目标队列已满
  • BOQNAME 或 BOQTHRESH 中没有值

如果您还没有定义一个回退队列,定义一个并将其名称放入输入队列的 BOQNAME 属性中。接下来,在输入队列的 BOQTHRESH 属性中放置一个值(通常使用“10”)。确保使用消息的应用程序被授权使用新的回退队列,并在进行这些更改后重新启动应用程序。如果问题是有害消息,您现在应该会看到有害消息落在回退队列中,然后主输入队列应该正常排出。

That sounds like a poison message problem. If a message in the queue cannot be delivered (for example invalid headers or unknown format) then the WMQ JMS classes will try to requeue it. First, they will look for a value in the BOQNAME and BOQTHRESH attributes of the queue. If these are present the message will be placed on the queue named in BOQNAME once the backout count exceeds BOQTHRESH. If there are problems requeuing to this queue then the message will be placed on the Dead Letter Queue. If this cannot be completed, the MDB stops receiving messages.

There are several possible problems with requeueing messages:

  • The BOQNAME queue or DLQ does not exist
  • The requeue destination queue exists but the ID consuming messages has no authority to it
  • The requeue destination queue is full
  • No value in BOQNAME or BOQTHRESH

If you do not already have a backout queue defined, define one and place its name in the BOQNAME attribute of the input queue. Next, place a value (often "10" is used) in the BOQTHRESH attribute of the input queue. Make sure the application consuming messages is authorized to the new backout queue and restart the application after making these changes. If the issue is a poison message, you should now see the poison message landing in the backout queue and the primary input queue should then drain normally.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文