We had an earlier problem with an MQ Listener ports stopping for no apparent reason we looked at -
http://www.ibm.com/developerworks/websphere/library/techarticles/0405_titheridge/0405_titheridge.html
- and we set the Backout threshold property on the queue to a value greater than 0 and less than the value of the listener port's Maximum retries property. The Deadletter queue seems quite so I don't think it is a poison message
This has stopped the port from stopping but we still are getting errors in system.out and system.err as below
To resolves this issue we have to restart the whole applications, stopping and starting the listener ports does not work
Can anyone shed any light on this?
Thanks,
Jerry
SYSTEM.ERR
Also putting the close into the finalise / destroy method of the MDB may not get called either (depending on how many messages the MDB is allowed to process).
Code:
[4/9/09 9:20:10:360 BST] 263d0d22 SystemErr R javax.jms.JMSException: Failed to create queue connection
[4/9/09 9:20:10:360 BST] 263d0d22 SystemErr R at com.ibm.ejs.jms.JMSCMUtils.mapToJMSException(JMSCMUtils.java:107)
[4/9/09 9:20:10:360 BST] 263d0d22 SystemErr R at com.ibm.ejs.jms.JMSQueueConnectionFactoryHandle.createQueueConnection(JMSQueueConnectionFactoryHandle.java:86)
SYSTEM.OUT
Code:
[4/9/09 9:26:42:757 BST] 263d0d22 FreePool E J2CA0045E: Connection not available while invoking method queueRequest for resource jms/QCFMLAXGO.
[4/9/09 9:26:42:817 BST] 263d0d22 ConnectionMan E J2CA0020E: The Connection Pool Manager could not allocate a Managed Connection: com.ibm.websphere.ce.j2c.ConnectionWaitTimeoutException: Connection not available, Timed out waiting for 180000
at com.ibm.ejs.j2c.poolmanager.FreePool.createOrWaitForConnection(FreePool.java(Compiled Code))
Where can I trace the WAS pools?
Is it on the websphere side of the equation or on the MQ side...
Depends. If you need 500 connections but your max channels is set to 200 it is on the MQ side. If your WAS connections are requesting a pool of size 100 but you only allocated a pool of size 10, it is on the WAS side.
At the same time do investigate the releasing of resources by the application.
If you wait for a garbage collector to release your resources you are way way way way way too oo oo late.
The WAS app needs to release the resource as soon as it is no longer needed so that it is available in the pool... and just for safety you can add a resource release to onDestroy and finalize methods.
Take special care when doing exception handling to make sure to use the finally block to release any resource that might have been acquired in the try block and would get lost due to the exception.
Be aware that each MDB will need x connections. x = number of instances of the MDB + 1. This covers your incoming connections. You need to allocate as well your outgoing connections so that your pool is sized adequately. Note that the reply should be done on the same connection the request was picked up and in the same session (transacted).
Don't know if the JMSTopology redbook is still available (check my posts a few years back and you will find a link) but it was a very good intro for sizing the JMS pool and max connections needed on a qmgr.
For outbound connections think about concurrency of threads and realize that each thread needs its own connection.
Have fun
_________________
MQ & Broker admin
The pool having a reference to it is irrelevant. What you don't want to happen is the pool marking it as in use, i.e. the app keeping a reference to it.
_________________
MQ & Broker admin
I agree, which is why the app should close it! When the close is called the resource is retruned to the pool whether or not the app still maintains a reference to it, which i'm sure we agree it definatly shouldnt do as it cant use it again anyway!
Well the whole design of the resource pool is to initialize and hold resources to have them ready when needed. The point I was trying to make is that you should not be worried about the resources being held in the pool. You should be worried about the resources being held by the application and not being released back into the pool as soon as possible.
When the resource is not being released to the pool, the pools runs out of connections real fast and you get a weird behavior for the application which is resource starved. This may also happen if your pool size is too small.
The other point I was trying to make is that when getting a resource from the pool the app is getting the resource not in raw form but wrapped such as releasing that resource does not physically release the resource but makes it available to the pool again. The behavior to the programmer is transparent...
_________________
MQ & Broker admin
MQSeries.net Forum Index
»
IBM MQ Installation/Configuration Support
»
javax.jms.JMSException: Failed to create queue connection
Jump to:
