| Author |
Message
|
| Empeterson |
 Posted: Thu Sep 18, 2003 8:34 am Post subject: Triggering problem... |
 |
|
Centurion
Joined: 14 Apr 2003
Posts: 125
Location: Foxboro, MA
|
We have a situation where a message hits a queue (Q1) and, if the trigger monitor is started, the message will go to the DLQ. Q1 has been set up for triggering, but the trigger is currently turned off. When we stop the trigger monitor, the message arrives on Q1 and stays there. As soon as we start the trigger monitor, the message gets sent to the DLQ. Why is this happening? If triggering on Q1 is turned off, what could be causing the message to go to DLQ when the monitor is on? The reason code in the dead letter header is 2079, MQRC_TRUNCATED_MSG_ACCEPTED, which implies to me that something is getting that message on that queue and doesnt know where to put the message. But if triggering is turned of, what could be getting the message?
We are running 5.2 on win2k.
_________________
IBM Certified Specialist: MQSeries
IBM Certified Specalist: Websphere MQ Integrator |
|
| Back to top |
|
 |
| vennela |
| Posted: Thu Sep 18, 2003 9:09 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
If your trigger monitor is OFF then all the messages should be on Q1.
When it is turned on, I guess your triggered application is getting the messages from Q1, but because of some error, those messages along with the error description will be put on DLQ. If your application works right then the messages will be processed and they would not go to DLQ. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Sep 18, 2003 9:23 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Which queue are you starting the trigger monitor on.
It should be the queue specified in the INITQ for Q1, not Q1 itself.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Empeterson |
| Posted: Thu Sep 18, 2003 9:33 am Post subject: |
|
|
Centurion
Joined: 14 Apr 2003
Posts: 125
Location: Foxboro, MA
|
I just went and looked at the trigger monitor myself (I was not the one who initally set it up), and whoever set it up was pointing it to Q1 and not the initiation queue, so that is the problem. Thanks for the help. 
_________________
IBM Certified Specialist: MQSeries
IBM Certified Specalist: Websphere MQ Integrator |
|
| Back to top |
|
|
| cgache |
| Posted: Wed Jun 21, 2017 3:49 pm Post subject: |
|
|
Apprentice
Joined: 27 May 2013
Posts: 28
Location: Sydney, AUS
|
| this makes no sense, i understand it was incorrectly configured to read from the queue, but what caused the 2079 error? I'm having an issue myself with message ending up on DLQ with mqrc 2079 but its not very clear why its ending up there.. what exactly does this reason code mean? any suggestions?? |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Jun 21, 2017 4:13 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| cgache wrote: |
| this makes no sense, i understand it was incorrectly configured to read from the queue, but what caused the 2079 error? I'm having an issue myself with message ending up on DLQ with mqrc 2079 but its not very clear why its ending up there.. what exactly does this reason code mean? any suggestions?? |
The problem above was because the trigger monitor had been misconfigured to point at an application queue instead of an initiation queue.
Trigger messages are all a fixed size so I the trigger monitor does not expect messages longer than a trigger message should be, and uses that as one of realising that the message it has just picked up wasn't a trigger message, and dumps it to the DLQ with the reason code MQRC_TRUNCATED_MSG_ACCEPTED.
In general the reason code means that you used the option MQGMO_ACCEPT_TRUNCATED_MSG and were then given a truncated message. The reason code informs your program that the message was truncated.
In the trigger monitor case it meant that it had got a message that couldn't be a trigger message because it was too long and thus had become truncated.
In your situation, is it also the trigger monitor that is the application DLQ-ing a message or is it some other application?
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| cgache |
| Posted: Wed Jun 21, 2017 4:24 pm Post subject: |
|
|
Apprentice
Joined: 27 May 2013
Posts: 28
Location: Sydney, AUS
|
| hughson wrote: |
| cgache wrote: |
| this makes no sense, i understand it was incorrectly configured to read from the queue, but what caused the 2079 error? I'm having an issue myself with message ending up on DLQ with mqrc 2079 but its not very clear why its ending up there.. what exactly does this reason code mean? any suggestions?? |
The problem above was because the trigger monitor had been misconfigured to point at an application queue instead of an initiation queue.
Trigger messages are all a fixed size so I the trigger monitor does not expect messages longer than a trigger message should be, and uses that as one of realising that the message it has just picked up wasn't a trigger message, and dumps it to the DLQ with the reason code MQRC_TRUNCATED_MSG_ACCEPTED.
In general the reason code means that you used the option MQGMO_ACCEPT_TRUNCATED_MSG and were then given a truncated message. The reason code informs your program that the message was truncated.
In the trigger monitor case it meant that it had got a message that couldn't be a trigger message because it was too long and thus had become truncated.
In your situation, is it also the trigger monitor that is the application DLQ-ing a message or is it some other application?
Cheers
Morag |
Hi Morag,
Thanks for your reply.
In my case the message is large (bigger than the default 4mb). It is not the same scenario as this one where it is triggered. The application is trying to send a large message and isn't getting to the destination. The message ends up on the DLQ with mqrc 2079. I have increased the max message length parameter on qmgr/queue/channel/xmitq to account for this large message, I'm wondering could this be an issue with the buffer being smaller than the message length and that is why it cannot read from the queue? |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 22, 2017 12:25 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| cgache wrote: |
| In my case the message is large (bigger than the default 4mb). It is not the same scenario as this one where it is triggered. The application is trying to send a large message and isn't getting to the destination. The message ends up on the DLQ with mqrc 2079. I have increased the max message length parameter on qmgr/queue/channel/xmitq to account for this large message, I'm wondering could this be an issue with the buffer being smaller than the message length and that is why it cannot read from the queue? |
What application (PutApplType and PutApplName from DLH) actually put the message on the DLQ? And at what end of the channel, sender or receiver, did it land up on the DLQ? If you could provide the DLQ Header you see, in your post, that would be great.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 22, 2017 5:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You have to remember, that if you are using the default client connection channel (autocreated when connecting to a svrconn), you are limited to 4MB.
To use a different size of message (bigger) you need to use either a CCDT where you specified a higher message size in the client channel definition, or a CONNX or CONNXC construct again specifying the max size of the message.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 22, 2017 1:01 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| You have to remember, that if you are using the default client connection channel (autocreated when connecting to a svrconn), you are limited to 4MB. |
Would the message end up on the DLQ if it couldn't be carried across the client channel? I think in that case you would just get a bad return code at the client application.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 22, 2017 2:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hughson wrote: |
| fjb_saper wrote: |
| You have to remember, that if you are using the default client connection channel (autocreated when connecting to a svrconn), you are limited to 4MB. |
Would the message end up on the DLQ if it couldn't be carried across the client channel? I think in that case you would just get a bad return code at the client application.
Cheers
Morag |
Why not? use JMS and pass the BOTHRESH without having specified a BACKOUT Queue... but it should have a reason of bothresh exceeded...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 22, 2017 2:41 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| hughson wrote: |
| fjb_saper wrote: |
| You have to remember, that if you are using the default client connection channel (autocreated when connecting to a svrconn), you are limited to 4MB. |
Would the message end up on the DLQ if it couldn't be carried across the client channel? I think in that case you would just get a bad return code at the client application.
Cheers
Morag |
Why not? use JMS and pass the BOTHRESH without having specified a BACKOUT Queue... but it should have a reason of bothresh exceeded... |
The answer to Why not is, if the message is too big to be carried over the client channel to the queue manager, then how can the message get to the queue manager to be placed on the DLQ? Your BOTHRESH example doesn't suffer from that additional problem.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| cgache |
| Posted: Thu Jun 22, 2017 4:06 pm Post subject: |
|
|
Apprentice
Joined: 27 May 2013
Posts: 28
Location: Sydney, AUS
|
| hughson wrote: |
| cgache wrote: |
| In my case the message is large (bigger than the default 4mb). It is not the same scenario as this one where it is triggered. The application is trying to send a large message and isn't getting to the destination. The message ends up on the DLQ with mqrc 2079. I have increased the max message length parameter on qmgr/queue/channel/xmitq to account for this large message, I'm wondering could this be an issue with the buffer being smaller than the message length and that is why it cannot read from the queue? |
What application (PutApplType and PutApplName from DLH) actually put the message on the DLQ? And at what end of the channel, sender or receiver, did it land up on the DLQ? If you could provide the DLQ Header you see, in your post, that would be great.
Cheers
Morag |
See below for DLQ Header. Also, the flow here is server-requester from one queue manager to another and THEN a client application consumer the message. The message has not gotten to the client application yet, it has failed on the receiving queue manager BEFORE the client can consume it.
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 1208
Format : 'MQDEAD '
Priority : 4 Persistence : 1
MsgId : xxx
CorrelId : xxx
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'xxx '
** Identity Context
UserIdentifier : 'mqm '
AccountingToken :
X'0000000000000000000000000000000000000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '28'
PutApplName : 'jar '
PutDate : 'xxx' PutTime : 'xxx'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1' |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 22, 2017 8:00 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| cgache wrote: |
| hughson wrote: |
| cgache wrote: |
| In my case the message is large (bigger than the default 4mb). It is not the same scenario as this one where it is triggered. The application is trying to send a large message and isn't getting to the destination. The message ends up on the DLQ with mqrc 2079. I have increased the max message length parameter on qmgr/queue/channel/xmitq to account for this large message, I'm wondering could this be an issue with the buffer being smaller than the message length and that is why it cannot read from the queue? |
What application (PutApplType and PutApplName from DLH) actually put the message on the DLQ? And at what end of the channel, sender or receiver, did it land up on the DLQ? If you could provide the DLQ Header you see, in your post, that would be great.
Cheers
Morag |
See below for DLQ Header. Also, the flow here is server-requester from one queue manager to another and THEN a client application consumer the message. The message has not gotten to the client application yet, it has failed on the receiving queue manager BEFORE the client can consume it.
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 1208
Format : 'MQDEAD '
Priority : 4 Persistence : 1
MsgId : xxx
CorrelId : xxx
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'xxx '
** Identity Context
UserIdentifier : 'mqm '
AccountingToken :
X'0000000000000000000000000000000000000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '28'
PutApplName : 'jar '
PutDate : 'xxx' PutTime : 'xxx'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1' |
Unfortunately that's only the MQMD from the message on the DLQ and not the DLH too. However the fact that the PutApplType is MQAT_JAVA (28) and PutApplName in the MQMD is 'jar' tells me that this is not a channel. Seems like the message successfully got as far as the target queue on the receiving system, so some good news, you found all the MAXMSGL attributes on the channels and transmission queues.
What is the Java application in question? Does it have buffer size maximums. And since you have client channels in here too, the earlier comments about setting MAXMSGL on those apply as well. How are you configuring your CLNTCONN?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| cgache |
| Posted: Thu Jun 22, 2017 8:18 pm Post subject: |
|
|
Apprentice
Joined: 27 May 2013
Posts: 28
Location: Sydney, AUS
|
| hughson wrote: |
| cgache wrote: |
| hughson wrote: |
| cgache wrote: |
| In my case the message is large (bigger than the default 4mb). It is not the same scenario as this one where it is triggered. The application is trying to send a large message and isn't getting to the destination. The message ends up on the DLQ with mqrc 2079. I have increased the max message length parameter on qmgr/queue/channel/xmitq to account for this large message, I'm wondering could this be an issue with the buffer being smaller than the message length and that is why it cannot read from the queue? |
What application (PutApplType and PutApplName from DLH) actually put the message on the DLQ? And at what end of the channel, sender or receiver, did it land up on the DLQ? If you could provide the DLQ Header you see, in your post, that would be great.
Cheers
Morag |
See below for DLQ Header. Also, the flow here is server-requester from one queue manager to another and THEN a client application consumer the message. The message has not gotten to the client application yet, it has failed on the receiving queue manager BEFORE the client can consume it.
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 1208
Format : 'MQDEAD '
Priority : 4 Persistence : 1
MsgId : xxx
CorrelId : xxx
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'xxx '
** Identity Context
UserIdentifier : 'mqm '
AccountingToken :
X'0000000000000000000000000000000000000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '28'
PutApplName : 'jar '
PutDate : 'xxx' PutTime : 'xxx'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1' |
Unfortunately that's only the MQMD from the message on the DLQ and not the DLH too. However the fact that the PutApplType is MQAT_JAVA (2 and PutApplName in the MQMD is 'jar' tells me that this is not a channel. Seems like the message successfully got as far as the target queue on the receiving system, so some good news, you found all the MAXMSGL attributes on the channels and transmission queues.
What is the Java application in question? Does it have buffer size maximums. And since you have client channels in here too, the earlier comments about setting MAXMSGL on those apply as well. How are you configuring your CLNTCONN?
Cheers,
Morag |
The consuming application is tibco bw and connects via bindings (through a svr-conn) so no client conn channels being used. I'm not sure about buffer size maximums, could quite possibly come into play here as I'm almost certain the maxmsgl parameters have been adjusted all the way through.. still can't figure out why it ended up on the dlq with 2079  |
|
| Back to top |
|
|
|
|
