| Author |
Message
|
| EricL |
 Posted: Tue Sep 12, 2017 8:02 am Post subject: Strange Queues like MQMON.userid.598AC98620309A0C |
 |
|
Centurion
Joined: 10 Oct 2014
Posts: 102
|
Hi
There are couple of queues created in qmgr with names like:
MQMON.userid.598AC98620309A0C
Strangely, these queues are not shown in MQ Explorer or MQ server(AIX), they might be created by MO71, is there a way to show and delete these queues?
Thanks |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Tue Sep 12, 2017 9:23 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi,
Yes, these look like MO71 reply queues. As is the default they are temporary reply queues so will probably be deleted when the MO71 application ends.
I think by default MQ Explorer doesn't show temporary queues but I suspect you can alter a setting to display them,
Not sure why you would want to either show or delete them though. Bear in mind that in order for any application to communicate via MQ it has to have queues in order to do it. Unless you are certain that a queue is not in use then deleting them is rarely a good idea.
What is the 'problem' for which deleting them seems to you like the solution ?
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| EricL |
| Posted: Tue Sep 12, 2017 10:53 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2014
Posts: 102
|
Thanks Paul.
Those temp queues are found out in Production by our 3rd party monitoring tools, since it is Prod env, we'd like to clear them.
You are right, MQ explorer by default doesn't show temp queues, still trying to figure out the ways to clear them.... |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 12, 2017 10:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricL wrote: |
| Those temp queues are found out in Production by our 3rd party monitoring tools, since it is Prod env, we'd like to clear them. |
If you're finding them when MO71 is not in use, there's a problem someplace that's making them not be temporary dynamic queues that disappear when the application closes.
If you're finding them while someone's using MO71, they're probably going to have a poor user experience when you delete them. And it's going to be like bat-the-rat deleting them as the poor soul closes and reopens MO71 in a vain attempt to do something.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Sep 12, 2017 1:13 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I still don't understand why you feel the need to 'clear' two temporary queues. I don't see how a production environment has anything to do with it. I know that "the only good queue is an empty queue" but even in a production environment you do need some messages 
If you issue some form of DIS CONN(*) TYPE(HANDLE) it should be fairly easy to work out which connection is using these queues and therefore which application, IP address etc.
I strongly suggest you find the user and see whether there is a valid reason for them running the application before getting all heavy handed.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 13, 2017 3:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Also
- The only people who should be able to use MO71 in production are fully authorized production support/operators
- temporary queues use queue files from the "ghost" pool, so you aren't accumulating additional disk space for each temporary queue
- deleting temporary queues automatically in any environment can cause unexpected havok
- It's nice if you want to scream test it, but production is the wrong enviornment to do that in.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Sep 13, 2017 11:32 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Add an alert suppression rule to your monitoring system to ignore queues starting with MQMON.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
