You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2008/04/26 08:25:03 UTC
[dbcp] Re: WAITING on lock=org.apache.commons.pool.impl.GenericObjectPool
On Fri, Apr 25, 2008 at 7:27 PM, Philip Arad <ph...@datatex.it> wrote:
> Hi
>
> I am using commons-pool-1.3.jar with commons-dbcp-1.2.2.jar.
Stack trace looks like pool 1.4, which is the latest release.
> My program is using concurrent threads that each of them access the DB
> through
> BasicDataSource. If I use 5 concurrent threads, the program is running
> without
> any problem. The problem starts when I am using 10 threads:
> Each thread is using the class ConnectionHelper to get a connection to the
> DB:
>
<snip/>
> ------------------------------------------------------------------------------------
> "Thread-4" Id=14 in WAITING on
> lock=org.apache.commons.pool.impl.GenericObjectPool@18a80d4
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:485)
> at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:942)
> at
> org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96)
> at
> dataAccess.util.ConnectionHelper.getConnection(ConnectionHelper.java:37)
> - locked java.lang.Class@99d56b
> at
> dataAccess.util.DataAccessLocalImpl.getConnection(DataAccessLocalImpl.java:25)
> at dataAccess.db.BaseDataAccess.getFullColumns(BaseDataAccess.java:1284)
> at dataAccess.db.BaseDataAccess.getFullColumns(BaseDataAccess.java:1272)
> at
> dataAccess.util.CreateStatement.createStatement(CreateStatement.java:63)
> at dataAccess.util.CreateStatement.process(CreateStatement.java:48)
> at
> dataAccess.db.thread.query.QueryRunnerThread.run(QueryRunnerThread.java:19)
>
> ------------------------------------------------------------------------------------
>
> Can you tell me what should I do to solve this problem?
The thread above is waiting for a connection to become available. The
default maxActive setting of BasicDataSource is 8, so if you want to
have more than 8 connections concurrently in use, you need to increase
this. See the BasicDataSource javadoc. See also the maxWait
property if you would prefer getConnection to time out and throw an
exception when there are no idle connections available.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [dbcp] Re: WAITING on lock=org.apache.commons.pool.impl.GenericObjectPool
Posted by Philip Arad <ph...@datatex.it>.
Hi
Thanks for your advices.
Working perfectly even with 50 threads.
Philip
Phil Steitz wrote:
> On Sat, Apr 26, 2008 at 2:57 AM, Philip Arad <ph...@datatex.it> wrote:
>
>> Hi
>>
>> Thanks for your help.
>> You are right, I am using commons-pool-1.4.jar.
>> First I have setup the numbers of concurrent threads to 8, an ran the
>> program
>> several times. It is executing correctly.
>>
>> Then I have setup the following attributes on BasicDataSource:
>> vBDS.setMaxActive(400);
>> vBDS.setMinIdle(0);
>> vBDS.setMaxWait(3000L);
>> And set up the numbers of concurrent threads to 10.
>> After running it again, I had to same problem.
>> It seems like the setting of the attributes did not effect the
>> configuration
>> of the BasicDataSource.
>> Are there any parameters to setup on the PoolingDataSource?
>> Is it possible that the connections are not returned to the pool after
>> being
>> closed?
>>
>
> Sorry, I had not looked carefully at the code in your initial post.
> Unless you want two layers of pooling for some reason, there is no
> need to wrap the BasicDataSource in a PoolingDataSource as you are
> doing here:
>
> // Create a PoolableDataSource
> ObjectPool vConnectionPool = new GenericObjectPool(null);
> ConnectionFactory vConnectionFactory = new DataSourceConnectionFactory(vBDS);
>
> Normally, you should be able to just return the BasicDataSource, vBDS,
> which already has a connection pool associated with it.
> Alternatively, you could create your own PoolingDataSource using a
> Driver- or DriverManagerConnectionFactory. See the examples linked on
> the DBCP web page (ManualPoolingDataSourceExample,
> BasicDataSourceExample).
>
> The maxActive and maxWait properties are poperties of the underlying
> object pool. BasicDataSource exposes these properties via getters and
> setters and creates a PoolingDataSource to source connections from the
> pool. When you create a PoolingDataSource manually, you need to set
> the properties on the object pool directly.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [dbcp] Re: WAITING on lock=org.apache.commons.pool.impl.GenericObjectPool
Posted by Phil Steitz <ph...@gmail.com>.
On Sat, Apr 26, 2008 at 2:57 AM, Philip Arad <ph...@datatex.it> wrote:
> Hi
>
> Thanks for your help.
> You are right, I am using commons-pool-1.4.jar.
> First I have setup the numbers of concurrent threads to 8, an ran the
> program
> several times. It is executing correctly.
>
> Then I have setup the following attributes on BasicDataSource:
> vBDS.setMaxActive(400);
> vBDS.setMinIdle(0);
> vBDS.setMaxWait(3000L);
> And set up the numbers of concurrent threads to 10.
> After running it again, I had to same problem.
> It seems like the setting of the attributes did not effect the
> configuration
> of the BasicDataSource.
> Are there any parameters to setup on the PoolingDataSource?
> Is it possible that the connections are not returned to the pool after
> being
> closed?
Sorry, I had not looked carefully at the code in your initial post.
Unless you want two layers of pooling for some reason, there is no
need to wrap the BasicDataSource in a PoolingDataSource as you are
doing here:
// Create a PoolableDataSource
ObjectPool vConnectionPool = new GenericObjectPool(null);
ConnectionFactory vConnectionFactory = new DataSourceConnectionFactory(vBDS);
Normally, you should be able to just return the BasicDataSource, vBDS,
which already has a connection pool associated with it.
Alternatively, you could create your own PoolingDataSource using a
Driver- or DriverManagerConnectionFactory. See the examples linked on
the DBCP web page (ManualPoolingDataSourceExample,
BasicDataSourceExample).
The maxActive and maxWait properties are poperties of the underlying
object pool. BasicDataSource exposes these properties via getters and
setters and creates a PoolingDataSource to source connections from the
pool. When you create a PoolingDataSource manually, you need to set
the properties on the object pool directly.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [dbcp] Re: WAITING on lock=org.apache.commons.pool.impl.GenericObjectPool
Posted by Hanson Char <ha...@gmail.com>.
>Is it possible that the connections are not returned to the pool after
being closed?
Or is it possible that the connections are never been closed from you
application ?
Hanson
On Sat, Apr 26, 2008 at 2:57 AM, Philip Arad <ph...@datatex.it> wrote:
> Hi
>
> Thanks for your help.
> You are right, I am using commons-pool-1.4.jar.
> First I have setup the numbers of concurrent threads to 8, an ran the
> program
> several times. It is executing correctly.
>
> Then I have setup the following attributes on BasicDataSource:
> vBDS.setMaxActive(400);
> vBDS.setMinIdle(0);
> vBDS.setMaxWait(3000L);
> And set up the numbers of concurrent threads to 10.
> After running it again, I had to same problem.
> It seems like the setting of the attributes did not effect the
> configuration
> of the BasicDataSource.
> Are there any parameters to setup on the PoolingDataSource?
> Is it possible that the connections are not returned to the pool after
> being
> closed?
>
> Regards
> Philip
>
>
>
> Philip
>
>
> Phil Steitz wrote:
>
> > On Fri, Apr 25, 2008 at 7:27 PM, Philip Arad <ph...@datatex.it>
> > wrote:
> >
> >
> > > Hi
> > >
> > > I am using commons-pool-1.3.jar with commons-dbcp-1.2.2.jar.
> > >
> > >
> >
> > Stack trace looks like pool 1.4, which is the latest release.
> >
> >
> >
> > > My program is using concurrent threads that each of them access the
> > > DB
> > > through
> > > BasicDataSource. If I use 5 concurrent threads, the program is
> > > running
> > > without
> > > any problem. The problem starts when I am using 10 threads:
> > > Each thread is using the class ConnectionHelper to get a connection
> > > to the
> > > DB:
> > >
> > >
> > >
> > <snip/>
> >
> >
> >
> > >
> > > ------------------------------------------------------------------------------------
> > > "Thread-4" Id=14 in WAITING on
> > > lock=org.apache.commons.pool.impl.GenericObjectPool@18a80d4
> > > at java.lang.Object.wait(Native Method)
> > > at java.lang.Object.wait(Object.java:485)
> > > at
> > >
> > > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:942)
> > > at
> > >
> > > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96)
> > > at
> > >
> > > dataAccess.util.ConnectionHelper.getConnection(ConnectionHelper.java:37)
> > > - locked java.lang.Class@99d56b
> > > at
> > >
> > > dataAccess.util.DataAccessLocalImpl.getConnection(DataAccessLocalImpl.java:25)
> > > at
> > > dataAccess.db.BaseDataAccess.getFullColumns(BaseDataAccess.java:1284)
> > > at
> > > dataAccess.db.BaseDataAccess.getFullColumns(BaseDataAccess.java:1272)
> > > at
> > >
> > > dataAccess.util.CreateStatement.createStatement(CreateStatement.java:63)
> > > at dataAccess.util.CreateStatement.process(CreateStatement.java:48)
> > > at
> > >
> > > dataAccess.db.thread.query.QueryRunnerThread.run(QueryRunnerThread.java:19)
> > >
> > >
> > > ------------------------------------------------------------------------------------
> > >
> > > Can you tell me what should I do to solve this problem?
> > >
> > >
> >
> > The thread above is waiting for a connection to become available. The
> > default maxActive setting of BasicDataSource is 8, so if you want to
> > have more than 8 connections concurrently in use, you need to increase
> > this. See the BasicDataSource javadoc. See also the maxWait
> > property if you would prefer getConnection to time out and throw an
> > exception when there are no idle connections available.
> >
> > Phil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [dbcp] Re: WAITING on lock=org.apache.commons.pool.impl.GenericObjectPool
Posted by Philip Arad <ph...@datatex.it>.
Hi
Thanks for your help.
You are right, I am using commons-pool-1.4.jar.
First I have setup the numbers of concurrent threads to 8, an ran the
program
several times. It is executing correctly.
Then I have setup the following attributes on BasicDataSource:
vBDS.setMaxActive(400);
vBDS.setMinIdle(0);
vBDS.setMaxWait(3000L);
And set up the numbers of concurrent threads to 10.
After running it again, I had to same problem.
It seems like the setting of the attributes did not effect the configuration
of the BasicDataSource.
Are there any parameters to setup on the PoolingDataSource?
Is it possible that the connections are not returned to the pool after being
closed?
Regards
Philip
Philip
Phil Steitz wrote:
> On Fri, Apr 25, 2008 at 7:27 PM, Philip Arad <ph...@datatex.it> wrote:
>
>> Hi
>>
>> I am using commons-pool-1.3.jar with commons-dbcp-1.2.2.jar.
>>
>
> Stack trace looks like pool 1.4, which is the latest release.
>
>
>> My program is using concurrent threads that each of them access the DB
>> through
>> BasicDataSource. If I use 5 concurrent threads, the program is running
>> without
>> any problem. The problem starts when I am using 10 threads:
>> Each thread is using the class ConnectionHelper to get a connection to the
>> DB:
>>
>>
> <snip/>
>
>
>> ------------------------------------------------------------------------------------
>> "Thread-4" Id=14 in WAITING on
>> lock=org.apache.commons.pool.impl.GenericObjectPool@18a80d4
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:485)
>> at
>> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:942)
>> at
>> org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96)
>> at
>> dataAccess.util.ConnectionHelper.getConnection(ConnectionHelper.java:37)
>> - locked java.lang.Class@99d56b
>> at
>> dataAccess.util.DataAccessLocalImpl.getConnection(DataAccessLocalImpl.java:25)
>> at dataAccess.db.BaseDataAccess.getFullColumns(BaseDataAccess.java:1284)
>> at dataAccess.db.BaseDataAccess.getFullColumns(BaseDataAccess.java:1272)
>> at
>> dataAccess.util.CreateStatement.createStatement(CreateStatement.java:63)
>> at dataAccess.util.CreateStatement.process(CreateStatement.java:48)
>> at
>> dataAccess.db.thread.query.QueryRunnerThread.run(QueryRunnerThread.java:19)
>>
>> ------------------------------------------------------------------------------------
>>
>> Can you tell me what should I do to solve this problem?
>>
>
> The thread above is waiting for a connection to become available. The
> default maxActive setting of BasicDataSource is 8, so if you want to
> have more than 8 connections concurrently in use, you need to increase
> this. See the BasicDataSource javadoc. See also the maxWait
> property if you would prefer getConnection to time out and throw an
> exception when there are no idle connections available.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org