【发布时间】：2015-03-17 04:36:14
【问题描述】：
JMSXDeliveryCount 在 WebSphere MQ 中增加的条件是什么。我需要它可能发生的所有场景。
【问题讨论】：
【发布时间】：2015-03-17 04:36:14
【问题描述】：
每次将消息重新传递给消费者时，JMSXDeliveryCount 都会递增。可以重新发送消息：
1) 使用客户端确认模式的消费者之前收到了消息，但没有对该消息调用确认（）。
2) 消费者在事务中收到消息，没有调用提交或调用回滚。
编辑：
如果 JMS 客户端由于某些错误的 JMS 标头而无法处理该消息，则此类消息（称为毒消息）将不会传递给应用程序，并且 JMS 客户端将在内部回滚该消息。在这种情况下，JMSXDeliveryCount 也会增加。
在 IBM MQ 中，您是否为从中检索消息的队列设置了 Backout Queue 和 Backout Threshold 属性？一旦达到 Backout Threshold，JMS Client 会将此类错误消息放入回退队列。这是为了避免 JMS 客户端一次又一次地检索相同的消息，从而阻止其他好的消息传递到应用程序。
【讨论】：
-
你能帮我进一步吗由于交易成功，我无法追踪原因。如果您能在这方面进一步帮助我，那就太好了...:)
非常感谢其他人，我得到了网上的答案并将其粘贴在这里，以便对其他人有所帮助。
消息可以重新传递给消费者的情况取决于会话的确认模式：
当应用程序的 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 将设置为错误代码进度。 message.jclient.Constants.UNDELIVERED_DELIVERY_LIMIT_EXCEEDED。 如果未设置“preserveUndelivered”属性，则消息将被丢弃。
- 或者，JMS 应用程序（例如基于 Pub-Sub 主题的客户端和 Sonic ESB 服务/进程）可以通过获取并处理每条消息的 JMSXDeliveryCount 属性值来自行执行检测。 JMSXDeliveryCount 属性使用 int 来指定消息的传递尝试次数。使用 javax.jms.Message.getIntProperty("JMSXDeliveryCount") 方法获取其值。每次向消费者提供消息时，此属性的值都会递增。传递计数器在客户端运行时中维护，用于等待传递给消费者对象的消息。如果消费者关闭/终止并重新创建/重新启动，则发送给消费者的每条消息的计数器将重置为 0。
【讨论】：