| Author |
Message
|
| osullivj35 |
 Posted: Thu Apr 09, 2009 1:54 am Post subject: javax.jms.JMSException: Failed to create queue connection |
 |
|
Newbie
Joined: 13 Jan 2009
Posts: 6
|
Hi,
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
| 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))
|
 |
|
| Back to top |
|
 |
| WMBDEV1 |
| Posted: Thu Apr 09, 2009 2:08 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
It looks like the pool of resources is full. Does this work for a while and then stop? I think something is not closing the resource properly.
You can trace the WAS pools to see how many aree free / used. |
|
| Back to top |
|
|
| osullivj35 |
| Posted: Thu Apr 09, 2009 2:44 am Post subject: |
|
|
Newbie
Joined: 13 Jan 2009
Posts: 6
|
Yep..it does work for a while and then stop. When you say 'something is not closing the resource properly' would this be on the Mainframe or Websphere side of the equation
Is there a garbage collector that can look for inactive resources?
Where can I trace the WAS pools? |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Apr 09, 2009 2:49 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| This is the Java code in WAS. In your code you will perform a JNDI lookup to get the queue object. When you are finished with the queue you should close it. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Apr 09, 2009 2:55 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| WMBDEV1 wrote: |
| This is the Java code in WAS. In your code you will perform a JNDI lookup to get the queue object. When you are finished with the queue you should close it. |
Sorry read your trace again, it could be the QCF that needs closing.
Last edited by WMBDEV1 on Thu Apr 09, 2009 3:06 am; edited 2 times in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 09, 2009 2:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| osullivj35 wrote: |
Yep..it does work for a while and then stop. When you say 'something is not closing the resource properly' would this be on the Mainframe or Websphere side of the equation
Is there a garbage collector that can look for inactive resources?
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 |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Apr 09, 2009 3:21 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| fjb_saper wrote: |
| If you wait for a garbage collector to release your resources you are way way way way way too oo oo late. |
I agree but unless you call close this may not ever happen as the pool will still have a reference to it.
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). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 09, 2009 12:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| WMBDEV1 wrote: |
| fjb_saper wrote: |
| If you wait for a garbage collector to release your resources you are way way way way way too oo oo late. |
I agree but unless you call close this may not ever happen as the pool will still have a reference to it.
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). |
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 |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Apr 09, 2009 1:46 pm Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| fjb_saper wrote: |
| The pool having a reference to it is irrelevant |
Not as far as the garbage collector is concerned which is the point I was trying to make. If the pool has a ref to it, it will not be GC'd
| fjb_saper wrote: |
| What you don't want to happen is the pool marking it as in use, i.e. the app keeping a reference to it |
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! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 09, 2009 9:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| WMBDEV1 wrote: |
| fjb_saper wrote: |
| The pool having a reference to it is irrelevant |
Not as far as the garbage collector is concerned which is the point I was trying to make. If the pool has a ref to it, it will not be GC'd
| fjb_saper wrote: |
| What you don't want to happen is the pool marking it as in use, i.e. the app keeping a reference to it |
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 |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Fri Apr 10, 2009 1:15 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| I think we are violently agreeing so i'll say no more! |
|
| Back to top |
|
|
|
|
