| Author |
Message
|
| koushikt |
 Posted: Fri Jul 24, 2015 3:37 pm Post subject: How to check connection status with C APIs |
 |
|
Novice
Joined: 26 Jan 2015
Posts: 14
|
I have a mq listener written in C. I use MQCONN to connect to the Queue Manager and MQGET to listen for messages. But my messages are not that much. So, when my connection gets disconnected often and I error out on get.
How do I check if I have an active connection before I read/publish.
Thanks. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Jul 24, 2015 4:44 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You don't. Because 1 nanosecond after you get a response that the connection is there, it can be gone.
You don't call your friend on the phone, and when he answers say "OK good, you are there. I'm going to hang up now and call you back so we can talk, because now I know you are there."
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| vsathyan |
| Posted: Fri Jul 24, 2015 7:26 pm Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
A simple step you can do is to check if the queue manager object in your program is not null before you call the open/put/get/calls on the queue.
Hope my understanding is not wrong from your question.
Thanks,
vsathyan
_________________
Custom WebSphere MQ Tools Development C# & Java
WebSphere MQ Solution Architect Since 2011
WebSphere MQ Admin Since 2004 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jul 25, 2015 7:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| vsathyan wrote: |
A simple step you can do is to check if the queue manager object in your program is not null before you call the open/put/get/calls on the queue.
Hope my understanding is not wrong from your question.
Thanks,
vsathyan |
It is pointless to do that. Just because the connection is valid when you check it doesn't mean it will be valid a split second later when you actually try and use it.
Establish your connections and assume they are good and use them. MQ will give you a very specific reason code on your failed get or put or open or close or commit or backout or set or inq or etc, etc, etc if the connection is no longer valid. It is a waste of CPU cycles to check the connection before trying to use the connection.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jul 25, 2015 7:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
You don't. Because 1 nanosecond after you get a response that the connection is there, it can be gone.
You don't call your friend on the phone, and when he answers say "OK good, you are there. I'm going to hang up now and call you back so we can talk, because now I know you are there." |
The same type of questions have been asked regarding how to check to see (inquire on queue depth) if there are messages in a queue before doing an MQGET, and how to check to see if a sender channel is RUNNING before issuing an MQPUT.
The answer remains the same: You don't. You don't need to.
_________________
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 |
|
|
| tczielke |
| Posted: Sat Jul 25, 2015 8:26 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 27, 2015 4:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| If your gets are infrequent, you should consider using triggering instead of sitting in a wait loop. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jul 27, 2015 4:09 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mqjeff wrote: |
| If your gets are infrequent, you should consider using triggering instead of sitting in a wait loop. |
Yes. If the MQ Client connection only exists when it is needed, it is less likely to suffer from random network glitches. This is the rationale behind DISCINT on SENDER channels etc. If the channel is not running when its not actually needed, it is less prone to random n/w or comms stack errors.
_________________
Glenn |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Jul 27, 2015 9:52 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Set keepalive yes and socket timeout to 15 seconds in mqclient.ini
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| koushikt |
| Posted: Thu Jul 30, 2015 3:50 pm Post subject: |
|
|
Novice
Joined: 26 Jan 2015
Posts: 14
|
| Thanks everyone. I used the auto reconnect parameter from MQCONNX. I was using MQCONN so far and I never knew about the possibility of passing options. |
|
| Back to top |
|
|
|
|
