| Author |
Message
|
| Satos |
 Posted: Thu Jan 25, 2007 6:25 am Post subject: Messages queued in channels |
 |
|
Novice
Joined: 17 Feb 2006
Posts: 10
Location: Pennsylvania
|
Hello All,
We are a Windows/Microsoft SQL Server shop. Our architecture consist of a Reference server that has a end point application that place messages to queue. the queue is a XMIT queue that send the messages to our target server where the corresponding local queue reside. There was some scheduled maintenance on the Reference server that required a reboot. Once the server came back on line there was a communication issue because the MQ Admin account was not associating with the Service Account that has Admin priviliges on the server. I resolve this by executing a script that created the association needed for MQ Admin to run under this service account. Afterwards, messages stopped. I bounced the channels and they went back into a running state. Now the messages are queuing on the sender and receiver channels and not loading to the destination queue. Can anyone help? I would like to also add that our environment is pretty simple. We do not have a Cluster environment, the channels are defined as Not Persistent, the speed is fast. No Message Broker. Any help is greatly appreciated. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Jan 25, 2007 6:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Confirm that the status of the sender and receiver channels is "RUNNING".
Confirm that there are messages on the XMITQ.
Examine the log files in <mq_install>/errors and <mq_install>/qmgrs/<qmgr name>/errors for any errors. Most of what's in there will also be in the Windows Event Viewer in the Application log.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Jan 25, 2007 7:00 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| There was some scheduled maintenance on the Reference server that required a reboot. |
To what? The queue manager? MQ?
| Quote: |
| that has a end point application that place messages to queue. the queue is a XMIT queue that send the messages to our target server where the corresponding local queue reside. |
You are placing the message directly onto the XMIT queue?  |
|
| Back to top |
|
|
| Satos |
| Posted: Thu Jan 25, 2007 7:03 am Post subject: |
|
|
Novice
Joined: 17 Feb 2006
Posts: 10
Location: Pennsylvania
|
| I was able to confirm the the sender/receiver channels are running. There are no messages in the XMIT queue and the only errors that was associated with MQ was the login failure and a TCP/IP connection error because of the login. Also, we are running 5.3. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 25, 2007 7:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Satos wrote: |
| There are no messages in the XMIT queue. |
I'm confused - if they're not queuing in the XMITQs where are you seeing these queued messages?
| Satos wrote: |
| Also, we are running 5.3. |
What CSD level?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Satos |
| Posted: Thu Jan 25, 2007 7:07 am Post subject: |
|
|
Novice
Joined: 17 Feb 2006
Posts: 10
Location: Pennsylvania
|
| The scheduled maintenance was to remove an old drive cage from the Reference server. Had nothing to do with MQ. The Authentication failure occurred after the reboot but was resolved. |
|
| Back to top |
|
|
| Satos |
| Posted: Thu Jan 25, 2007 7:11 am Post subject: |
|
|
Novice
Joined: 17 Feb 2006
Posts: 10
Location: Pennsylvania
|
| I am able to see the message counts when you select the channel status. This is the only place where I see messages. The XMIT and Local Queue Depths are zero. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 25, 2007 7:18 am Post subject: |
|
|
Guest
|
"...the channels are defined as Not Persistent, the speed is fast"
If your application creates non-persistent messages AND you have specified NPMSPEED(FAST), you have instructed the receiving end Message Channel Agent to discard the messages IF they cannot be delivered to to the destination queue OR the dead-letter-queue at the receiving end of the channel.
On the sending end:
Check that the programmer has set message persistence to PERSISTENT. If the programmer specified persistence-as-defined-at-the-queue, check the remote deinition persistence attribute persistence(yes).
Remove NPMSPEED(FAST) from the sender channel. Restore it to NPMSPEED(NORMAL).
On the receiving end:
Check that the destination queue is put enabled, max msg length is at least as big as the message you are sending, and that max queue depth is sufficiently large for the quantity of messages you are sending.
Check that a dead-letter-queue exists, that the queue manager attribute DEADQ has the name of your dead-letter-queue in it; AND that its maxdepth and max msg length are sized appropriately (see above).
Last edited by bruce2359 on Thu Jan 25, 2007 7:20 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 25, 2007 7:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Satos wrote: |
| I am able to see the message counts when you select the channel status. This is the only place where I see messages. The XMIT and Local Queue Depths are zero. |
These would be the message counts indictating how many messages have gone through the channels??? 
If your channels are running normally, I'd be worried if the counts were not zero.....
Channels don't hold messages. XMITQs hold messages. If the XMITQ depth is zero, I'd have said all the messages were processed. Or am I missing something?
Put a test message. If it stays in the XMITQ you have an issue. If it disappears and the count goes up by 1, the channel's working.
If it doesn't turn up at the expected destination you have a different problem.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Satos |
| Posted: Thu Jan 25, 2007 7:39 am Post subject: |
|
|
Novice
Joined: 17 Feb 2006
Posts: 10
Location: Pennsylvania
|
All,
We were able to determine the bottleneck. The end application use a series of SQL db tables to massage the data then place the messages to queue. Thanks all for your advice. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 25, 2007 7:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Rule #1 when troubleshooting MQ.
Eliminate Application Problems first.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Jan 25, 2007 8:09 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| jefflowrey wrote: |
Rule #1 when troubleshooting MQ.
Eliminate Application Problems first. |
Rule #2 when troubleshooting MQ
See rule #1 |
|
| Back to top |
|
|
| Satos |
| Posted: Thu Jan 25, 2007 9:01 am Post subject: |
|
|
Novice
Joined: 17 Feb 2006
Posts: 10
Location: Pennsylvania
|
| Thanks to everyone who had something constructive to say. I really appreciate the positive feedback. From the chain of post we can all tell who was sincere advisors and those who was just a jack @ss. What part of Newbie didn't you get. Please note the name on my post and if I ever post again, you can target your unappreciated comments to an audience that would entertainment your level of maturity. Everyone else, thanks again. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Jan 25, 2007 6:48 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Satos wrote: |
| I really appreciate the positive feedback. From the chain of post we can all tell who was sincere advisors and those who was just a jack @ss. What part of Newbie didn't you get. Please note the name on my post and if I ever post again, you can target your unappreciated comments to an audience that would entertainment your level of maturity. Everyone else, thanks again. |
Hmmm strikes me that the only 'unappreciated comments' came after you had identified the problem, before that all the post were trying to assist you. even after you had identified the problem those post's advice remains the same.....it is rarely an MQ issue, the first place to check is usually the application doing something strange. Just when you think it can't possibly be an application issue is the time to check again.
This site is purely voluntary. All posts should be taken at face value, nobody intends offence (except you apparently).
Newbie or not I saw nothing in any post but yours that was offensive. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 26, 2007 12:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Satos wrote: |
| What part of Newbie didn't you get. |
If you research the board a little, "Newbie" and the other titles are simply an indication of how many times someone has posted to the board. You could have 25 years experience of the product, a PhD in Computing and still be a newbie. There are people on the board with "lower" titles than Grand Master who have forgotten more about MQ than I will ever know.
Most of the Grand Masters are those of us who, on a voluntary basis, reply to the many questions that are posted here. If you found some of the answers not to your taste that that's your opinion. If you're making a point that doesn't seem to make sense (like the count in the channel status indicates the number of messages queued in the channel) then I feel I have a perfect right to query it. Likewise if any advice offered (like check for application issues before looking in MQ) was not to your liking then again I support your right to hold any opinion you choose, but if you don't want help and advice from those of us prepared to take time out of our busy days to try and offer it then please feel free not to post.
I certainly won't be offended. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
