ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Triggering problem...

Post new topic  Reply to topic Goto page 1, 2  Next
 Triggering problem... « View previous topic :: View next topic » 
Author Message
Empeterson
PostPosted: Thu Sep 18, 2003 8:34 am    Post subject: Triggering problem... Reply with quote

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
View user's profile Send private message Send e-mail AIM Address
vennela
PostPosted: Thu Sep 18, 2003 9:09 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
EddieA
PostPosted: Thu Sep 18, 2003 9:23 am    Post subject: Reply with quote

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
View user's profile Send private message
Empeterson
PostPosted: Thu Sep 18, 2003 9:33 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail AIM Address
cgache
PostPosted: Wed Jun 21, 2017 3:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Wed Jun 21, 2017 4:13 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
cgache
PostPosted: Wed Jun 21, 2017 4:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Jun 22, 2017 12:25 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Thu Jun 22, 2017 5:31 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
hughson
PostPosted: Thu Jun 22, 2017 1:01 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Thu Jun 22, 2017 2:16 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
hughson
PostPosted: Thu Jun 22, 2017 2:41 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
cgache
PostPosted: Thu Jun 22, 2017 4:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Jun 22, 2017 8:00 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
cgache
PostPosted: Thu Jun 22, 2017 8:18 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » General IBM MQ Support » Triggering problem...
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.