| Author |
Message
|
| volkerp |
 Posted: Mon Dec 11, 2006 6:26 am Post subject: C++: Monitoring QueueManager connection status |
 |
|
Newbie
Joined: 11 Dec 2006
Posts: 2
|
Hi all.
I have to admit i'm a newbie to MQSeries, so please be gentle 
My app needs to be aware of the connection status the queue-mgr to which it connects over a tcp/ip channel.
I understand i can get the status by ImqQueueManager::connectionStatus( ). Is there a better way than calling this method periodicaly? e.g. a callback-function?
Regards
.....Volker |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Dec 11, 2006 6:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
As a newbie, introduce yourself to the search button at the top of the page. It will be your friend; though not as good a friend as the search on the Info Centre. 
Start by searching for this - it's not the first time the subject's come up.
As to monitoring the connection status, the question is not how but why? If you perform a get or a put, you'll receive a success or failure reason code. If the reason code indicates that the connection is down then this should trigger the reconnect logic within your application.
Unless you're another of the growing band trying to re-invent the wheel (or invent a better wheel) and produce an app to monitor MQ health.
Give us a bit more detail on the requirement please.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| volkerp |
| Posted: Mon Dec 11, 2006 7:38 am Post subject: |
|
|
Newbie
Joined: 11 Dec 2006
Posts: 2
|
Hi Vitor and thanks for the reply.
I sure do react to the reason codes of put and get (although my app only puts). But i seems a little bit like trial-and-error to me. I would prefer some type of event which asynchronously informs me about connection state. I also wonder about the use of the hearbeat setting in the channel. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 11, 2006 7:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| volkerp wrote: |
Hi Vitor and thanks for the reply.
I sure do react to the reason codes of put and get (although my app only puts). But i seems a little bit like trial-and-error to me.
|
Why? If it works you're fine, if not you need to take action. Also, if your program puts intermitently, does it need to know the channel's failed immediately or when it puts a message 1-n minutes later? And there's nothing "trial-and-error" about the reason codes; they turn up reliably for documented reasons with documented responses.
| volkerp wrote: |
| I would prefer some type of event which asynchronously informs me about connection state. |
I believe callback is implemented as you describe in the XMS. Exercise for the reader there. Personally, never had the inclination or requirement to do it this way.
| volkerp wrote: |
| I also wonder about the use of the hearbeat setting in the channel. |
You don't say if you're using client or server side code, though if you're worried about connections I'm guessing client! HBINT is more often associated with server side channels, and a quick search will yield you a raft of information.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon Dec 11, 2006 12:18 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| volkerp wrote: |
| ... I would prefer some type of event which asynchronously informs me about connection state. I also wonder about the use of the hearbeat setting in the channel. |
This is what MQ monitoring software is for. Do a search for this, as there are several of them. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| kayou |
| Posted: Tue Dec 12, 2006 7:47 pm Post subject: |
|
|
Novice
Joined: 05 Aug 2006
Posts: 21
|
| volkerp wrote: |
Hi Vitor and thanks for the reply.
I sure do react to the reason codes of put and get (although my app only puts). But i seems a little bit like trial-and-error to me. I would prefer some type of event which asynchronously informs me about connection state. I also wonder about the use of the hearbeat setting in the channel. |
1) "reason code" & "trial-and-error"
I learnt from MQ development experience in C++, C# and VB6 that handling reason codes is not "trial-and-error". You have to handle reason codes for at least two very normal situations :
- The queue is empty while you thought it contained messages and try to get a message from it. The reason code (after a get) will help you understand that the queue is empty and you have to wait until it contains messages.
- You try to create a shared queue while it has already been created by another application sharing it with you. The reason code helps you understand that it is an already existing queue and that you have just to open it (and not to create it).
2) concurrent programming not-familiar programmers mistake
A classical mistake programmers which are not familiar with concurrent programming usually do is to think "if they test the status of an object and find it OK, the object will remain OK until they terminate the action on it". I mean ; If queue manager has to fail, it will not wait until you terminate what you are doing on a queue, a channel, etc. |
|
| Back to top |
|
|
|
|
