| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Connection |
« View previous topic :: View next topic » |
| Author |
Message
|
| apk007 |
 Posted: Tue Jun 01, 2010 8:21 am Post subject: MQ Connection |
 |
|
Apprentice
Joined: 23 Mar 2010
Posts: 25
|
I am connectting the MQ with below code. I am able connected to MQ successfully. My case is i place the messages to MQ every 1 min once. After disconnecting the cable i get a ResonCode error but IsConnected property still show true. Is this is the right way to check if the connection is still connected ? Or there any best pratcices around that.
I would like to open the connection when applicaiton is started keep it open for ever.
public static MQQueueManager ConnectMQ()
{
if ((queueManager == null) || (!queueManager.IsConnected)||(queueManager.ReasonCode == 2009))
{
queueManager = new MQQueueManager();
}
return queueManager;
} |
|
| Back to top |
|
 |
| mvic |
| Posted: Tue Jun 01, 2010 8:29 am Post subject: Re: MQ Connection |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
If you want to find out if the queue manager is up, you are an admin and you can use the admin commands like runmqsc and dspmq.
If you want to put/get messages you are an application, and you can rely on the admins to keep the queue manager up. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 01, 2010 8:50 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
As you have discovered, there is no absolute method of determining, at a precise instant in time, whether a qmgr is available - until you/your application attempts to connect, or attempts the next MQI call.
A properly coded application will catch CompletionCode and ReasonCode for each MQI call, and take appropriate action.
_________________
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 |
|
|
| gbaddeley |
| Posted: Tue Jun 01, 2010 2:56 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
MQ v7.0 and later have an async client protocol, so MQ can do a keepalive from the client side. If the program is sitting on a blocking get, it will know very quickly if there is a network interruption.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 01, 2010 4:41 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Is this is the right way to check if the connection is still connected ? Or there any best pratcices around that. |
As gbaddeley points out, you will receive a connection broken (or possibly another) ReasonCode. This is not an indicator of whether the the connection can be immediately reestablished. Trying to reconnect is a reasonable action for an application to take. The WMQ Application Programming Guide and WMQ Application Programmning Reference offers descriptions of the WMQ calls and ReasonCodes that may be returned to the application.
There are performance monitoring tools available from IBM and other vendors, if you goal is to monitor qmgr bottlenecks and availability.
_________________
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 |
|
|
| gbaddeley |
| Posted: Wed Jun 02, 2010 4:47 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
You should use symbolic names:
| Code: |
| if ((queueManager == null) || (!queueManager.IsConnected)||(queueManager.ReasonCode == MQRC_CONNECTION_BROKEN)) |
You didn't say if you were using Client or Binding mode connection. Binding is much more reliable than Client and generally you don't need to be concerned about MQRC_CONNECTION_BROKEN. If the queue manager fails in Binding mode, you are more likely to experience one of the several reason codes related to invalid handles or quiescing. These reason codes can occur on any call to MQ. In most cases, an application receiving any unexpected reason codes should produce a diagnostic message (including qmgr and queue name), and then shutdown, restart or reconnect. If the qmgr is unavailable, it should also have a delay before reconnecting, eg. 1 minute.
_________________
Glenn |
|
| 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
|
|
|
|
