| Author |
Message
|
| PeterPotkay |
 Posted: Wed May 04, 2005 12:34 pm Post subject: Limiting a JMS App to 1 connection to the QM |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQServer is Win2000 SP4. MQ 5.3.0.8
MQClient is WinXP, MQ 5.306 - j5306-09-041027
JMS Client app makes more than 1 connection to the QM, even though
they only create only 1 QM object in the code.
The app utilizes JMS with a MessageListener blocking on a queue. Only 1 QM connection is made per app instance. When the app displays the search screen it begins polling on a q. Upon leaving the search screen the app issues a Close to the QueueReceiver and QueueSession. When the app user rapidly switches between the search screen and other screens, API calls to open and close q connections create a new QM connection while the original QM connection is in a "closing" state. After the creation of the second or third connection no new connections are created by rapid screen navigation.
It appears the API is pooling connections and using the 1 that is not
in the "closing" state. Older APIs (MA88) kept creating new connections
when the current connection was in a "closing" state. If we only create
1 QM object, why do we not only see 1 connection to the QM? Is there anyway to cap connection attempts to the QM at 1 per QM object?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed May 04, 2005 12:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Very unpractical and dangerous.
Read up on JMS topography and use of MQ with WAS.
As soon as you use MDB's you will have a number of "extra" connections.
Your connections in JMS should be pooled anyway.
If you are specifically using a MessageListener and not an MDB a few precautions are necessary:
stop the connection
set the MessageListener to Null on the Consumer
Close the Consumer
close the session
close the connection.
Any MessageListener should be paired with a ConnectionErrorListener...
You can call me if you need any explanation on the above.
Enjoy  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 04, 2005 12:55 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
guess I am just looking at it from the MQ admins perspective only.
This app runs on 250 desktops. Meaning I can potentially see up to 750 connections to my QM when all we have is 250 apps, if each one can grab 3 connections. That is why I was asking to cap each one at 1 connection max.
Why do you say it is dangerous? To me its dangerous when my QM is overloaded with running client channels!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 04, 2005 3:46 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The java API in general has problems letting go of rapidly opened and closed connections. You want some fun, write standard MQ Java app that will open and close a qmgr connection every second - and count how long it takes to use up all your available connections.
I think the app shouldn't close the queue session until the app is closing - unless an error is thrown. But it's been a while since I've read the JSR for JMS.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 04, 2005 5:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If possible the app should only close the session when it is done.
Now depending on the way the app does transactional processing it might need more than one session per connection.
Referring to my earlier post... if you use the connection to receive messages you need to think about the session as a thread controller.
The session controls your commit capability and your transaction boundaries...
You should use a session by message type being received...
Remember as well the importance of the connection more to connection.stop() and connection.start() which control the delivery of messages accross all sessions created from this connection....
Think of specific variables for session and connection... to be class instance variables and be reused.
There is a reason why JMS pools the connections ...
Enjoy  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 04, 2005 5:53 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I want to use Roger's Exit to limit the # of connections this app takes on its channel. With 250 users, what should the max connections be? I guessed (incorrectly apparently) that 250 would suffice. Now it looks like I have to allow 750? Maybe more?
I assume it is bad to disable pooling on the app (use the UseConnectionPooling property on the Connection Factory and set it
to false (boolean), right?) because the app will perform slowly as it needs to send everything over the 1 connection? Well, what's so bad about that? Any other app makes it just fine by sending all its MQGETS amd MQPUTs over a single connection. Why does JMS need more than 1? And if it does need more than 1, fine, I see how a pool helps, but why can't it make due with 1 connection?
The developer asked me these followup questions:
Did v5.2.2 jars support connection pooling?
The default MQ connection pool has a keep alive of 5 minutes for unused connections. Is that keep alive configurable via JMS?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 04, 2005 6:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
|
|
|
