Author |
Message
|
kordi |
Posted: Sat Jan 03, 2015 9:35 am Post subject: Cannot delete temp dynamic queues AMQ8147 |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
Hi,
I am using M071 tool to manage q managers. When I shut down VPN sesion prior to close MO71 some MQMON.* queues last. When I want to display them all by
dis q(MQMON.*)
I see all of them, but when I want to display specific queue (or delete it)
dis q(queue name)
I got error AMQ8147: WebSphere MQ object MQMON.ssds83.5182DCE0902 not found.
Do you know what is the reason and how can I get rid of these queues without restarting q manager?
Cheers |
|
Back to top |
|
 |
PaulClarke |
Posted: Sat Jan 03, 2015 11:04 am Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
I'm a little confused. What makes you think that these queues 'last' ?
These queues are created from the model definition which should be defined as temporary dynamic. These queues will then be deleted when the QM connection is ended.
If you are shutting down the VPN session while MO71 is still running then it may take MQ a few seconds (minutes) to realise that the MQ connection is no longer valid. Therefore the queues may stay around for a little while. This is standard MQ behaviour and would happen for any MQ application.
In an ideal world you should end MO71 (or disconnect from the location) before you end the VPN session. I would then expect the queues to be deleted immediately.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
kordi |
Posted: Sat Jan 03, 2015 11:09 am Post subject: |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
Thanks for reply Paul,
Well, these queues were created many days ago, that's why I think, they last for a bit longer than I expected they will.
You are right, I should (or my team mates) shut down MO71 before we disconnect from corp network but sometimes ppl forget about it. Thats why I have 10 queues which I am unable to display (when I want to display specific one) or delete these queues. And I wonder why.
Cheers |
|
Back to top |
|
 |
PaulClarke |
Posted: Sat Jan 03, 2015 12:55 pm Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
Well that seems a little strange.
Could you append the output from the commands....
DIS Q(MQMON*) all
DIS QSTATUS(MQMON*) type(handle) all
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
rekarm01 |
Posted: Sun Jan 04, 2015 12:39 pm Post subject: Re: Cannot delete temp dynamic queues AMQ8147 |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
kordi wrote: |
when I want to display specific queue (or delete it)
dis q(queue name)
I got error AMQ8147: WebSphere MQ object MQMON.ssds83.5182DCE0902 not found.
Do you know what is the reason ... ? |
For unquoted strings, runmqsc folds lowercase to uppercase. If the MQ object name includes lowercase characters, then enclose it in single quotes:
Code: |
dis q('queue name') |
|
|
Back to top |
|
 |
kordi |
Posted: Tue Jan 06, 2015 7:08 am Post subject: |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
rekarm01 You are perfectly right. I didn't notice, I have lower case string in queue name. I am able to display these queues now. Lame me
Paul These queues are still in use by MO71 utility even though I (or other people) disconnected from q manager long time ago.
Here is an example of queue status you asked for:
dis qs(MQMON.*) type(handle) all
11 : dis qs(MQMON.*) type(handle) all
AMQ8450: Display queue status details.
QUEUE(MQMON.user1.51875F932C0AC945) TYPE(HANDLE)
APPLTAG(6)\MQViewer-1.0\mqmonntp.exe) APPLTYPE(USER)
BROWSE(NO) CHANNEL(CHANNEL.MO71.SVR)
CONNAME(172.26.19.25) HSTATE(INACTIVE)
INPUT(NO) INQUIRE(NO)
OUTPUT(YES) PID(598174)
QMURID(0.0) SET(NO)
TID(920830)
URID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
URTYPE(QMGR) USERID(user1) |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Jan 06, 2015 7:18 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Looks like you have unresolved /aborted transactions and you might be left behind with some ghost messages...
What does dspmqtrn say?
Bouncing the queue manager should either clear this up or allow you to manually force rollback the transactions... ...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
PaulClarke |
Posted: Tue Jan 06, 2015 7:28 am Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
So, if you issue
DIS CHL(CHANNEL.MO71.SVR) ALL
Does MQ still think you have this SVRCONN channel running ? Perhaps you could append the results.
If you are certain that the connection has gone then this becomes one of configuring MQ to detect when a socket has died.
The easiest way of doing this is to ensure that you are using MQ V7 at least at both ends of the channel, and you have a SHARECNV of at least 1. However, you can do it with 'old' clients but using ClientIdle and TCP KeepAlive etc.
There are many forum posts and pages in the manual dedicated to detecting when the channel connection has ended so it doesn't seem worth repeating. Especially since we don't know that this is definitely your problem.
So, first step. Confirm that MQ thinks that there are channels running, which you KNOW FOR CERTAIN are no longer connected.
Then, check your settings a correct so that MQ can detect when the underlying network dies.
Regards,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
kordi |
Posted: Tue Jan 06, 2015 8:07 am Post subject: |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
fjb_saper dspmqtrn says that there are no prepared transactions.
Paul I believe you meant dis chs(name) all.
This command show many instances of this channel with RUNNING status. I think MQ still thinks these channels are in use.
I have also noticed that following stanza is missing in qm.ini. I will add it.
TCP:
KeepAlive=Yes
Unfortunatelly this is v6 mq, so I can't set up SHARECNV to 1. Is there anything more I can do to prevent mq from keeping dead sessions? |
|
Back to top |
|
 |
PaulClarke |
Posted: Tue Jan 06, 2015 8:14 am Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
yes sorry I meant DIS CHS(*) - it's been a long day
Adding KeepAlive should improve things hugely. Prior to MQ V7 we had to rely on KEEPALIVE. Unfortunately, as you probably know, the default keepalive settings are pretty large. So MQ will not notice the socket has gone for about 2 hours - you could try reducing the keepalive setting if you are allowed. However, even at two hours it will still stop a steady build-up of these channels/queues.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
kordi |
Posted: Tue Jan 06, 2015 11:33 am Post subject: |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
Thank you Paul, fjb_saper and rekarm01 for your support. I much apperciate it! Have a great, healthy and rich 2015! |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jan 06, 2015 2:04 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
kordi, we had the same problem when we first got MO71. Its not an MO71 problem, but our admins would disconnect from the network without closing things down on their laptop. The queue manager would be left holding the channel for MO71 open, because it never got the communication that the other side (the MQ Admin's laptop) is going away.
TCP Keep Alive did the trick. Not only do you have to tell the Queue Manager to use it, but it must be enabled on your server, and the value on the server must be appropriate. We set ours to 15 minutes.
Now when an MO71 user or any other MQ Client abruptly goes away without issuing an MQDISC, the queue manager knows to purge the orphaned connection (and the orphaned dynamic queue) 15 minutes later.
 _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
kordi |
Posted: Wed Jan 07, 2015 5:37 am Post subject: |
|
|
Centurion
Joined: 28 May 2012 Posts: 146 Location: PL
|
Yep, I definitely must set up this stanza in qm.ini file. Thanks Peter  |
|
Back to top |
|
 |
|