IBM MQ : 데드 레터의 이유를 알아내는 방법?

Question

데드 레터 대기열에 여러 개의 메시지가 표시되고 있는데 어떤 원인인지 이해할 수 없습니다.

나는 이러한 메시지를 검색하기 위해 MQ Explorer를 사용하고 있습니다. 여기에 내가 데드 - 레터 헤더에서 볼 수있는 작업은 다음과 같습니다이 문제의 실제 원인이 무엇인지 말해주지 않습니다

. 어떻게 알 수 있습니까?

나는 this article from IBM을 읽었으며 그 이유는 아마도 의 형식이 잘못된 메시지이라고합니다. 어떤 식 으로든 형식이 잘못 되었나요?

(참고 : 나는 생산자와 소비자 모두의 제어에있어) 당신은 원인 필드 '이유'에 :-) 나무의 숲을 그리워

Answer 1

내가 예상했던대로 MQRC_BACKOUT_THRESHOLD_REACHED 이유는 실제로 단지 노크 효과입니다. 진짜 이유를 찾으려면 데드 - 레터 헤더의 스크린 샷 (위)에서 Put application name 필드에 표시되는 내용에 따라 소비자 측 또는 생산자 측의 로그를 조사해야합니다.

이제 JMS 용 MQ 클래스가 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의 의사가 말했듯이 잘못된 형식의 메시지입니다. 이를 파악하는 유일한 방법은 메시지 생성자 또는 메시지 소비자가 덤프하는 로그를 조사하는 것입니다. 필자의 경우에는 원격 대기열이 포함되어 있지 않으므로 메시지 소비자는 중간 대기열 관리자가 아니라 실제 대상 응용 프로그램입니다. 그것이 로그를 찾은 곳입니다.

Answer 2

. (0x93A; 2,362) MQRC_BACKOUT_THRESHOLD_REACHED 이는

MQRC_BACKOUT_THRESHOLD_REACHED here in Knowledge Center 설명하는 메시지가 QLOCAL 정의 백 아웃 임계 값에 도달 원인 을하지만은 제거 큐 정의되지 않는다. 백 아웃 대기열을 정의 할 수없는 플랫폼에서 메시지는 JMS 정의 백 아웃 임계 값 20에 도달했습니다. 조치 이 작업이 필요하지 않은 경우 관련 QLOCAL에 대한 백 아웃 대기열을 정의하십시오. 또한 다중 백 아웃의 원인을 찾으십시오.