Subject | Re: [Firebird-Java] Glassfish 2.1 connection pool does not ask for more than 10 connections, regardless of poolsize |
---|---|
Author | Lutz Müller |
Post date | 2009-05-07T00:26:59Z |
i found out what is causing the problem:
in PooledConnectionQueue, line 477
boolean maximumCapacityReached =
getConfiguration().getMaxPoolSize() <= totalConnections &&
getConfiguration().getMaxPoolSize() != 0 &&
getConfiguration().isPooling();
evaluates to true, because getConfiguration().getMaxPoolSize() returns 10,
regardless of what i configure in glassfishs admin console. any idea what i
could do to solve this?
thanks for reading,
lutz
in PooledConnectionQueue, line 477
boolean maximumCapacityReached =
getConfiguration().getMaxPoolSize() <= totalConnections &&
getConfiguration().getMaxPoolSize() != 0 &&
getConfiguration().isPooling();
evaluates to true, because getConfiguration().getMaxPoolSize() returns 10,
regardless of what i configure in glassfishs admin console. any idea what i
could do to solve this?
thanks for reading,
lutz
On Donnerstag 30 April 2009 15:22:00 Lutz Müller wrote:
> I had this posted in another thread before, where the problem seems to be
> related, but it was apparently not. so here's my problem again:
>
> i ran into the following issue
> with jaybird and glassfish connection pooling just yesterday. atm im trying
> to setup a testscenario.
> the following happened:
> we tried to deploy a webapplication (db access via spring/hibernate) that
> is normally deployed on tomcat to glassfish 2.1. The first thing we noticed
> was the infamous "Could not obtain connection during blocking timeout (5000
> ms)" exception when our application started to use more than 10 connections
> at a time. tomcat running on the same machine with the same jaybird against
> the same database did allocate its connections just fine.
> Firts thing we checked were the poolsettings ofc. Nothing special there.
> When i raised the minimum number of connections in pool above 10, the
> creation of the pool itself would fail, otherwise the error would occur
> when our application requested more than 10 connections from pool.
> Next suspect was xinetd, since we were running classic server.i changed the
> settings in et/xinetd.d/firebird, then replaced classic with superserver.
> but the problem remained.
> at the moment i am trying to setup a testcase on my developer machine and
> plan to debug in to glassfishs and jaybirds sources to see whats going on.
>
> lutz