IBM MQ:如何知道死信的原因?

时间:2016-07-19 12:20:42

标签: jms ibm-mq

我在死信队列中看到一堆消息,我不明白是什么原因导致的。

我使用MQ Explorer浏览此类消息。这就是我在Dead-Letter Header中看到的内容:

enter image description here

这并不能告诉我问题的真正原因是什么。我该如何找到?

我已阅读this article from IBM并且它告诉原因可能是格式错误的消息。以什么方式格式错误?

(注意:我控制了生产者和消费者)

2 个答案:

答案 0 :(得分:0)

你错过了森林里的树木:-) 原因在于' Reason' 。 MQRC_BACKOUT_THRESHOLD_REACHED 这被描述为here in Knowledge Center

  

MQRC_BACKOUT_THRESHOLD_REACHED(0x93A; 2362)   原因   消息已达到QLOCAL上定义的回退阈值,但没有回退   队列已定义。在无法定义回退的平台上   队列中,消息已达到JMS定义的回退阈值   20。   行动   如果不需要,请为相关QLOCAL定义Backout Queue。还要查找多次退出的原因。

答案 1 :(得分:0)

正如我所料,MQRC_BACKOUT_THRESHOLD_REACHED原因实际上只是一种连锁反应。要找到真正的原因,您需要查看消费者端或生产者端的日志,具体取决于您在死信头(上图)的屏幕截图中的Put application name字段中看到的内容。

我现在已经了解到JMS的MQ Classes在当前目录mqjms.log.x中生成日志文件。通过观察,我可以看到问题的真正原因:

July 19, 2016 4:48:33 PM CEST[Queue Service thread] com.ibm.msg.client.wmq.common.internal.messages.WMQReceiveMarshal
A received message could not be correctly parsed.

EXPLANATION:
The message with messageID = '414D512064657620202020202020202012048D5720064E04' and correlationID = '310000000000000000000000000000000000000000000000' could not be correctly parsed. The last successful data read from the message was at position '192' in buffer '0000:  5246 4820 0000 0002 0000 00c0 0000 0111    RFH ............
0010:  0000 04b8 4d51 5354 5220 2020 0000 0000    ....MQSTR   ....
0020:  0000 04b8 0000 0020 3c6d 6364 3e3c 4d73    ....... <mcd><Ms
0030:  643e 6a6d 735f 7465 7874 3c2f 4d73 643e    d>jms_text</Msd>
0040:  3c2f 6d63 643e 2020 0000 0074 3c6a 6d73    </mcd>  ...t<jms
0050:  3e3c 4473 743e 7175 6575 653a 2f2f 2f6d    ><Dst>queue:///m
0060:  7971 7565 7565 3c2f 4473 743e 3c54 6d73    yqueue</Dst><Tms
0070:  3e31 3436 3839 3339 3731 3338 3234 3c2f    >1468939713824</
0080:  546d 733e 3c45 7870 3e31 3436 3839 3339    Tms><Exp>1468939
0090:  3734 3338 3234 3c2f 4578 703e 3c43 6964    743824</Exp><Cid
00a0:  3e49 443a 3331 3c2f 4369 643e 3c44 6c76    >ID:31</Cid><Dlv
00b0:  3e31 3c2f 446c 763e 3c2f 6a6d 733e 2020    >1</Dlv></jms>  
00c0:  3c64 6174 614d 7367 2073 656e 7454 696d    <mymessage .....
.................

' with exception '
                       Message : java.lang.Exception
                         Class : class java.lang.Exception
                         Stack : com.ibm.msg.client.wmq.internal.WMQConsumerShadow.getMsg(WMQConsumerShadow.java:1900)
                               : com.ibm.msg.client.wmq.internal.WMQSyncConsumerShadow.receiveInternal(WMQSyncConsumerShadow.java:231)
                               : com.ibm.msg.client.wmq.internal.WMQConsumerShadow.receive(WMQConsumerShadow.java:1471)
                               : com.ibm.msg.client.wmq.internal.WMQMessageConsumer.receive(WMQMessageConsumer.java:659)
                               : com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receiveInboundMessage(JmsMessageConsumerImpl.java:1036)
                               : com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receive(JmsMessageConsumerImpl.java:461)
                               : com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receive(JmsMessageConsumerImpl.java:495)
                               : com.ibm.mq.jms.MQMessageConsumer.receive(MQMessageConsumer.java:209)
                               : com.addicticks.avenuemq.client.base.connection.QueueService.recvMessages(QueueService.java:129)
                               : com.addicticks.avenuemq.client.base.connection.QueueService.run(QueueService.java:92)
                               : java.lang.Thread.run(Thread.java:745)
' with MQMD 'version:2(0x2) report:0(0x0) msgType:8(0x8) expiry:300(0x12c) feedback:0(0x0) encoding:273(0x111) codedCharSetId:1208(0x4b8) format:'MQHRF2  ' priority:4(0x4) persistence:0(0x0) msgId:414D512064657620202020202020202012048D5720064E04 correlId:310000000000000000000000000000000000000000000000 backoutCount:0(0x0) replyToQ:'                                                ' replyToQMgr:'dev                                             ' userIdentifier:'peter       ' accountingToken:160105150000008D3439C9CC13CC025B66F34BE903000000000000000000000B applIdentityData:'                                ' putApplType:28(0x1c) putApplName:'Carrefour Server            ' putDate:'20160719' putTime:'14483382' applOriginData:'    ' groupId:000000000000000000000000000000000000000000000000 msgSeqNumber:1(0x1) physicalMsgOffset:0(0x0) msgFlags:0(0x0) originalLength:-1(0xffffffff) '

EXPLANATION:
null

ACTION:
null

所以你有它。不知何故,我设法创建了一个无效的JMS消息,没有生产者方面注意到存在问题。

我需要弄清楚这一点,但这将成为另一篇文章的主题。

简而言之,问题的答案是:退出只是一种连锁反应。真正的原因是 - 正如IBM的文档所说 - 一个格式错误的消息。解决这个问题的唯一方法是查看消息生产者或(更有可能)消息使用者转储的任何日志。在我的情况下 - 因为没有涉及远程队列 - 我的消息使用者不是中间队列管理器,而是我的实际目标应用程序。那就是我找到日志的地方。