| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| DLQ |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Sat Nov 01, 2003 9:38 pm Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The 2 cases where a sending MCA will put messages to the DLQ on the sending side are as follows:
1.) Conversion error. The app put the message and it made it as far as the XMITQ, hence the app gets a good return code on the MQPUT. When the MCA tries to convert the message to send across the channel, it fails for whatever reason and the message is then put to the DLQ on the sending side.
2.) MAXMSGLENGTH error: The app puts a 10 MEG message. The XMIT queue was altered to accept the 10 MEG message length, so the message makes it onto the XMIT queue, and the app gets a good return code on the MQPUT. But the channel has a MAXMSGLENGTH of 4 MEG. The MCA can't makes its put of the message across the channel, so the message goes to the DLQ on the sending side.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| bduncan |
| Posted: Mon Nov 03, 2003 2:23 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Okay... I knew I wasn't crazy. So it is possible for messages to end up on the DLQ on the sender side...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| CuriCAT |
| Posted: Tue Dec 29, 2009 3:22 pm Post subject: |
|
|
Voyager
Joined: 26 Sep 2006
Posts: 82
|
I have the similier scenario, I don't see an answere from the existing posts. I have explained my problem here, please advice ...
In MQ clustering environment (QM_A and QM_B are clustered) some of the messages overflows cluster transmission queue during high volume of messages transmitted from QM_A to QM_B and lands in DLQ of QM_A, Can you please help us to resolve the issue.
Increasing transmission queue depth will be useful, currently transmission queue depth is 640 k? or is there any other ways ? thanks for you help...
MQ Version :
Operating system : AIX Version 5.3 on pSeries
Transmission queue depth : 640k
reason code in DLQ message header :2053
Sample Message with header
MQ Message Header
StrucId : 'MD ' Version : 2 Report : 0[MQRO_NONE] MsgType : 8[MQMT_DATAGRAM] Expiry : -1[Not Expiring] Feedback : 0[MQFB_NONE]
Encoding : 273 CodedCharSetId : 819 Format : 'MQDEAD ' Priority : 1 Persistence : 0[Not Persistent]
MsgId : X'414D51204D54475441583034202020204A87429B23971E50'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' ' ReplyToQMgr : 'MTGTAX04 '
UserIdentifier : '00mcpqa '
AccountingToken : X'0332313100000000000000000000000000000000000000000000000000000006'
ApplIdentityData : ' '
PutApplType : '6'[MQAT_UNIX] PutApplName : 'java '
PutDate : '20090827' PutTime : '05271864'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1' Offset : '0' MsgFlags : '0' OriginalLength : '-1'
MQ Dead-Letter Header
StrucId : 'DLH ' Version: 1 Reason: 2053[Q full] Encoding: '273' CodedCharSetId: '819' Format: 'MQSTR '
DestQName: 'MST.KTCFFD_FIN.IN.CIT4 ' DestQMgrName: ' '
PutApplType: '6'[MQAT_UNIX] PutApplName: 'amqrrmfa '
PutDate: '20090827' PutTime: '05330978'
Message Data
+579+020523197IXL003CLOSED +20021115+20080303DefXault OrXga
nization NN +200803 |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Dec 29, 2009 3:44 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
Hi
- this should be a new thread since it barely relates to the years-old posts that went before
- if you have a growth in qdepth, ask if it is business-as-usual or an outage somewhere downstream
- if it's business as usual then increasing the qdepth might not be such a good idea because the real issue is that you have too little power in your cluster channels to serve the queue. Solution: more channels/qmgrs, better network, better local or remote disk, fastpath cluster channels...
- if it's an outage downstream then get your architects to declare whether they are happy with that qdepth. IMHO, a Q_FULL failure to put to the SCTQ because of downstream downtime is not principally an admin's problem. It's an application/architecture problem. Maybe not all companies will view it that way, but it seems fair to put the question about qdepth to your architects rather than us random folks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 29, 2009 5:27 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| In MQ clustering environment (QM_A and QM_B are clustered) some of the messages overflows cluster transmission queue during high volume of messages transmitted... |
Hmmm. I must test this theory out - by setting a very maxdepth on the SCTQ.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 29, 2009 9:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| bruce2359 wrote: |
| Quote: |
| In MQ clustering environment (QM_A and QM_B are clustered) some of the messages overflows cluster transmission queue during high volume of messages transmitted... |
Hmmm. I must test this theory out - by setting a very maxdepth on the SCTQ. |
And remember, all it takes is for one target queue on the Destination to be full to create a backup on the xmitq, regardless of whether the target queue for the high volume messages is full or not...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 30, 2009 5:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| bruce2359 wrote: |
| Quote: |
| In MQ clustering environment (QM_A and QM_B are clustered) some of the messages overflows cluster transmission queue during high volume of messages transmitted... |
Hmmm. I must test this theory out - by setting a very maxdepth on the SCTQ. |
And remember, all it takes is for one target queue on the Destination to be full to create a backup on the xmitq, regardless of whether the target queue for the high volume messages is full or not...
Have fun |
That can be avoided by setting the receiving channe'ls Message Retry Count and Interval appropriately. The default values do cause a slowdown on the sending side when Q1 on the receiving side fills up but Q2 and the DLQ still have plenty of room.
Of course when the remote DLQ then fills up then that won't matter anyway.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
