| Author |
Message
|
| lyntongrice |
 Posted: Mon Jan 23, 2012 9:55 am Post subject: C code to simply PING MQ QueueManager to see if alive? |
 |
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
I would like to have a THREAD in C that simply "pings" the MQ queue manager to see if it is still alive.....meaning if it get an MQRC_CONNECTION_BROKEN etc then it must shutdown the entire application....
Any ideas which C API call I can make to do this?
Thanks for the help, much appreciated 
Lynton |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Jan 23, 2012 10:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| lyntongrice |
| Posted: Mon Jan 23, 2012 10:07 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Yeah.....but which function call must I make? I do not want to try connect to MQ every 5 seconds or will that be ok?
I was hoping there would be a simple function like MQPING(&conn) ?
Just curious what would be considered "best practice" in this case if it needs to check availability every 2 to 5 seconds?
Thanks |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 23, 2012 10:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
No, you don't want to reconnect every 5 seconds.
In general, you don't want to ping the qmgr to see if it's available.
In general, you attempt to do real work against the queue manager, and if it's not available you will get an error telling you this, and then you can for example attempt to reconnect.
So, recommended practice is not to do what you think you want to do.
You could, however, use MQINQ. This will fail if the qmgr is not available.
But again, not recommended. |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Mon Jan 23, 2012 10:20 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
OK....let me explain my reasoning......then you will see why I need this:
So you have the following middleware written in C:
adapter_1 -> engine -> adapter_2
Let's say the "adapter_1" is something like a socket server / HTTP server or similar.....and "adapter_2" sends the message to MQ...
So essentially adapter 1 waits for messages and when one arrives it sends it to MQ....
NOw what happens is the system is IDLE and the queue manager goes down? The process will just keep running as it does not know yet the MQ is down....it will only know when another message arrives....
That is why I wanted to have a seperate thread "above adapter 2" that PINGS MQ and will exit the entire application if the connection breaks....(or try re-connect I suppose)...
Essentially I do not want to have to WAIT for another message to arrive before knowing MQ is down....
Thanks for th ehelp on this, much appreciated
Lynton |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 23, 2012 10:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
v7.0.1 and later will auto-reconnect for you, if you configure the connection to support it.
And you can configure a handler to receive information about reconnection events, including deciding to shut everything down. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 23, 2012 10:24 am Post subject: Re: C code to simply PING MQ QueueManager to see if alive? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lyntongrice wrote: |
| I would like to have a THREAD in C that simply "pings" the MQ queue manager to see if it is still alive.....meaning if it get an MQRC_CONNECTION_BROKEN etc then it must shutdown the entire application.... |
There are a number of ways of getting a MQRC_CONNECTION_BROKEN when the queue manager is alive, well, and skipping happily through the proverbial field of daisies. Likewise a dead queue manager can (and probaly will) return a different code than that.
There are more traditional ways to health check a queue manager, most of which have been discussed in this forum over the years.
I'm also interested to determine why you plan to use a new thread / application to monitor the queue manager, when the logical place for such a check is the application trying to use the queue manager. This is (one would hope) currently checking to see if the queue manager is responsive as it processes and can alert in the event of a failure.
Remember a queue manager can be running perfectly normally (i.e. accepting connections) and still be unusable by a given application (e.g the transmission queue is full).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 23, 2012 10:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lyntongrice wrote: |
| Essentially I do not want to have to WAIT for another message to arrive before knowing MQ is down.... |
Whatever you have monitoring the queue manager should alert you to that kind of major failure.
I'm assuming your site doesn't establish a client connection to each of it's databases once every 5 seconds to see if they're active. It's the same principle.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Mon Jan 23, 2012 10:30 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
You said "This is (one would hope) currently checking to see if the queue manager is responsive as it processes and can alert in the event of a failure. "
But in my adapter -> adapter scenario above how would that work in a "single threaded process"? I mean if the socket server is waiting for an incoming message then the other adapter connecting to MQ would not even know about this "queue manager down" until a message arrived via the socket....
This is VERY NB as the QM can be down and there are still processes connected to it without even knowing it is down....
Then if you try a STRMQM it will yell at you until those processes are killed....we have had this in PROD before....that is why I find it crucial to know about the QM status....
Am I totally wrong here? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 23, 2012 10:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lyntongrice wrote: |
| Am I totally wrong here? |
IMHO yes. If the queue manager has crashed completely (and if it's doing it frequently enough that you're thinking about checking it you have a different and more serious problem with your queue manager!) then the system level monitoring you have in place should be raising tickets with all relevant parties in the same way it would be if your database crashed.
In this context I mean "system level monitoring" to be everything from Tivoli at one extreme to some scripts the sys admins knocked up at the other.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 23, 2012 1:55 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Sounds simple enough: "is the qmgr alive?
But the practical reality is that there are many, many components that must be functioning for applications to function correctly. Channels must be able to come into RUNNING state, queues must NOT have reached MAXDEPTH, triggers must be enabled, trigger monitor apps must be running, the qmgr must have sufficient o/s-level resources to respond to app requests...
It's complicated.
_________________
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 |
|
|
| mqjeff |
| Posted: Mon Jan 23, 2012 2:04 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Again, you may be able to avoid your extra thread by using the autoreconnect options. These can potentially call a handler that will decide to close down the application. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 23, 2012 4:14 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Even if you come up with the absolute perfect solution for your little app to check if the QM is up, it doesn't mean that 0.000000001 milliseconds after you check and get a good response that the QM can't crash - meaning you have to plan for the QM not being available no matter what you do.
Having multiple QMs available and using something like an MQ Channel Table will allow you to connect to one of many, and if you assume there will always be at least one target available, you can rely on it just working 99.9999999% of the time. It will always be possible no matter what you do that you might not be able to connect to a QM, so you have to code for it.
The DB analogy is a good one. You don't test to see if the DB is up prior to using it each time. Likewise you don't pick up the phone to call your buddy to see if the phone is working, then hang up and call him right back for real.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 23, 2012 6:04 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| Likewise you don't pick up the phone to call your buddy to see if the phone is working, then hang up and call him right back for real. |
You don't?
[edit]
Oddly, there is a parallel here to your calling your buddy example.
When you lift the handset (go off-hook, in phone-speak), the switch (phone system hardware/software) validates that there is a circuit available that will allow the call to proceed (but not necessarily complete). The phone company returns a dial-tone, phone-speak for a CompletionCode of OK.
[/edit]
_________________
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 |
|
|
| fjb_saper |
| Posted: Mon Jan 23, 2012 9:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And if you absolutely must check whether a qmgr is available or not, I believe a pcf PING QMGR request is in order...
You'll have to look up the pcf control interface though...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
