| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Ghost queue monitoring threads |
« View previous topic :: View next topic » |
| Author |
Message
|
| educos |
 Posted: Tue Nov 19, 2002 9:03 am Post subject: Ghost queue monitoring threads |
 |
|
Apprentice
Joined: 18 Jul 2001
Posts: 34
Location: Salt Lake City, UT
|
I have a queue-monitoring Java component that uses the Java MQ API to connect to a queue manager, access a queue, and then repeatedly gets messages from the queue (times out with no msg available then looks again, etc...) The component tries to be resilient to connection errors so that it attempts to reestablish a broken/lost queue manager connection.
I noticed that even if a connection is lost, an underlying thread named "MQBindingsQMThreadn" hangs around (i.e. Thread.isAlive() == true) forever. I assume the thread is created and (should be) managed by the MQ API but it never gets cleaned up. In an environment with really bad connectivity/network congestion problems, I could foresee after a few weeks/months hundreds of those threads hanging out and not doing anything.
Is there anything I can tell the MQ API or anything I could safely do to get rid of those zombie theads?
Many thanks |
|
| Back to top |
|
 |
| nimconsult |
| Posted: Tue Nov 19, 2002 11:13 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
That's a very interesting issue.
Have you tried closing queues and/or disconnecting queue manager after you get the connection broken?
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| educos |
| Posted: Wed Nov 20, 2002 6:58 am Post subject: |
|
|
Apprentice
Joined: 18 Jul 2001
Posts: 34
Location: Salt Lake City, UT
|
Yes,
I have tried calling close() on the queue and queue manager as well as calling disconnect() on the queue manager object.
Since the API is diconnected from the queue manager, I also make sure that the MQQueue.close(), MQManager.disconnect(), and MQManager.close() are in separate try/catch blocks to make sure they all have a chance to execute.
The zombie threads are daemon threads, so they shouldn't prevent a process from exiting, but it is basically a "thread leak" for lack of a better term, and it is a problem for a long-running queue monitor in an environment where, for one reason or another, broken connections occur often. |
|
| Back to top |
|
|
| kingdon |
| Posted: Wed Nov 20, 2002 7:40 am Post subject: |
|
|
Acolyte
Joined: 14 Jan 2002
Posts: 63
Location: UK
|
You only get those threads when using bindings connections, and it is relatively unusual for a bindings connection to get broken on a production system. However, there is a gap in the code that we could tighten up to get rid of the threads (they ought to be removed during the disconnect call, but if the disconnect call fails we leave the thread in case the application wants to try again - not so clever if the connection has broken). I'll raise a defect to record the problem, and hopefully it will get fixed in a future release. If you have an urgent need to have this fixed you'll need to raise a problem through IBM support.
Thanks for pointing this out.
Cheers,
James. |
|
| Back to top |
|
|
| educos |
| Posted: Wed Nov 20, 2002 8:07 am Post subject: |
|
|
Apprentice
Joined: 18 Jul 2001
Posts: 34
Location: Salt Lake City, UT
|
That's a good point - it should be unusual to see this situation when you access the queue manager locally. However, if the queue-monitoring component wants to survive a queue manager stop for example - which is not really an unusual event - then this could still be somewhat of a problem.
Thanks for raising a defect for this problem.
In the meantime, and based on your observation that connection errors are quite unlikely in bindings mode, I don't think that this problem represents the kind of exposure I was originally worried about. Thank you. |
|
| Back to top |
|
|
| kingdon |
| Posted: Tue Nov 26, 2002 6:38 am Post subject: |
|
|
Acolyte
Joined: 14 Jan 2002
Posts: 63
Location: UK
|
Hi,
Whilst I was investigating getting this fixed, I was reminded that the latest version (MQ5.3 with CSD1) doesn't actually create the extra threads in the first place. This should reduce resource usage, give a slight performance increase and (of course) avoid this thread-leak possibility.
There's nothing like going to fix a problem and discovering it's already been done, and in a better way than I was planning to do it!
Cheers,
James. |
|
| 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
|
|
|
|
