| Author |
Message
|
| miklesw |
 Posted: Wed Jul 29, 2009 6:54 am Post subject: MQSession & QueueManager timeout behaviour |
 |
|
Newbie
Joined: 29 Jul 2009
Posts: 5
|
I am using activeX, but i guess my query also applies to the java API.
I would like to design a class that has the session and QM instansiated in by contructor , so multiple operations can be performed using the same connection.
This way the client will not need to connect to the QM for each request.
My concern is that if the user idles, the QM connection may time-out.
How does the API behave in this situation? does it fail or does it automatically reconnect?
Thanks,
Mike |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Jul 29, 2009 7:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In general, you should code your application to expect MQ return codes from each and every API call that indicate that the connection is broken and will need to be remade.
This is best practice. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 29, 2009 7:24 am Post subject: Re: MQSession & QueueManager timeout behaviour |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| miklesw wrote: |
| My concern is that if the user idles, the QM connection may time-out. |
Even if the user doesn't idle, the connection can still break and need to be re-made.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 29, 2009 8:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...my query also applies to the java API. |
Your query applies to the native MQI calls, as well. Connections can fail for a variety of reasons. As stated in a previous post (and other posts), your app shouuld catch all exceptions (ReasonCodes), and do what is necessary for the application to continue/end.
If the connection is broken, trying to reconnect n times seems to be a good choice.
_________________
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 |
|
|
| miklesw |
| Posted: Wed Jul 29, 2009 9:30 am Post subject: |
|
|
Newbie
Joined: 29 Jul 2009
Posts: 5
|
ok fair enough.
seems like I might aswell create/close connection for each request/reply..
what is the general practice? connection per message pair or global connection? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 29, 2009 9:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| what is the general practice? |
It depends. Do you expect zillions of messages to be flowing continuously? Or will be message arrival be sporadic?
_________________
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 |
|
|
| miklesw |
| Posted: Wed Jul 29, 2009 9:49 am Post subject: |
|
|
Newbie
Joined: 29 Jul 2009
Posts: 5
|
| there will be at max 10 request/reply messages per use case..depending on the outcome |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 29, 2009 10:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| miklesw wrote: |
| seems like I might aswell create/close connection for each request/reply.. |
You'll find this has a serious performance impact.
| miklesw wrote: |
| what is the general practice? connection per message pair or global connection? |
Generally it's best to have a global connection, and code to reconnect as the previous posters have indicated (retry n times then give up).
If the message traffic is intermittant, you should consider triggering the application rather than long running.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| miklesw |
| Posted: Thu Jul 30, 2009 5:05 am Post subject: |
|
|
Newbie
Joined: 29 Jul 2009
Posts: 5
|
Thanks for your help..
The queue manager class has 2 properties:
isConnected
connectionStatus
both return a boolean value indicating the status of the connection. is there a difference between these 2 values? and are they reliable enough to determine whether i need to reconnect to the qm? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 30, 2009 6:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| miklesw wrote: |
| are they reliable enough to determine whether i need to reconnect to the qm? |
To repeat the advice given at many posts through this thread (and elsewhere on the forum) check the reason code from each MQI call (or equivalent method). If the code indicates a failure, respond accordingly. There are many possible reasons the call will fail and your app should handle them all. If only by disconnecting and ending cleanly.
(A common problem with WMQ is an application that terminates without disconnecting, leaving the queue manager connection hanging)
Example: You make a call and recieve a 2019. Your application should attempt to reconnect.
Example: You make a call and recieve a 2161. Your application should put on it's coat and go home once it's finished what it's doing without throwing any exceptions.
Many codes, many responses.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
