| Author |
Message
|
| Glen Shubert |
 Posted: Tue Sep 02, 2008 12:52 pm Post subject: JBOSS and MQ |
 |
|
Apprentice
Joined: 16 May 2001
Posts: 42
Location: TSYS - Columbus, GA
|
Can anyone tell me how to set up JBOSS MQ to be able to disconnect from the queue manager? I don't know anything about JBOSS, but we have an application that is using over 2048 connections from approx 5 app servers. The developers claim that they have to use persistent sessions. When they hit max connections, We end up bouncing the queue manager. How does JBOSS perform the connect and disconnect?
Thanks in advance,
Glen Shubert
_________________
Glen Shubert
Associate Director
MQSeries Technical Support
TSYS |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Sep 02, 2008 3:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
JBoss is not any different from any other J2EE app server. There is somewhere in the JBoss documentation about using a different JMS provider links on how to create the relevant JBoss JNDI and pools.
Don't know anything about persistent sessions but if the resource (MQ) gets acquire in the lifetime of the session it it the responsability of the programmer who acquired the resource to release it.
Don't know why you have to recycle the qmgr... maybe because you are running with server connections? If in client connection just force shutdown the channel and restart it when all instances are in a stopped state.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Glen Shubert |
| Posted: Wed Sep 03, 2008 7:01 am Post subject: |
|
|
Apprentice
Joined: 16 May 2001
Posts: 42
Location: TSYS - Columbus, GA
|
You have to forgive me, I am an old mainframer.... They are using client connections to the server, starting x number of connections from their EJBs based upon the function. They will send one message across, then not use that connection again, but claim they need to keep the session up. When we force disconnect the channel, they have to restart their app servers. In order to clear up the connections, we end up having to restart the queue manager. Basically, I am trying to prove them wrong, and find a way for them to police their connections themselves.
Glen
_________________
Glen Shubert
Associate Director
MQSeries Technical Support
TSYS |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Sep 03, 2008 7:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
On a z/OS queue manager, one can now set an inactive disconnect interval on client channels to help with this.
However generally this is an application design issue, if their code issues MQCONN, then it must also issue MQDISC to release the channel.
Most multi-threaded adapters use some kind of handle management logic to maintain a pool of connections, that allow efficient re-use of open connections without excessive channel connections.
I would ration any given app server to 20 concurrent connections (and no creeping up), any more and they are not allowed to implement that design.
However you can't enforce this at the queue manager level, you just have to impose this as a condition of production readiness. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 03, 2008 7:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
In MQ 7.0 you can enforce this at the SVRCONN channel level. At all versions you can use a security exit to enforce this.
You don't need to restart the QM, Glen. FORCE STOP the SVRCONN channel. They will go from STOPPING to STOPPED. Then start the SVROCNN channel. That will blow away all the STOPPED instances and start you fresh.
Search here on TCP Keep Alive as well to help clean up truly orphaned connections.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 03, 2008 7:35 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Glen Shubert wrote: |
| When we force disconnect the channel, they have to restart their app servers. |
They don't have any reconnect logic! Ask them what happens when the network blips - they gotta come in to restart their apps to recover? Tell them they need to code reconnect logic, and by the way not to drop into a tight loop trying to reconnect as fast as possible forever. Try a couple of time quickly to recover from blips, and then once every few seconds / minutes to recover from scheduled outages, channel restarts, etc.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Sep 04, 2008 4:11 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And remind them that closing a connection does not really close it but release it to the pool, in an available state. If they acquire a connection (mqfactory.createConnection() ) they NEED to CLOSE that connection!!
Leaving that task to the garbage collector IS NOT AN OPTION!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
