| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Application Managing QMGR and Q Connections |
« View previous topic :: View next topic » |
| Author |
Message
|
| queuetip |
 Posted: Tue May 08, 2007 2:01 pm Post subject: Application Managing QMGR and Q Connections |
 |
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
I am working on a Java multi-threaded application that can easily experience hundreds of concurrent sessions, each connecting to the same QMGR and Q. We aren't planning to use JMS. Each session writes numerous messages (pretty large) within a configurable syncpoint.
Ideally, I'd like to query the queue manager to see how many handles he has - then, if he's not too busy, I'd like to query the queue to see how many open handles it has before starting up a connection and syncpoint/commit.
PROPERTIES
When I look at the properties that deal with connection management, for the queue manager, I see a "MaxOpenHandles" property. That's it. The local queue has a "DefaultInputOpenOption" of either sharable/exclusive. That's it. I will conclude the queue properties do not allow me to configure the max connections on a queue.
MQINQ PROGRAM CALL
A prerequisite for MQINQ is you must already be connected to the queue manager and also have the queue open in order to inquiry. This prerequisite defeats the purpose of querying to manage connection since you have to connect to it.
HELP WANTED
Do I have this right? I really would like to be able to have the app manage connections so the user can configure the max connections as needed. Dedicating one connection for inquiry use is something I'd like to avoid. I am also not allowed to use MQ clustering. Anyone have any ideas on how to manage the connection load without connecting?
Thanks!
Mike
 |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue May 08, 2007 3:58 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can not configure maximum connections per queue. MaxActiveChannels is per queue manager.
Also, if you are using bindings connections, then MaxActiveChannels does not come in to play for your application.
It is a bad idea to write an application that will say "based on the immediate state of the qmgr, I'm going to go get all the available connections, and hang on to them." Half a second later, the MCA may decide that it needs a connection, and can't start a channel.
It's a much better idea to write your application to open a fixed number of connections, and then share them between threads, or reuse them. Then you and your MQ Administrator can *plan* for how many connections are going to be open, and *manage* the load.
The MaxHandles parameter applies *per application*, or possibly *per connection*. I believe the default is more than sufficient for most uses - it's better to stress test your application and only worry about this if you run into it.
For purposes of working with and planning connections, it's always better to pretend that MQ is a database. The same principles apply.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 09, 2007 12:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
It is a bad idea to write an application that will say "based on the immediate state of the qmgr, I'm going to go get all the available connections, and hang on to them." Half a second later, the MCA may decide that it needs a connection, and can't start a channel.
|
Aside from endorsing all of the above points, if you decide you are going for the "grab the connections and hang onto them" architecture, you may wish to consider using an application server solution that supplies connection pooling. Easier than rewriting your own. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| queuetip |
| Posted: Wed May 09, 2007 7:33 am Post subject: |
|
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
I appreciate you advice. I think that is a much better starting point. It's a little more complicated than I painted the picture to be since there are other apps using MQ that aren't designed to use an "MQ connection broker" but I think I will have the app maintain it's own max number of MQ connections that the users can adjust dynamically.
Thanks!
Mike |
|
| 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
|
|
|
|
