| Author |
Message
|
| alperb |
 Posted: Wed Jul 13, 2005 7:27 am Post subject: how to reconnect to a MQ Manager |
 |
|
Apprentice
Joined: 01 Jun 2004
Posts: 25
|
hi,
After a proper connection to MQ Manager, in some case such as network problems, restart of mqservice etc., put and get functions get 6109 and reconnect needs. I thought checking for 6109 and then reconnecting to mqmanager will solve it.
If anyone before experienced such a need do you have any other idea to overcome this problem?
thanks in advance, |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Jul 13, 2005 9:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If you lose your connection, you reconnect. What's there to overcome?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| alperb |
| Posted: Wed Jul 13, 2005 10:54 am Post subject: |
|
|
Apprentice
Joined: 01 Jun 2004
Posts: 25
|
I mean is there a rule of thumb or any adviced design for reconnecting?
for example how do you decide to reconnect after a put operatşon? Is just 6109 reason code enough to decide to reconnect? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jul 13, 2005 11:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The list of possible return codes you can get back from an MQPUT is long, and fully documented in the Application Programming Guide.
Most people won't ever get a 6109 - as most people don't use the C++ interface, from what I can tell.
The big question is not "when to reconnect". The big question is IF to reconnect, or to fail gracefully.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| alperb |
| Posted: Wed Jul 13, 2005 11:03 pm Post subject: |
|
|
Apprentice
Joined: 01 Jun 2004
Posts: 25
|
In my situation I have a service to have up-time %99.999999. So, I if a connection is lost, it has to be reconnected.
I think it is not a common issue in mq world. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 14, 2005 3:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| alperb wrote: |
In my situation I have a service to have up-time %99.999999. So, I if a connection is lost, it has to be reconnected.
I think it is not a common issue in mq world. |
It's not that uncommon.
You still haven't decided if the connection needs to be retried automatically- your requirements suggest it, but do not require it.
But suppose for a moment, you decide to retry the connection automatically. How many times is it supposed to retry? Under what kinds of situations is it okay for the connection to not be reestablished (known maintenance window for the queue manager in question or during maintenance on the network)? Under what kinds of situations should it give up trying to reconnect, even if it's not supposed to be disconnected?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| alperb |
| Posted: Thu Jul 14, 2005 4:55 am Post subject: |
|
|
Apprentice
Joined: 01 Jun 2004
Posts: 25
|
| jefflowrey wrote: |
| alperb wrote: |
In my situation I have a service to have up-time %99.999999. So, I if a connection is lost, it has to be reconnected.
I think it is not a common issue in mq world. |
It's not that uncommon.
You still haven't decided if the connection needs to be retried automatically- your requirements suggest it, but do not require it.
But suppose for a moment, you decide to retry the connection automatically. How many times is it supposed to retry? Under what kinds of situations is it okay for the connection to not be reestablished (known maintenance window for the queue manager in question or during maintenance on the network)? Under what kinds of situations should it give up trying to reconnect, even if it's not supposed to be disconnected? |
In my case, it has to re-try as long as it can after updating the operator monitoring window about it.
I would like to learn if there is a common pattern for reconnecting or deciding the cases that flushes reconnection? |
|
| Back to top |
|
|
| WillH |
| Posted: Thu Jul 14, 2005 8:35 am Post subject: |
|
|
Novice
Joined: 15 Jun 2005
Posts: 23
|
| If you're looking for a best practice, you could use IBM's channel-error-handling as an example: heartbeats and intervals, short retry counts and intervals, long retry counts and intervals, maintaining a status of Inactive/Started/Stopped/Retrying (to help debug your connectivity problem). |
|
| Back to top |
|
|
|
|
