Hi All,
I'm curious if anyone has had the unfortunate case of being plagued by
database pool errors?
Our environment is Tomcat (5.5) + Postgres (8.4) + XMLUI (1.7.1)
An example of the error we had been getting is:
/dspace/log/dspace.log.2012-07-01:2012-07-01 12:25:59,627 ERROR
org.dspace.app.xmlui.aspect.general.AuthenticatedSelector @ Error selecting
based on authentication status: Cannot get a connection, pool error Timeout
waiting for idle object
>From my understanding is that DSpace will use a database connection pool,
which is configurable to have some 30 open connections between the JVM, and
postgres. When a new request comes in, that requires interaction with the
database, it will re-use an existing already-open database connection,
taking it from the pool, make the query, and then return the connection
back to the pool.
The problem must lie in that somehow more requests come in at a certain
moment, which is more than the number of available connections in the pool,
and the default behavior is to wait/block until a connection becomes
available. There is a timeout for how long it will wait for a connection to
become available, after which time, it errors out with the above error.
Reasons why all the connections in the pool are in use could be that the
system is very busy, and its just using all the connections, or as I
suspect, there is a bug that is prohibiting some connections from being
returned back to the pool. I can't quite put my finger on precisely what
could be wrong.
Anyways, I have made a change to my database pool settings in DSpace, and
I've noticed that since we've made this change, we haven't seem the error
occur again.
dspace-api/src/main/java/org/dspace/storage/rdbms/DataSourceInit.java
https://github.com/osulibraries/DSpaceOSUKB/commit/c627ebdb738efbf46ba7a338180099fa38b96a66.diff
// Create object pool
ObjectPool connectionPool = new GenericObjectPool(null,
// PoolableObjectFactory
- // - set below
- maxConnections, // max connections
- GenericObjectPool.*WHEN_EXHAUSTED_BLOCK*, maxWait, // don't
- // block
- // more than 5
- // seconds
- maxIdle, // max idle connections (unlimited)
- true, // validate when we borrow connections from pool
- false // don't bother validation returned connections
+ maxConnections, // max connections
+ GenericObjectPool.*WHEN_EXHAUSTED_GROW*, // What
to do when pool is exhausted
+ maxWait, // don't
block more than 5 seconds
+ maxIdle, // max
idle connections (unlimited)
+ true, //
validate on connection borrow ?
+ true //
validate on connection return ?
Basically, the biggest change in there is the WHEN_EXHAUSTED action. The
default is to use the strategy of WHEN_EXHAUSTED_BLOCK, and I've changed
that locally to WHEN_EXHAUSTED_GROW, which essentially nullifies any
max-number-of-connections limit that I've set. But, atleast we don't have
the problem where a submitter would randomly become plagued with not being
able to use the system.
As I've said, since we've made this change, we've been two weeks error free
(on this issue). I'm wary to claim victory on one of these sneaky bugs, but
I was wondering if anyone else has run into this issue, and perhaps has
found some action steps to resolve it.
Peter Dietz
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
