| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| messages getting stuck in transmit queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| shradha |
 Posted: Mon Apr 11, 2005 12:52 pm Post subject: messages getting stuck in transmit queue |
 |
|
Newbie
Joined: 11 Apr 2005
Posts: 1
|
A unique problem..messages are getting stuck in transmission queue at the hub and not being picked up the channel..the channels are in running state..tried resetting and running the channels again also..deleted the messages in transmit queue and resent the messages but still no luck/...
please suggest any possible solutions |
|
| Back to top |
|
 |
| JT |
| Posted: Mon Apr 11, 2005 2:30 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Two quick thoughts come to mind:
Is triggering enabled on the xmitq?
Have you checked the MQ errorlogs on the local AND the remote queue manager? |
|
| Back to top |
|
|
| PGoodhart |
| Posted: Tue Apr 12, 2005 3:34 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
Another thought, is the transmit queue on the other end put disabled?
That will create exactly what you have...
Check the logs on both ends as stated too.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| hopsala |
| Posted: Sun Apr 17, 2005 5:16 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
A few other thoughts:
1. There's a problem with the msgs (MCAUSER not authorized to put to target queue, target queue full or does not exist, and you do not have a dlq etc etc) and you have the RCVR's "message retry count" set to 9999999 or the "message retry interval" to a long time. (note: I am referring here to *message* retry, not channel retry)
This means that the channel just keeps trying to reput the message, and naturally, does not succeed, but to you it seems it is running.
2. Possibly in addition to prob1, say the channel gives up message retry and goes to RETRYING mode, but your SDR's short retry count is 100000 with a very short interval.
This means that although the channel keeps bouncing between RETRY and RUNNING mode you will not have a chance to see it, since almost immediately retries and goes back to message retry mode.
These two are probably the reason your channel does not go to RETRY and STOPPED mode even though there's a problem. About the reason the messages are not sent:
3. try setting the RCVR MCAUSER parameter to MUSR_MQADMIN or some other highly privilaged mq userid. (don't use this in production, it is a security breach, just for the sake of seeing what the prob is!)
4. see in the remote qmgr if there's a dlq defined, if not, define it! you will probably see all messages flowing to it, and if you browse them you can see what the MQRC is.
5. look at the transmission header of the msgs in the xmitq, just browse the message data and look at the beginning between XQH and MD, there you will see in binary the queue and qmanager the message is supposed to be transmitted to.
Now check in the remote qm if that is indeed it's name, and if that queue exists and is not put disabled or somethin'. (keep note that the whole thing is case sensitive)
That's all I can think of, good luck! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Apr 17, 2005 7:00 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hopsala wrote: |
1. There's a problem with the msgs (MCAUSER not authorized to put to target queue, target queue full or does not exist, and you do not have a dlq etc etc) and you have the RCVR's "message retry count" set to 9999999 or the "message retry interval" to a long time. (note: I am referring here to *message* retry, not channel retry)
This means that the channel just keeps trying to reput the message, and naturally, does not succeed, but to you it seems it is running.
|
In this case the RCVR channel would have a status of PAUSED.
| hopsala wrote: |
2. Possibly in addition to prob1, say the channel gives up message retry and goes to RETRYING mode, but your SDR's short retry count is 100000 with a very short interval.
This means that although the channel keeps bouncing between RETRY and RUNNING mode you will not have a chance to see it, since almost immediately retries and goes back to message retry mode.
|
Not likely. If the channel can't start, and is fluttering around retrying, it is not going to show RUNNING, even for a second.
| hopsala wrote: |
3. try setting the RCVR MCAUSER parameter to MUSR_MQADMIN or some other highly privilaged mq userid. (don't use this in production, it is a security breach, just for the sake of seeing what the prob is!)
|
Easier and safer to turn on Authority Events for the receiving QM, and then look in the SYSTEM.ADMIN.QMGR.EVENT queue. If its a problem with the MCAUSER ID of the RCVR channel, it will show up here. Of course, if that RCVR's channels MCAUSER is blank, it is running with the ID that the Listener is running as, which is 99.99999% going to be mqm or MUSR_MQADMIN, unless you got something funky set up.
| hopsala wrote: |
4. see in the remote qmgr if there's a dlq defined, if not, define it! you will probably see all messages flowing to it, and if you browse them you can see what the MQRC is.
|
If this was the solution, then that means the RCVR MCA was trying to put to the DLQ, and if there was no DLQ, then the channel would have already gone to STOPPED.
What MQ version are you at? You may be a victim of ghost messages in the XMITQ.
http://www.mqseries.net/phpBB2/viewtopic.php?t=14370&highlight=ghost
Or, the simplest solution, your app is putting the messages with under syncpoint, and not committing them. This will show up as messages in the XMITQ that are uncommitted. The q depth goes up, but the channel can't get them.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mq_developer |
| Posted: Sun Apr 17, 2005 7:31 am Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
| Quote: |
Or, the simplest solution, your app is putting the messages with under syncpoint, and not committing them. This will show up as messages in the XMITQ that are uncommitted. The q depth goes up, but the channel can't get them.
|
If you want to find UNCOM messages on a queue at 5.3 level of mqseries , you can make use of
| Code: |
| DIS QSTATUS <QueueName> |
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
