Re: Borrow broker from pool failed. in production server
hi; The problem is resolved using : connection-pool maxActive=1000 whenExhaustedAction=2/ so it s strange the message gived by ojb tel us about the broker pool problem but the solution was the growing the connection pool ! thx for all. On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Marwane wrote: thx. if i don't defin the connection-pool clause in the repository.xml what is the default behavor about the connection managment in ojb ? I think by default 30 connections (docs says 21) managed by the pool (if you specify one of the pooling ConnectionFactory implementations in OJB.properties file). The other properties please see docs http://db.apache.org/ojb/docu/guides/repository.html#Attributes-N10284 http://db.apache.org/ojb/docu/guides/connection.html regards, Armin On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Hi, Marwane wrote: thx for your reply. so we use only the maxActive declared in OJB.properties. in the repository.xml we dont use the connection-pool elements. Keep in mind that OJB use two different pools by default. An PB-pool (settings in OJB.properties file) and a connection-pool (setting within the connection-pool element in repository file). we use maxActif in 1000 the problem persist. It seems that the error is caused by the broker-pool and not by the connection-pool. Normally the connection is associated with the PB when PB-tx starts or a query is performed - thus always after the PB is requested from the PB-pool. If the suggestions from Eric and Dennis doesn't solve your problem I suppose you have a PB leak in your code. regards, Armin regards. On 10/26/06, Dennis Bekkering [EMAIL PROTECTED] wrote: when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis 2006/10/26, Marwane [EMAIL PROTECTED]: hi we have a web application on production used about 500 users. we use default value of ojb parameters (maxActif: 100 ). we are getting frequently the message indicating that we can't borrow connection from pool. even if we use maxActif in 1000 the problem persist. we need your help and give us some leads. stack trace : org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=* at java.lang.Throwable.init(Throwable.java:195) at java.lang.Exception.init(Exception.java:41) at java.lang.RuntimeException.init(RuntimeException.java:43) at org.apache.commons.lang.exception.NestableRuntimeException .init( NestableRuntimeException.java:86) at org.apache.ojb.broker.OJBRuntimeException.init(Unknown Source) at org.apache.ojb.broker.PBFactoryException.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker (Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker (Unknown Source) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.getBroker( OJBPersistenceService.java:156) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.newSession ( OJBPersistenceService.java:250) at ma.co.omnidata.framework.services.transaction.impl.TransactionManagerImpl.getTransaction (TransactionManagerImpl.java:39) at ma.co.omnidata.framework.services.businessInterface.OMNIFacade.invokeService (OMNIFacade.java:55) at ma.co.omnidata.framework.services.ihm.struts.core.OMNIBaseAction.invokeBusiness (OMNIBaseAction.java:120) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.doExecute (HabLogonAction.java:47) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.execute (HabLogonAction.java:35) at org.apache.struts.action.RequestProcessor.processActionPerform ( RequestProcessor.java:421) at org.apache.struts.action.RequestProcessor.process( RequestProcessor.java:226) at org.apache.struts.action.ActionServlet.process(ActionServlet.java :1164) at org.apache.struts.action.ActionServlet.doPost( ActionServlet.java :415) at javax.servlet.http.HttpServlet.service(HttpServlet.java :763) at javax.servlet.http.HttpServlet.service(HttpServlet.java :851) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(
RE: Borrow broker from pool failed. in production server
Marwane, Growing the pool is not a good thing always. Say you have 300 Oracle licenses, depending on the license, that may include connection pooled objects under the same user account. So there is a section in your code that may not have a finally block so the connection does not get closed. If your DBA does not have orphan settings enabled. When you hit your maxActive count and need another connection, there wont be one available and thus, you will grow you connection pool maxActive limit. What will happen is you hit your database max connection limit and will see some nasty error like ORCL: 9000 No More Available Connections don't quote on that I cant reproduce a more meanifull error at this point and time. So even if you are going to grow make sure you have evictionThreads running. DBCP has an initialSize argument which I believe the OJB Community is planning to support. Once this is available, using a Database Profiler, you should be able to start your application up and via the profiler see new connections per your initialSize. As you need additional resources, say maxActive is 30, you will see the connection increase to handle the load. You should then be able to see eviction thread run to clean up unused/idle connections. I performed a similar test, and found over 45 object calls that did not have a finally block to close connections and release them back to the pool. Last point, the more connections you have the more memory footprint for your application will be. Someone else chim in but I believe each connection takes up to 2MB of memory or that is just what I can see from the Database Profiler. -Eric -Original Message- From: Marwane [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 3:56 AM To: OJB Users List Subject: Re: Borrow broker from pool failed. in production server hi; The problem is resolved using : connection-pool maxActive=1000 whenExhaustedAction=2/ so it s strange the message gived by ojb tel us about the broker pool problem but the solution was the growing the connection pool ! thx for all. On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Marwane wrote: thx. if i don't defin the connection-pool clause in the repository.xml what is the default behavor about the connection managment in ojb ? I think by default 30 connections (docs says 21) managed by the pool (if you specify one of the pooling ConnectionFactory implementations in OJB.properties file). The other properties please see docs http://db.apache.org/ojb/docu/guides/repository.html#Attributes-N10284 http://db.apache.org/ojb/docu/guides/connection.html regards, Armin On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Hi, Marwane wrote: thx for your reply. so we use only the maxActive declared in OJB.properties. in the repository.xml we dont use the connection-pool elements. Keep in mind that OJB use two different pools by default. An PB-pool (settings in OJB.properties file) and a connection-pool (setting within the connection-pool element in repository file). we use maxActif in 1000 the problem persist. It seems that the error is caused by the broker-pool and not by the connection-pool. Normally the connection is associated with the PB when PB-tx starts or a query is performed - thus always after the PB is requested from the PB-pool. If the suggestions from Eric and Dennis doesn't solve your problem I suppose you have a PB leak in your code. regards, Armin regards. On 10/26/06, Dennis Bekkering [EMAIL PROTECTED] wrote: when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis 2006/10/26, Marwane [EMAIL PROTECTED]: hi we have a web application on production used about 500 users. we use default value of ojb parameters (maxActif: 100 ). we are getting frequently the message indicating that we can't borrow connection from pool. even if we use maxActif in 1000 the problem persist. we need your help and give us some leads. stack trace : org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=* at java.lang.Throwable.init(Throwable.java:195) at java.lang.Exception.init(Exception.java:41) at java.lang.RuntimeException.init(RuntimeException.java:43) at org.apache.commons.lang.exception.NestableRuntimeException .init( NestableRuntimeException.java:86) at org.apache.ojb.broker.OJBRuntimeException.init(Unknown Source
Re: Borrow broker from pool failed. in production server
thx for your helpful and constructif reply . i will profile the connections, but it will be gretful if you can give me more detail about using DBCP and evictionThreads with example configuration (ojb.prperties, repository.xml) and how to profile the connections with wich tools ? thx On 11/8/06, Ferrer, Eric [EMAIL PROTECTED] wrote: Marwane, Growing the pool is not a good thing always. Say you have 300 Oracle licenses, depending on the license, that may include connection pooled objects under the same user account. So there is a section in your code that may not have a finally block so the connection does not get closed. If your DBA does not have orphan settings enabled. When you hit your maxActive count and need another connection, there wont be one available and thus, you will grow you connection pool maxActive limit. What will happen is you hit your database max connection limit and will see some nasty error like ORCL: 9000 No More Available Connections don't quote on that I cant reproduce a more meanifull error at this point and time. So even if you are going to grow make sure you have evictionThreads running. DBCP has an initialSize argument which I believe the OJB Community is planning to support. Once this is available, using a Database Profiler, you should be able to start your application up and via the profiler see new connections per your initialSize. As you need additional resources, say maxActive is 30, you will see the connection increase to handle the load. You should then be able to see eviction thread run to clean up unused/idle connections. I performed a similar test, and found over 45 object calls that did not have a finally block to close connections and release them back to the pool. Last point, the more connections you have the more memory footprint for your application will be. Someone else chim in but I believe each connection takes up to 2MB of memory or that is just what I can see from the Database Profiler. -Eric -Original Message- From: Marwane [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 3:56 AM To: OJB Users List Subject: Re: Borrow broker from pool failed. in production server hi; The problem is resolved using : connection-pool maxActive=1000 whenExhaustedAction=2/ so it s strange the message gived by ojb tel us about the broker pool problem but the solution was the growing the connection pool ! thx for all. On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Marwane wrote: thx. if i don't defin the connection-pool clause in the repository.xml what is the default behavor about the connection managment in ojb ? I think by default 30 connections (docs says 21) managed by the pool (if you specify one of the pooling ConnectionFactory implementations in OJB.properties file). The other properties please see docs http://db.apache.org/ojb/docu/guides/repository.html#Attributes-N10284 http://db.apache.org/ojb/docu/guides/connection.html regards, Armin On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Hi, Marwane wrote: thx for your reply. so we use only the maxActive declared in OJB.properties. in the repository.xml we dont use the connection-pool elements. Keep in mind that OJB use two different pools by default. An PB-pool (settings in OJB.properties file) and a connection-pool (setting within the connection-pool element in repository file). we use maxActif in 1000 the problem persist. It seems that the error is caused by the broker-pool and not by the connection-pool. Normally the connection is associated with the PB when PB-tx starts or a query is performed - thus always after the PB is requested from the PB-pool. If the suggestions from Eric and Dennis doesn't solve your problem I suppose you have a PB leak in your code. regards, Armin regards. On 10/26/06, Dennis Bekkering [EMAIL PROTECTED] wrote: when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis 2006/10/26, Marwane [EMAIL PROTECTED]: hi we have a web application on production used about 500 users. we use default value of ojb parameters (maxActif: 100 ). we are getting frequently the message indicating that we can't borrow connection from pool. even if we use maxActif in 1000 the problem persist. we need your help and give us some leads. stack trace : org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=* at java.lang.Throwable.init(Throwable.java:195
RE: Borrow broker from pool failed. in production server
Well with SQL Server 2005 I use the profiler that comes with the studio, don't know about your database/database tools. You want to have your maxActive settings the same in repository_database.xml and ojb.properties. Then you want to enable eviction threads in your ojb.properties file. Just read the instructions and make the appropriate changes. -Original Message- From: Marwane [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 10:28 AM To: OJB Users List Subject: Re: Borrow broker from pool failed. in production server thx for your helpful and constructif reply . i will profile the connections, but it will be gretful if you can give me more detail about using DBCP and evictionThreads with example configuration (ojb.prperties, repository.xml) and how to profile the connections with wich tools ? thx On 11/8/06, Ferrer, Eric [EMAIL PROTECTED] wrote: Marwane, Growing the pool is not a good thing always. Say you have 300 Oracle licenses, depending on the license, that may include connection pooled objects under the same user account. So there is a section in your code that may not have a finally block so the connection does not get closed. If your DBA does not have orphan settings enabled. When you hit your maxActive count and need another connection, there wont be one available and thus, you will grow you connection pool maxActive limit. What will happen is you hit your database max connection limit and will see some nasty error like ORCL: 9000 No More Available Connections don't quote on that I cant reproduce a more meanifull error at this point and time. So even if you are going to grow make sure you have evictionThreads running. DBCP has an initialSize argument which I believe the OJB Community is planning to support. Once this is available, using a Database Profiler, you should be able to start your application up and via the profiler see new connections per your initialSize. As you need additional resources, say maxActive is 30, you will see the connection increase to handle the load. You should then be able to see eviction thread run to clean up unused/idle connections. I performed a similar test, and found over 45 object calls that did not have a finally block to close connections and release them back to the pool. Last point, the more connections you have the more memory footprint for your application will be. Someone else chim in but I believe each connection takes up to 2MB of memory or that is just what I can see from the Database Profiler. -Eric -Original Message- From: Marwane [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 3:56 AM To: OJB Users List Subject: Re: Borrow broker from pool failed. in production server hi; The problem is resolved using : connection-pool maxActive=1000 whenExhaustedAction=2/ so it s strange the message gived by ojb tel us about the broker pool problem but the solution was the growing the connection pool ! thx for all. On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Marwane wrote: thx. if i don't defin the connection-pool clause in the repository.xml what is the default behavor about the connection managment in ojb ? I think by default 30 connections (docs says 21) managed by the pool (if you specify one of the pooling ConnectionFactory implementations in OJB.properties file). The other properties please see docs http://db.apache.org/ojb/docu/guides/repository.html#Attributes-N10284 http://db.apache.org/ojb/docu/guides/connection.html regards, Armin On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Hi, Marwane wrote: thx for your reply. so we use only the maxActive declared in OJB.properties. in the repository.xml we dont use the connection-pool elements. Keep in mind that OJB use two different pools by default. An PB-pool (settings in OJB.properties file) and a connection-pool (setting within the connection-pool element in repository file). we use maxActif in 1000 the problem persist. It seems that the error is caused by the broker-pool and not by the connection-pool. Normally the connection is associated with the PB when PB-tx starts or a query is performed - thus always after the PB is requested from the PB-pool. If the suggestions from Eric and Dennis doesn't solve your problem I suppose you have a PB leak in your code. regards, Armin regards. On 10/26/06, Dennis Bekkering [EMAIL PROTECTED] wrote: when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis
Re: Borrow broker from pool failed. in production server
If you are leaking brokers, that doesn't solve the problem - it just works around it. We had the same problem with our Spring/JTA/OJB application and I discovered the problem was due to using Spring DAOs directly instead of going through the Spring transaction layer. On 11/8/06, Marwane [EMAIL PROTECTED] wrote: hi; The problem is resolved using : connection-pool maxActive=1000 whenExhaustedAction=2/ so it s strange the message gived by ojb tel us about the broker pool problem but the solution was the growing the connection pool ! thx for all. On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Marwane wrote: thx. if i don't defin the connection-pool clause in the repository.xml what is the default behavor about the connection managment in ojb ? I think by default 30 connections (docs says 21) managed by the pool (if you specify one of the pooling ConnectionFactory implementations in OJB.properties file). The other properties please see docs http://db.apache.org/ojb/docu/guides/repository.html#Attributes-N10284 http://db.apache.org/ojb/docu/guides/connection.html regards, Armin On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Hi, Marwane wrote: thx for your reply. so we use only the maxActive declared in OJB.properties. in the repository.xml we dont use the connection-pool elements. Keep in mind that OJB use two different pools by default. An PB-pool (settings in OJB.properties file) and a connection-pool (setting within the connection-pool element in repository file). we use maxActif in 1000 the problem persist. It seems that the error is caused by the broker-pool and not by the connection-pool. Normally the connection is associated with the PB when PB-tx starts or a query is performed - thus always after the PB is requested from the PB-pool. If the suggestions from Eric and Dennis doesn't solve your problem I suppose you have a PB leak in your code. regards, Armin regards. On 10/26/06, Dennis Bekkering [EMAIL PROTECTED] wrote: when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis 2006/10/26, Marwane [EMAIL PROTECTED]: hi we have a web application on production used about 500 users. we use default value of ojb parameters (maxActif: 100 ). we are getting frequently the message indicating that we can't borrow connection from pool. even if we use maxActif in 1000 the problem persist. we need your help and give us some leads. stack trace : org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=* at java.lang.Throwable.init(Throwable.java:195) at java.lang.Exception.init(Exception.java:41) at java.lang.RuntimeException.init(RuntimeException.java:43) at org.apache.commons.lang.exception.NestableRuntimeException .init( NestableRuntimeException.java:86) at org.apache.ojb.broker.OJBRuntimeException.init(Unknown Source) at org.apache.ojb.broker.PBFactoryException.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker (Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker (Unknown Source) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.getBroker( OJBPersistenceService.java:156) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.newSession ( OJBPersistenceService.java:250) at ma.co.omnidata.framework.services.transaction.impl.TransactionManagerImpl.getTransaction (TransactionManagerImpl.java:39) at ma.co.omnidata.framework.services.businessInterface.OMNIFacade.invokeService (OMNIFacade.java:55) at ma.co.omnidata.framework.services.ihm.struts.core.OMNIBaseAction.invokeBusiness (OMNIBaseAction.java:120) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.doExecute (HabLogonAction.java:47) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.execute (HabLogonAction.java:35) at org.apache.struts.action.RequestProcessor.processActionPerform ( RequestProcessor.java:421)
Re: Borrow broker from pool failed. in production server
thx for your reply. so we use only the maxActive declared in OJB.properties. in the repository.xml we dont use the connection-pool elements. regards. On 10/26/06, Dennis Bekkering [EMAIL PROTECTED] wrote: when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis 2006/10/26, Marwane [EMAIL PROTECTED]: hi we have a web application on production used about 500 users. we use default value of ojb parameters (maxActif: 100 ). we are getting frequently the message indicating that we can't borrow connection from pool. even if we use maxActif in 1000 the problem persist. we need your help and give us some leads. stack trace : org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=* at java.lang.Throwable.init(Throwable.java:195) at java.lang.Exception.init(Exception.java:41) at java.lang.RuntimeException.init(RuntimeException.java:43) at org.apache.commons.lang.exception.NestableRuntimeException .init( NestableRuntimeException.java:86) at org.apache.ojb.broker.OJBRuntimeException.init(Unknown Source) at org.apache.ojb.broker.PBFactoryException.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker (Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker (Unknown Source) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.getBroker( OJBPersistenceService.java:156) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.newSession ( OJBPersistenceService.java:250) at ma.co.omnidata.framework.services.transaction.impl.TransactionManagerImpl.getTransaction (TransactionManagerImpl.java:39) at ma.co.omnidata.framework.services.businessInterface.OMNIFacade.invokeService (OMNIFacade.java:55) at ma.co.omnidata.framework.services.ihm.struts.core.OMNIBaseAction.invokeBusiness (OMNIBaseAction.java:120) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.doExecute (HabLogonAction.java:47) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.execute (HabLogonAction.java:35) at org.apache.struts.action.RequestProcessor.processActionPerform( RequestProcessor.java:421) at org.apache.struts.action.RequestProcessor.process( RequestProcessor.java:226) at org.apache.struts.action.ActionServlet.process(ActionServlet.java :1164) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java :415) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:851) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service( ServletWrapper.java:1246) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest( ServletWrapper.java:380) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest ( CacheServletWrapper.java:80) at com.ibm.ws.webcontainer.WebContainer.handleRequest( WebContainer.java :1724) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready( WCChannelLink.java:79) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination( HttpInboundLink.java:422) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation( HttpInboundLink.java:319) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready( HttpInboundLink.java:288) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters (NewConnectionInitialReadCallback.java:207) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete (NewConnectionInitialReadCallback.java:109) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete( WorkQueueManager.java:537) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO( WorkQueueManager.java:593) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun( WorkQueueManager.java:946) at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run( WorkQueueManager.java:1038) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1446) Caused by: java.util.NoSuchElementException at java.lang.Throwable.init(Throwable.java:180) at java.lang.Exception.init(Exception.java:29) at java.lang.RuntimeException.init(RuntimeException.java:32) at java.util.NoSuchElementException.init( NoSuchElementException.java :28) at
Re: Borrow broker from pool failed. in production server
Hi, Marwane wrote: thx for your reply. so we use only the maxActive declared in OJB.properties. in the repository.xml we dont use the connection-pool elements. Keep in mind that OJB use two different pools by default. An PB-pool (settings in OJB.properties file) and a connection-pool (setting within the connection-pool element in repository file). we use maxActif in 1000 the problem persist. It seems that the error is caused by the broker-pool and not by the connection-pool. Normally the connection is associated with the PB when PB-tx starts or a query is performed - thus always after the PB is requested from the PB-pool. If the suggestions from Eric and Dennis doesn't solve your problem I suppose you have a PB leak in your code. regards, Armin regards. On 10/26/06, Dennis Bekkering [EMAIL PROTECTED] wrote: when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis 2006/10/26, Marwane [EMAIL PROTECTED]: hi we have a web application on production used about 500 users. we use default value of ojb parameters (maxActif: 100 ). we are getting frequently the message indicating that we can't borrow connection from pool. even if we use maxActif in 1000 the problem persist. we need your help and give us some leads. stack trace : org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=* at java.lang.Throwable.init(Throwable.java:195) at java.lang.Exception.init(Exception.java:41) at java.lang.RuntimeException.init(RuntimeException.java:43) at org.apache.commons.lang.exception.NestableRuntimeException .init( NestableRuntimeException.java:86) at org.apache.ojb.broker.OJBRuntimeException.init(Unknown Source) at org.apache.ojb.broker.PBFactoryException.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker (Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker (Unknown Source) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.getBroker( OJBPersistenceService.java:156) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.newSession ( OJBPersistenceService.java:250) at ma.co.omnidata.framework.services.transaction.impl.TransactionManagerImpl.getTransaction (TransactionManagerImpl.java:39) at ma.co.omnidata.framework.services.businessInterface.OMNIFacade.invokeService (OMNIFacade.java:55) at ma.co.omnidata.framework.services.ihm.struts.core.OMNIBaseAction.invokeBusiness (OMNIBaseAction.java:120) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.doExecute (HabLogonAction.java:47) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.execute (HabLogonAction.java:35) at org.apache.struts.action.RequestProcessor.processActionPerform( RequestProcessor.java:421) at org.apache.struts.action.RequestProcessor.process( RequestProcessor.java:226) at org.apache.struts.action.ActionServlet.process(ActionServlet.java :1164) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java :415) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:851) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service( ServletWrapper.java:1246) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest( ServletWrapper.java:380) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest ( CacheServletWrapper.java:80) at com.ibm.ws.webcontainer.WebContainer.handleRequest( WebContainer.java :1724) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready( WCChannelLink.java:79) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination( HttpInboundLink.java:422) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation( HttpInboundLink.java:319) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready( HttpInboundLink.java:288) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters (NewConnectionInitialReadCallback.java:207) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete (NewConnectionInitialReadCallback.java:109) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(
Re: Borrow broker from pool failed. in production server
thx. if i don't defin the connection-pool clause in the repository.xml what is the default behavor about the connection managment in ojb ? On 10/27/06, Armin Waibel [EMAIL PROTECTED] wrote: Hi, Marwane wrote: thx for your reply. so we use only the maxActive declared in OJB.properties. in the repository.xml we dont use the connection-pool elements. Keep in mind that OJB use two different pools by default. An PB-pool (settings in OJB.properties file) and a connection-pool (setting within the connection-pool element in repository file). we use maxActif in 1000 the problem persist. It seems that the error is caused by the broker-pool and not by the connection-pool. Normally the connection is associated with the PB when PB-tx starts or a query is performed - thus always after the PB is requested from the PB-pool. If the suggestions from Eric and Dennis doesn't solve your problem I suppose you have a PB leak in your code. regards, Armin regards. On 10/26/06, Dennis Bekkering [EMAIL PROTECTED] wrote: when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis 2006/10/26, Marwane [EMAIL PROTECTED]: hi we have a web application on production used about 500 users. we use default value of ojb parameters (maxActif: 100 ). we are getting frequently the message indicating that we can't borrow connection from pool. even if we use maxActif in 1000 the problem persist. we need your help and give us some leads. stack trace : org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=* at java.lang.Throwable.init(Throwable.java:195) at java.lang.Exception.init(Exception.java:41) at java.lang.RuntimeException.init(RuntimeException.java:43) at org.apache.commons.lang.exception.NestableRuntimeException .init( NestableRuntimeException.java:86) at org.apache.ojb.broker.OJBRuntimeException.init(Unknown Source) at org.apache.ojb.broker.PBFactoryException.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker (Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker (Unknown Source) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.getBroker( OJBPersistenceService.java:156) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.newSession ( OJBPersistenceService.java:250) at ma.co.omnidata.framework.services.transaction.impl.TransactionManagerImpl.getTransaction (TransactionManagerImpl.java:39) at ma.co.omnidata.framework.services.businessInterface.OMNIFacade.invokeService (OMNIFacade.java:55) at ma.co.omnidata.framework.services.ihm.struts.core.OMNIBaseAction.invokeBusiness (OMNIBaseAction.java:120) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.doExecute (HabLogonAction.java:47) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.execute (HabLogonAction.java:35) at org.apache.struts.action.RequestProcessor.processActionPerform ( RequestProcessor.java:421) at org.apache.struts.action.RequestProcessor.process( RequestProcessor.java:226) at org.apache.struts.action.ActionServlet.process(ActionServlet.java :1164) at org.apache.struts.action.ActionServlet.doPost( ActionServlet.java :415) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:851) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service( ServletWrapper.java:1246) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest( ServletWrapper.java:380) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest ( CacheServletWrapper.java:80) at com.ibm.ws.webcontainer.WebContainer.handleRequest( WebContainer.java :1724) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready( WCChannelLink.java:79) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination( HttpInboundLink.java:422) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation( HttpInboundLink.java:319) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready( HttpInboundLink.java:288) at
Re: Borrow broker from pool failed. in production server
when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis 2006/10/26, Marwane [EMAIL PROTECTED]: hi we have a web application on production used about 500 users. we use default value of ojb parameters (maxActif: 100 ). we are getting frequently the message indicating that we can't borrow connection from pool. even if we use maxActif in 1000 the problem persist. we need your help and give us some leads. stack trace : org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=* at java.lang.Throwable.init(Throwable.java:195) at java.lang.Exception.init(Exception.java:41) at java.lang.RuntimeException.init(RuntimeException.java:43) at org.apache.commons.lang.exception.NestableRuntimeException.init( NestableRuntimeException.java:86) at org.apache.ojb.broker.OJBRuntimeException.init(Unknown Source) at org.apache.ojb.broker.PBFactoryException.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker(Unknown Source) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.getBroker( OJBPersistenceService.java:156) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.newSession( OJBPersistenceService.java:250) at ma.co.omnidata.framework.services.transaction.impl.TransactionManagerImpl.getTransaction (TransactionManagerImpl.java:39) at ma.co.omnidata.framework.services.businessInterface.OMNIFacade.invokeService (OMNIFacade.java:55) at ma.co.omnidata.framework.services.ihm.struts.core.OMNIBaseAction.invokeBusiness (OMNIBaseAction.java:120) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.doExecute (HabLogonAction.java:47) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action.HabLogonAction.execute (HabLogonAction.java:35) at org.apache.struts.action.RequestProcessor.processActionPerform( RequestProcessor.java:421) at org.apache.struts.action.RequestProcessor.process( RequestProcessor.java:226) at org.apache.struts.action.ActionServlet.process(ActionServlet.java :1164) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:851) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service( ServletWrapper.java:1246) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest( ServletWrapper.java:380) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest( CacheServletWrapper.java:80) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java :1724) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready( WCChannelLink.java:79) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination( HttpInboundLink.java:422) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation( HttpInboundLink.java:319) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready( HttpInboundLink.java:288) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters (NewConnectionInitialReadCallback.java:207) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete (NewConnectionInitialReadCallback.java:109) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete( WorkQueueManager.java:537) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO( WorkQueueManager.java:593) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun( WorkQueueManager.java:946) at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run( WorkQueueManager.java:1038) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1446) Caused by: java.util.NoSuchElementException at java.lang.Throwable.init(Throwable.java:180) at java.lang.Exception.init(Exception.java:29) at java.lang.RuntimeException.init(RuntimeException.java:32) at java.util.NoSuchElementException.init(NoSuchElementException.java :28) at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject( GenericKeyedObjectPool.java:760) ... 31 more [18/10/06 11:59:53:253 TUC] 0379 SystemErr R org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=*
RE: Borrow broker from pool failed. in production server
One thing to consider. Take a look at the database and find out how many licenses you have. When I was an OJB/DBCP noob I had set the maxActive higher than the number of available connections in the database. - Eric -Original Message- From: Dennis Bekkering [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 3:11 PM To: OJB Users List Subject: Re: Borrow broker from pool failed. in production server when i have a quick look it seems to be about the broker pool and not the connection pool. Check your OJB.properties and set maxActive to the same value as maxActive of the connection pool settings in repository_database.xml. I am not sure about it but your problem happened to me once this way and it was solved by doing as i suggest. regards, Dennis 2006/10/26, Marwane [EMAIL PROTECTED]: hi we have a web application on production used about 500 users. we use default value of ojb parameters (maxActif: 100 ). we are getting frequently the message indicating that we can't borrow connection from pool. even if we use maxActif in 1000 the problem persist. we need your help and give us some leads. stack trace : org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=default, user=db2bmce, password=* at java.lang.Throwable.init(Throwable.java:195) at java.lang.Exception.init(Exception.java:41) at java.lang.RuntimeException.init(RuntimeException.java:43) at org.apache.commons.lang.exception.NestableRuntimeException.init( NestableRuntimeException.java:86) at org.apache.ojb.broker.OJBRuntimeException.init(Unknown Source) at org.apache.ojb.broker.PBFactoryException.init(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPer sistenceBroker(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersi stenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker( Unknown Source) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.getBroke r( OJBPersistenceService.java:156) at ma.co.omnidata.framework.services.dao.ojb.OJBPersistenceService.newSessi on( OJBPersistenceService.java:250) at ma.co.omnidata.framework.services.transaction.impl.TransactionManagerImp l.getTransaction (TransactionManagerImpl.java:39) at ma.co.omnidata.framework.services.businessInterface.OMNIFacade.invokeSer vice (OMNIFacade.java:55) at ma.co.omnidata.framework.services.ihm.struts.core.OMNIBaseAction.invokeB usiness (OMNIBaseAction.java:120) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action .HabLogonAction.doExecute (HabLogonAction.java:47) at com.rmawatanya.convergence.application.technique.habilitation.ihm.action .HabLogonAction.execute (HabLogonAction.java:35) at org.apache.struts.action.RequestProcessor.processActionPerform( RequestProcessor.java:421) at org.apache.struts.action.RequestProcessor.process( RequestProcessor.java:226) at org.apache.struts.action.ActionServlet.process(ActionServlet.java :1164) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:851) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service( ServletWrapper.java:1246) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest( ServletWrapper.java:380) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest( CacheServletWrapper.java:80) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java :1724) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready( WCChannelLink.java:79) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscriminatio n( HttpInboundLink.java:422) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformatio n( HttpInboundLink.java:319) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready( HttpInboundLink.java:288) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscr iminaters (NewConnectionInitialReadCallback.java:207) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete (NewConnectionInitialReadCallback.java:109) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete( WorkQueueManager.java:537) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO( WorkQueueManager.java:593) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun( WorkQueueManager.java:946) at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run( WorkQueueManager.java:1038) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1446) Caused by: java.util.NoSuchElementException at java.lang.Throwable.init(Throwable.java:180
