| Author |
Message
|
| divyadam |
 Posted: Sun Oct 20, 2019 8:42 am Post subject: SYSTEM.CLUSTER.TRANSMIT.QUEUE |
 |
|
Novice
Joined: 03 Oct 2018
Posts: 22
|
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sun Oct 20, 2019 9:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What issue? Clean up what?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| divyadam |
| Posted: Sun Oct 20, 2019 11:05 am Post subject: |
|
|
Novice
Joined: 03 Oct 2018
Posts: 22
|
there are around 12Million messages stuck in the Cluster transmit queue. Right now the Manager is trying to re-reference them back to SYSTEM.CLUSTER.TRANSMIT.QUEUE. The QMGR is trying to recover messages and can't be accessed.
the best way think right now is to dump all those messages either by deleting the SYSTME.CLUSTER.TRANSMIT.QUEUE and recreating it.
Need help with that. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Oct 20, 2019 12:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| divyadam wrote: |
there are around 12Million messages stuck in the Cluster transmit queue. Right now the Manager is trying to re-reference them back to SYSTEM.CLUSTER.TRANSMIT.QUEUE. The QMGR is trying to recover messages and can't be accessed.
the best way think right now is to dump all those messages either by deleting the SYSTME.CLUSTER.TRANSMIT.QUEUE and recreating it.
Need help with that. |
| Quote: |
| the Manager is trying to re-reference them back to SYSTEM.CLUSTER.TRANSMIT.QUEUE. |
What does this mean? Who is the Manager?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Oct 20, 2019 2:40 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
|
| Back to top |
|
|
| divyadam |
| Posted: Sun Oct 20, 2019 8:17 pm Post subject: |
|
|
Novice
Joined: 03 Oct 2018
Posts: 22
|
thanks for the info.
I can't bring up the QMGR which is down. even if I bring it up I don't want to flood it with millions of messages; which doesn't add any value.
My plan is to stop Cluster Sender channel to faulty Manager and then delete the Cluster transmit queue and them recreate it.
the challenge here is - Cluster transmit queue is a SYSTEM object. need help to remove / delete a system object and then recreate it.
runmqsc can't do it. what other tools that I can use to deal with system objects. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Oct 20, 2019 8:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| divyadam wrote: |
thanks for the info.
I can't bring up the QMGR which is down. even if I bring it up I don't want to flood it with millions of messages; which doesn't add any value.
My plan is to stop Cluster Sender channel to faulty Manager and then delete the Cluster transmit queue and them recreate it.
the challenge here is - Cluster transmit queue is a SYSTEM object. need help to remove / delete a system object and then recreate it.
runmqsc can't do it. what other tools that I can use to deal with system objects. |
Don't do it that way.
First change the xmitq to have one per qmgr (see cluster documentation).
The one to the offending qmgr should then hold only messages for that qmgr. You can then clear it without risking loss of messages to other qmgrs.
Once it is cleared you can force remove the qmgr from the cluster.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Oct 21, 2019 3:11 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| divyadam wrote: |
| runmqsc can't do it |
What makes you believe that runmqsc can't delete a system object, that is different from the constraints on deleting any type of object?
_________________
Glenn |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Oct 22, 2019 12:15 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| gbaddeley wrote: |
| divyadam wrote: |
| runmqsc can't do it |
What makes you believe that runmqsc can't delete a system object, that is different from the constraints on deleting any type of object? |
And "strmqm -c" would recreate all system objects with default settings.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| markt |
| Posted: Tue Oct 22, 2019 2:19 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| Quote: |
| What makes you believe that runmqsc can't delete a system object, |
There's a couple of system queues that are very hard to delete because they are kept permanently open by queue manager processes. If you're a member of a cluster, then the xmitq is opened pretty much as soon as the qmgr starts. SYSTEM.AUTH.DATA.QUEUE is another such. If you ever really wanted to do that (and as has been said here, it's not a good idea), I think you'd be forced down the route of deleting files outside the qmgr |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Oct 23, 2019 12:44 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| markt wrote: |
| Quote: |
| What makes you believe that runmqsc can't delete a system object, |
There's a couple of system queues that are very hard to delete because they are kept permanently open by queue manager processes. If you're a member of a cluster, then the xmitq is opened pretty much as soon as the qmgr starts. SYSTEM.AUTH.DATA.QUEUE is another such. If you ever really wanted to do that (and as has been said here, it's not a good idea), I think you'd be forced down the route of deleting files outside the qmgr |
You could start a QMgr with the command
| Code: |
| strmqm -ns <Name of the QMgr> |
This command start a QMgr without channels. listener, channel inititator etc. This wouldn't affect access to the SYSTEM.AUTH.DATA.QUEUE, but the SYSTEM.CLUSTER.TRANSMIT.QUEUE should be free. You then should be able to clear this queue - or read messages out of the queue with "dmpmqmsg". "dmpmqmsg" is able to read messages by time stamp or - even better in this case - by correlation id. The correlation id of messages in the SYSTEM.CLUSTER.TRANSMIT.QUEUE is the name of the channel, which should transfer the message.
So there is no need to delete the queue.
_________________
Regards
Hubert
Last edited by HubertKleinmanns on Thu Oct 24, 2019 12:49 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 23, 2019 9:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
It should be trivial to move the messages from the S.C.T.Q. to another temp queue or file using your favorite MQ Admin tool.
But all you are doing is addressing the symptom. What will prevent new messages from finding themselves in the same situation?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Oct 24, 2019 2:10 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
Hi Peter,
| PeterPotkay wrote: |
It should be trivial to move the messages from the S.C.T.Q. to another temp queue or file using your favorite MQ Admin tool.
But all you are doing is addressing the symptom. What will prevent new messages from finding themselves in the same situation? |
But the question was:
| Quote: |
... I need to clean up SYSTEM.CLSUTER.TRANSMITT.QUEUE ...
need help / instructions on how to delete the "SYSTEM.CLUSTER.TRANSMIT.QUEUE" and recreate it to get by this issue. |
and
| Quote: |
I can't bring up the QMGR which is down. even if I bring it up I don't want to flood it with millions of messages; which doesn't add any value.
My plan is to stop Cluster Sender channel to faulty Manager and then delete the Cluster transmit queue and them recreate it.
the challenge here is - Cluster transmit queue is a SYSTEM object. need help to remove / delete a system object and then recreate it. |
My last post is an answer to the last quote.
Then divyadam should look at new incoming messages and which tool creates these messages.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Oct 24, 2019 2:24 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
divyadam,
first you should cleanup the S.C.T.Q as I described before (strmqm -ns ...).
Then you should stop and start the QMgr in normal mode (without "-ns").
Now have a look, if new messages arrive and stuck in the S.C.T.Q. Have a look at the queue status with
| Code: |
| DISPLAY QSTATUS(SYSTEM.CLUSTER.TRANSMIT.QUEUE) TYPE(HANDLE) ALL |
Check if here are any applications, which write to the S.C.T.Q.
- When you find an application: Stop it.
- When the message come across the channel: Stop the incoming channel.
- Check the CorrelationID of the messages in the S.C.T.Q: They contain a channel name, which should transfer these messages. Check this channel.
- Check the cluster information with "DISPLAY QCLUSTER(*) ALL" and "DISPLAY CLUSQMGR(*) ALL" and look for any "unknown" objects.
Hope this helps.
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
