在WebSphere MQ中增加JMSXDeliveryCount的条件是什么.我需要所有可能发生的场景.
每次将消息重新传递给消费者时,JMSXDeliveryCount都会递增.可以重新传递消息:
1)使用客户端确认模式的消费者先前收到的消息没有在该消息上调用acknowledge().
2)消费者在事务中收到消息,没有调用提交或调用回滚.
编辑:
如果JMS客户端由于某些错误的JMS头而无法处理该消息,则此类消息(称为"有害消息")将不会传递给应用程序,而JMS客户端将在内部回滚该消息.在这种情况下,JMSXDeliveryCount也会递增.
在IBM MQ中,是否为要从中检索消息的队列设置了"回退队列"和"回退阈值"属性?一旦达到回退阈值,JMS客户端就会将这些错误消息放入回退队列.这是为了避免JMS客户端一次又一次地检索到相同的消息,从而阻止其他好消息被传递给应用程序.
非常感谢其他人,我得到了网上的答案并将其粘贴在这里,以便对其他人有所帮助。
消息可以重新传递给消费者的情况取决于会话的确认模式:
当应用程序的 onMessage() 方法抛出异常时,选择 AUTO_ACKNOWLEDGE 或 DUPS_OK_ACKNOWLEDGE 确认模式的非事务性会话会将消息重新传递给使用者。客户端运行时捕获异常,然后再次调用 onMessage()。异常被捕获并报告给 Connection 的 ExceptionListener。设置重新传递尝试的限制会限制重新传递计数。请参阅下面的注释。
选择 SINGLE_MESSAGE_ACKNOWLEDGE 或 CLIENT_ACKNOWLEDGE 确认模式的非事务性会话,当应用程序调用 Session.recover() 时会重新传递消息。
使用 TRANSACTED 确认模式,当应用程序回滚事务时会重新传递消息。
应用程序可能会陷入循环,重复接收导致应用程序失败的消息,然后一次又一次地重新传递相同的消息。无限重发循环有时被称为“毒药消息场景”。
超过重新传送限制且尚未确认的消息将根据消息中指定的属性进行处理或将被丢弃。
如果消息属性 JMS_SonicMQ_preserveUndelivered 设置为 true,则消息将放置在 SonicMQ.DeadMessage 队列(或由 JMS_SonicMQ_destinationUndelivered 属性指定的备用目的地)上,并且消息属性 JMS_SonicMQ_undeliveredReasonCode 将设置为错误代码 progress.message.jclient .Constants.UNDELIVERED_DELIVERY_LIMIT_EXCEEDED。如果未设置 'preserveUndelivered' 属性,则消息将被丢弃。
| 归档时间: |
|
| 查看次数: |
7880 次 |
| 最近记录: |