当JMSXDeliveryCount增加时

Aja*_*ani 5 java jms ibm-mq

在WebSphere MQ中增加JMSXDeliveryCount的条件是什么.我需要所有可能发生的场景.

Sha*_*shi 7

每次将消息重新传递给消费者时,JMSXDeliveryCount都会递增.可以重新传递消息:

1)使用客户端确认模式的消费者先前收到的消息没有在该消息上调用acknowledge().

2)消费者在事务中收到消息,没有调用提交或调用回滚.

编辑:

如果JMS客户端由于某些错误的JMS头而无法处理该消息,则此类消息(称为"有害消息")将不会传递给应用程序,而JMS客户端将在内部回滚该消息.在这种情况下,JMSXDeliveryCount也会递增.

在IBM MQ中,是否为要从中检索消息的队列设置了"回退队列"和"回退阈值"属性?一旦达到回退阈值,JMS客户端就会将这些错误消息放入回退队列.这是为了避免JMS客户端一次又一次地检索到相同的消息,从而阻止其他好消息被传递给应用程序.


Aja*_*ani 5

非常感谢其他人,我得到了网上的答案并将其粘贴在这里,以便对其他人有所帮助。

消息可以重新传递给消费者的情况取决于会话的确认模式:

  • 当应用程序的 onMessage() 方法抛出异常时,选择 AUTO_ACKNOWLEDGE 或 DUPS_OK_ACKNOWLEDGE 确认模式的非事务性会话会将消息重新传递给使用者。客户端运行时捕获异常,然后再次调用 onMessage()。异常被捕获并报告给 Connection 的 ExceptionListener。设置重新传递尝试的限制会限制重新传递计数。请参阅下面的注释。

  • 选择 SINGLE_MESSAGE_ACKNOWLEDGE 或 CLIENT_ACKNOWLEDGE 确认模式的非事务性会话,当应用程序调用 Session.recover() 时会重新传递消息。

  • 使用 TRANSACTED 确认模式,当应用程序回滚事务时会重新传递消息。

应用程序可能会陷入循环,重复接收导致应用程序失败的消息,然后一次又一次地重新传递相同的消息。无限重发循环有时被称为“毒药消息场景”。

  • 想要限制重新传递尝试的点对点(基于队列)消费者客户端可以通过在 ConnectionFactory 上指定参数来限制向消费者传递消息的次数。. 这是通过 progress.message.jclient.ConnectionFactory.setMaxDeliveryCount(java.lang.Integer value) 方法完成的。值 0(默认值)表示没有限制。

超过重新传送限制且尚未确认的消息将根据消息中指定的属性进行处理或将被丢弃。

如果消息属性 JMS_SonicMQ_preserveUndelivered 设置为 true,则消息将放置在 SonicMQ.DeadMessage 队列(或由 JMS_SonicMQ_destinationUndelivered 属性指定的备用目的地)上,并且消息属性 JMS_SonicMQ_undeliveredReasonCode 将设置为错误代码 progress.message.jclient .Constants.UNDELIVERED_DELIVERY_LIMIT_EXCEEDED。如果未设置 'preserveUndelivered' 属性,则消息将被丢弃。

  • 或者,JMS 应用程序(例如基于 Pub-Sub 主题的客户端和 Sonic ESB 服务/进程)可以通过获取和操作每条消息的 JMSXDeliveryCount 属性值来自行执行检测。JMSXDeliveryCount 属性使用 int 来指定消息的传递尝试次数。使用 javax.jms.Message.getIntProperty("JMSXDeliveryCount") 方法获取其值。每次向消费者提供消息时,此属性的值都会增加。传递计数器在客户端运行时维护,用于等待传递给消费者对象的消息。如果消费者关闭/终止并重新创建/重新启动,则发送给消费者的每条消息的计数器都会重置为 0。