| Author |
Message
|
| J.D |
 Posted: Tue Jun 22, 2010 1:50 pm Post subject: Purge Queue |
 |
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
Hi,
Is any Support Pack available to purge the Queue when there are output handles on it. I can do this through monitoring tool but want to automate this process.
Thank You |
|
| Back to top |
|
 |
| jeevan |
| Posted: Tue Jun 22, 2010 2:56 pm Post subject: Re: Purge Queue |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| J.D wrote: |
Hi,
Is any Support Pack available to purge the Queue when there are output handles on it. I can do this through monitoring tool but want to automate this process.
Thank You |
Here is the list of MQ Supportpacs |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 22, 2010 3:51 pm Post subject: Re: Purge Queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| J.D wrote: |
| Is any Support Pack available to purge the Queue when there are output handles on it. I can do this through monitoring tool but want to automate this process. |
Any support pac that can do a destructive get can do this for you, so you could modify a piece of sample code to do it.
It all depends on what you mean by "automate". Clearing out a queue isn't something you should need to be doing on a schedule.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| J.D |
| Posted: Tue Jun 22, 2010 4:47 pm Post subject: |
|
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
| Clients connect to several Queue Managers and they periodically sends test message to test Queue in order to check whether MQ Server is available or not. There is no expiration set on these messages by app team and they goin to this only after 3-4 months. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 22, 2010 5:02 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| J.D wrote: |
| Clients connect to several Queue Managers and they periodically sends test message to test Queue in order to check whether MQ Server is available or not. |
This is a terrible, terrible idea. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 22, 2010 11:16 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Trout very hard whoever 'designed' this...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 23, 2010 3:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| in order to check whether MQ Server is available or not. |
This technique is a way to test if the sysadmin is available or not.
_________________
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 |
|
|
| J.D |
| Posted: Wed Jun 23, 2010 4:51 am Post subject: |
|
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
| I agree it's a complex design and was developed long time back using WebSphere MQ C++ classes. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 23, 2010 5:06 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
The design (and I've seen it before) is: I'll send a message now to see if I can send a message in a little while. It's not a complex design; rather, it's a poorly thought out design.
Just because a message can be successfully sent at one precise instant in time, doesn't guarantee (assure) that a message can be successfully sent a microsecond later. Or, that a message that fails to arrive, cannot be followed immediately by a message that successfully arrives.
At best, it's a waste of network bandwidth and processor cycles.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Jun 23, 2010 6:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| J.D wrote: |
| I agree it's a complex design |
No, it's as complex as throwing a brick through a window today to see if it's open for you to climb through next week. And as pointless. Because they could have fixed the window by the time you come to do it.
This doesn't alter the advice given on cleaning up the messages which is still valid.
But seriously, push back on this as a way of determining availability.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 23, 2010 6:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Or at least alter the maxdepth of the queue they are sticking these messages on to some useful value like "1"....
You can fully justify this as their unused messages are taking up valuable space and administrative effort on your queue manager, and they can just as easily modify their code to get the message again right after they put it (this will also ensure that MQ is able to let them get messages... at least as much as putting a message ensures MQ is available does...). |
|
| Back to top |
|
|
| J.D |
| Posted: Wed Jun 23, 2010 6:14 am Post subject: |
|
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
| I will find out if anything is available from BMC vendor. Thanks for your advices on design. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Wed Jun 23, 2010 6:40 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Vitor wrote: |
| J.D wrote: |
| I agree it's a complex design |
No, it's as complex as throwing a brick through a window today to see if it's open for you to climb through next week. And as pointless. Because they could have fixed the window by the time you come to do it.
This doesn't alter the advice given on cleaning up the messages which is still valid. |
I really liked this explanation ! 
I got a question for J.D, is that true that application gets an error/exception, when tries to connect to queue manager first time ? And it gets the connection over the queue manager in second subsequent try ?
| J.D wrote: |
| ..they periodically sends test message to test Queue in order to check whether MQ Server is available or not.. |
Applications, don't they release connection after they are done with put/get message(s)?
| Vitor wrote: |
| Clearing out a queue isn't something you should need to be doing on a schedule |
Agree !
J.D : If you have ever tried rfhutil , then there is an option to purge the queue (unless it been used by some application already).
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| J.D |
| Posted: Wed Jun 23, 2010 9:01 am Post subject: |
|
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
| Register are hosting bunch of req/rsp applications sending messages through MQ. So, when the register is opened it will create a communication and keeps the connection open. All the apps sitting on register will use this single channel for their transactions. I don't know what type of error exceptions does the app gets. If app fails to put the test message in a designated Queue (used for test messages only) then register switches the connection over to the next MQ Server by taking connection parameters from .xml config file. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 23, 2010 9:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| J.D wrote: |
| If app fails to put the test message in a designated Queue (used for test messages only) then register switches the connection over to the next MQ Server by taking connection parameters from .xml config file. |
So why doesn't it just switch over if a real message fails to be put successfully? Obviously re-sending the real message on the new connection.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
