| Author |
Message
|
| francoisvdm |
 Posted: Tue Jun 02, 2009 1:51 am Post subject: PCF command MQCMD_CLEAR_Q and if the queue is open |
 |
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
If you send the PCF command MQCMD_CLEAR_Q to the command server it will not clear the queue if the open count on the queue is more than zero. It will return the error MQRCCF_OBJECT_OPEN X’00000FA4’.
Is there a way to force this command....or a different one to clear the queue anyway?
Or, can I force close all opens? ... and then issue this PCF command?
Thank you
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jun 02, 2009 2:02 am Post subject: Re: PCF command MQCMD_CLEAR_Q and if the queue is open |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| francoisvdm wrote: |
| a different one to clear the queue anyway? |
It's simple enough to use an app/support pac to use a series of destructive gets to clear the queue (as MQExplorer offers).
| francoisvdm wrote: |
| Or, can I force close all opens? ... and then issue this PCF command? |
You can obtain the open handles and disconnect them. Obviously how the applications in question will respond to this is specific to your site.
But if you're clearing a queue that's in use I imagine you've already considered this, and the impact of the loss of the messages in question.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Tue Jun 02, 2009 2:07 am Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
Thanks, I guess it will have to be the "destructive get" approach, and it will have to be coded in C... I need the speed on deep queues.
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 02, 2009 2:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| francoisvdm wrote: |
| I need the speed on deep queues. |
If you're building up deep queues of unprocessed messages that need to be cleared administratively, sounds like you need a design review as well! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Tue Jun 02, 2009 2:42 am Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
No I do not.... this works fine for the required business process.
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 02, 2009 2:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| francoisvdm wrote: |
| No I do not.... this works fine for the required business process. |
I was simply pointing out it's unusual to have a queue of unprocessed messages so deep you need compiled C to clear it administratively. It's certainly not best practice to hold so much which is clearly redundant.
But pardon me for offering a helpful suggestion. Should have paid more attention to your signature I suppose, and the circumstances in which you created it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Tue Jun 02, 2009 9:28 am Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
No problem mate.... I'm sure we have all came across some unusual circumstances .... please keep on pointing out those things, it is helpful for all.
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 02, 2009 2:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Francois, you don't need c for better speed. What you need is a very fast lan connection or to be located on the server. Here are some examples of speed obtained through a client connection by a standalone JMS program...
20090602 09:21:25.000502-0400 XXXXXXXXP1 Queue=XXXXXXXXXXA 208282 records deleted 00:01:52.371
20090602 09:23:18.000576-0400 XXXXXXXXP2 Queue=XXXXXXXXXXXA 184643 records deleted 00:01:02.048
So we deleted on a remote qmgr 208,282 messages in less than 2 minutes.
And 184,643 messages on the same box as the java program in a little bit over 1 minute. Commit interval is every 1,000 messages.
I'd say that's pretty impressive don't you think? 
[edit]Ref MQ V 6.0.2.5 (soon to be 6.0.2.6) on AIX 5.3 and a 100 GB ethernet connection[/edit]
_________________
MQ & Broker admin
Last edited by fjb_saper on Tue Jun 02, 2009 8:08 pm; edited 2 times in total |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Jun 02, 2009 4:20 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Yep, using MQ client MQGET to remove messages is pretty fast if the app doesn't provide a Message Data buffer.
_________________
Glenn |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Tue Jun 02, 2009 8:33 pm Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
Yes it is...in isolation.... BUT on a big very busy message broker system with not the fastest CPU and network, remote databases....lots of integration points... every little bit you can safe means you delay the customer from buying more HW and SW, a saving in the end that is not to be sneezed at.
Also if there might be a few human interfaces on the other side that is let frustrated by waaaaaaitinggggg then you score even brownie points.
In the end it all ads up......
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Jun 02, 2009 8:45 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated. |
Should that be:
If you do not know the answer AND (you get the urge to answer with "RTFM" OR "Search better in this forum"), please refrain from doing so, just move on to the next question. Much appreciated.
I add:
If you do know the answer AND (you get the urge to answer with "RTFM" OR "Search better in this forum"), please do so, and give a meaningful hint at the answer, give the manual name & link, give the link to the best search result. This saves a lot of time and frustration for the asker and improves their regard for this forum and the kind knowing people who frequent it.
_________________
Glenn |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 02, 2009 9:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| francoisvdm wrote: |
| Thanks, I guess it will have to be the "destructive get" approach |
And hope the app didn't open the queue with the exclusive option, otherwise your MQOPEN won't work.
I really wish we had a Clear Q command that worked regardless of whether the q was opened, exclusivly or otherwise.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Tue Jun 02, 2009 11:25 pm Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
| gbaddeley wrote: |
| Quote: |
| If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated. |
Should that be:
If you do not know the answer AND (you get the urge to answer with "RTFM" OR "Search better in this forum"), please refrain from doing so, just move on to the next question. Much appreciated.
I add:
If you do know the answer AND (you get the urge to answer with "RTFM" OR "Search better in this forum"), please do so, and give a meaningful hint at the answer, give the manual name & link, give the link to the best search result. This saves a lot of time and frustration for the asker and improves their regard for this forum and the kind knowing people who frequent it. |
lol.... yes, maybe, but people that answer with RTFM will usually also not go the extra step
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Tue Jun 02, 2009 11:27 pm Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
| PeterPotkay wrote: |
| francoisvdm wrote: |
| Thanks, I guess it will have to be the "destructive get" approach |
And hope the app didn't open the queue with the exclusive option, otherwise your MQOPEN won't work.
I really wish we had a Clear Q command that worked regardless of whether the q was opened, exclusivly or otherwise. |
Yes...will make life so much easier, but I guess will also add another stupid thing that stupid designers / architects will misuse in their effort to cut corners.
Funny, had a situation 2 days ago where "exclusive" open on a queue caused another flow to go into a tight loop (yes, stupid design from somebody) .... but yes, it did crippled the broker.... sigh
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
|
|
