| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQOPEN returns 2009 after extended delay? |
« View previous topic :: View next topic » |
| Author |
Message
|
| ShaggyMoose |
 Posted: Mon Jan 30, 2006 7:57 pm Post subject: MQOPEN returns 2009 after extended delay? |
 |
|
Newbie
Joined: 30 Jan 2006
Posts: 2
Location: Sydney, Australia
|
First a brief description of what I am doing. I am using the MQ Series 5.2 client with the C API on Linux. I create a single connection to a remote queue manager which is shared amongst several threads. Before putting a request, each thread will open a dynamic reply queue to get the reply-to-queue.
Normally this works fine. However, if there has been no channel activity for around half an hour, it seems the queue manager connection is broken. This causes the next MQOPEN command to fail with a 2009 error (MQ_RC_CONNECTION_BROKEN). Once this occurs, I can re-create the connection and all is well. The problem is, it takes roughly 20 minutes for the error to be returned! During this time, my application is effectively dead. I have read a bit about KeepAlive and HBINT on this forum, but I am not sure how to apply these settings to my problem or if they are even relevant.
Note that I have absolutely no control over the remote queue manager; I am given the connection details and that is it. Also, there is no firewall between the client and manager, so the connection is not being dropped there.
Can anyone advise a good way to either avoid this problem altogether, or recover as quickly as possible. Thanks. |
|
| Back to top |
|
 |
| csmith28 |
| Posted: Tue Jan 31, 2006 12:21 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| Code: |
2009 X’07D9’ MQRC_CONNECTION_BROKEN
Connection to the queue manager has been lost. This can occur because the queue manager has ended. If the call is an MQGET call with the MQGMO_WAIT option, the wait has been canceled. All connection and object handles are now invalid.
For WebSphere MQ client applications, it is possible that the call did complete successfully, even though this reason code is returned with a CompCode of MQCC_FAILED.
Corrective action: Applications can attempt to reconnect to the queue manager by issuing the MQCONN or MQCONNX call. It may be necessary to poll until a successful response is
received. |
Is this a Permdyn Queue or a Tempdyn Queue? If it's a Tempdyn Queue is your code intelligent enough to re-create the dynqueue?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Jan 31, 2006 3:20 am Post subject: Re: MQOPEN returns 2009 after extended delay? |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ShaggyMoose wrote: |
| Also, there is no firewall between the client and manager, so the connection is not being dropped there. |
Almost certainly there is an "active" network device - possibly not even called a firewall - somewhere in the route that is killing the connection because of inactivity. (Why?) I've seen this sort of thing before. However if your organisation does not control the network policy at all points along the route, I guess there is nothing to be done except reconnect.
How about writing your app so that it only makes "short" conversations with the server? For example : Connect - open(1) - open(2) - put(1) - get(2) - disconnect. This would ensure your MQI channel doesn't go quiet for too long.
Or, in the scenario you describe, you could have a "health" thread that wakes up every 10 minutes, observes the length of time elapsed since the last activity on the hConn, and if it was a "long" time, chooses (under mutex protection of course) to MQDISC, record some internal state, and leave the next thread that wants a connection to do an MQCONN when it needs to. Thus, the connection will not go quiet for too long.
EDIT: added a little bit to the last paragraph. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 31, 2006 5:58 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Or issue an MQINQ call to get the name of the q every minute or so. Kinda create your own heartbeat to keep the connection live.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| ShaggyMoose |
| Posted: Tue Jan 31, 2006 1:00 pm Post subject: |
|
|
Newbie
Joined: 30 Jan 2006
Posts: 2
Location: Sydney, Australia
|
Thanks for the suggestions. I had already considered the options presented by mvic and Peter, but was hoping they wouldn't be neccessary. 
Since the period of time taken for the connection to break is not always consistant, I will probably go with the MQINQ heartbeat.
Thanks again. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
