References: <listhandler=29&site=www.java.net&nid=722732&pid=0&cid=&uid=566421&tid=&6e7ec0881c28739da08c931fee22e7d7_at_www.java.net>
From: makiey <makiey_at_szajka.org>
Content-Type: text/plain;
charset=us-ascii
X-Mailer: iPhone Mail (8B117)
In-Reply-To: <listhandler=29&site=www.java.net&nid=722732&pid=0&cid=&uid=566421&tid=&6e7ec0881c28739da08c931fee22e7d7_at_www.java.net>
Message-Id: <9D59C216-A4BE-48EB-9C73-5FAFCC3F4F28_at_szajka.org>
Date: Fri, 26 Nov 2010 09:06:21 +0100
To: "users_at_glassfish.dev.java.net" <users_at_glassfish.dev.java.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (iPhone Mail 8B117)
Hi,
are you sure you need pinned connections? try with "associated with thread =3D=
disabled"
regards,
makiey
On 23.11.2010, at 21:44, forums_at_java.net wrote:
> I'm using GlassFish v3.0.1 in our production environment. We have several=
> applications deployed, each using their own datasource. We are encounterin=
g
> an issue where we seem to run out of database connections. We constantly s=
eem
> to hit the following error:
>=20
> /*java.sql.SQLException: Error in allocating a connection. Cause: In-use
> connections equal max-pool-size and expired max-wait-time. Cannot allocate=
> more connections.*/
>=20
> To try and identify the issue I enabled leak detection by setting the Leak=
> Timeout to 180 seconds and enabled Leak Reclaim. This resulted in stack
> traces being written out to the log file stating:
>=20
> /*A potential connection leak detected for connection pool */
>=20
> While this would tell me about the leaked connection it did not help ident=
ify
> the offender because the leaks appear in different datasources / applicati=
ons
> each time. Each application uses a its own datasource and in some cases a
> different persistence technology: (one uses JPA with EclipseLink, others u=
se
> Hibernate with Spring) This leads me to believe that there may be an issue=
> with GlassFish and the way it is managing the connections.
>=20
> =20
>=20
> I have configured each connection pool with the following characteristics:=
>=20
> Wrap JDBC Objects: enabled
>=20
> Pooling: enabled
>=20
> Leak Timeout: 180
>=20
> Leak Reclaim: enabled
>=20
> Creation Retry Attempts: 6
>=20
> Retry Interval: 10
>=20
> Associate With Thread: enabled
>=20
> Max Connection Usage: 1
>=20
> Connection Validation: enabled
>=20
> Validation Method: auto-commit
>=20
> Transaction Isolation: read-committed
>=20
> Isolation Level: guaranteed
>=20
> =20
>=20
> Each time a stack trace is printed pertaining to a leaked connection, the o=
ne
> thing that seems constant is the method from which the exception was throw=
n
> in the stack trace:
>=20
> =20
>=20
> /The stack trace of the thread is provided below :/
> /com.sun.enterprise.resource.pool.ConnectionPool.setResourceStateToBusy(Co=
nnectionPool.java:319)/
> /com.sun.enterprise.resource.pool.ConnectionPool.getResourceFromPool(Conne=
ctionPool.java:694)/
> /com.sun.enterprise.resource.pool.ConnectionPool.getUnenlistedResource(Con=
nectionPool.java:572)/
> /com.sun.enterprise.resource.pool.AssocWithThreadResourcePool.getUnenliste=
dResource(AssocWithThreadResourcePool.java:164)/
> /com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(Conne=
ctionPool.java:467)/
> /com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPoo=
l.java:369)/
> /com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(Pool=
ManagerImpl.java:226)/
> /com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerI=
mpl.java:150)/
> /com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(Connectio=
nManagerImpl.java:327)/
> /com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection=
(ConnectionManagerImpl.java:290)/
> /com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(Co=
nnectionManagerImpl.java:227)/
> /com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(Co=
nnectionManagerImpl.java:159)/
> /com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(Co=
nnectionManagerImpl.java:154)/
> /com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:105)/ I=
t
> appears that there may be a deadlock situation occurring
> in /ConnectionPool.setResourceStateToBusy./ Currently the only ay to
> resolve this issue is to bounce the glassfish instance as I eventually run=
> out of connection, but this is not a viable work-around in a production
> environment. Are there any configuration changes that I can make that will=
> prevent this from occurring? Is this a know issue that will be addressed i=
n a
> patch or an up-coming release?
> =20
>=20
>=20
> --
>=20
> [Message sent by forum member 'fericit_bostan']
>=20
> View Post: http://forums.java.net/node/722732
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>=20