Rainer Jung-3 wrote:
>
> TP-Processor16 owns lock at 0x73a71c40 and thus blocks TP12, TP5 and TP1.
>
> TP16 and TP2 both wait for lock 0x73a71dd0. The thread holding this lock
> is not in your dump.
>
> Since the lock is of type
> org.firebirdsql.gds.impl.wire.isc_db_handle_impl, it seems either yet
> another thread uses that lock (in which case it could be either simple
> lock contention, or if that thread wait e.g. on 0x73a71c40 it would be a
> deadlock), or the thread that originally hold the lock didn't free it
> due to a code bug. Check your thread dump for 0x73a71c40.
>
> Also check the firebird bug database and version of your firebird JDBC
> driver.
>
Dear Rainer,
Thanks for your help. I am sending the complete thread dump just in case. I
looked for the "0x73a71c40" you mentionned and only found the following
thread that mentionned it :
"ContainerBackgroundProcessor[StandardEngine[PSA]]" daemon prio=1
tid=0x6a1262a8 nid=0x6f75 waiting for monitor entry [0x6977d000..0x6977deb0]
at
org.firebirdsql.jdbc.AbstractConnection.commit(AbstractConnection.java:435)
- waiting to lock <0x73a71c40> (a org.firebirdsql.jdbc.FBConnection)
at fr.microtec.db.Connection.commit(Connection.java:201)
at
fr.microtec.artemis.model.web.ArtemisParams.closeConnection(ArtemisParams.java:63)
at
fr.microtec.artemis.model.web.ArtemisUserList.removeUser(ArtemisUserList.java:55)
at
fr.microtec.artemis.controller.servlets.ArtemisSessionListener.sessionDestroyed(ArtemisSessionListener.java:58)
at
org.apache.catalina.session.StandardSession.expire(StandardSession.java:697)
- locked <0x73a8f990> (a org.apache.catalina.session.StandardSession)
at
org.apache.catalina.session.StandardSession.isValid(StandardSession.java:581)
at
org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:546)
at
org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:664)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1285)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1570)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1579)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1579)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1559)
at java.lang.Thread.run(Thread.java:595)
If I'm interpreting this correctly, we can see that the container is waiting
to lock the connection 0x73a71c40 because it's trying to commit() at the
time when the user session times out. But it's getting stuck because TP-16
is already locking that connection. If I look at TP16 I can see that it is
waiting on "0x73a71dd0" which is locked by the FINALIZER.
"Finalizer" daemon prio=1 tid=0x09a61f68 nid=0x6f3e runnable
[0x6cc7d000..0x6cc7df30]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
org.firebirdsql.gds.impl.wire.XdrInputStream.read(XdrInputStream.java:253)
at
org.firebirdsql.gds.impl.wire.XdrInputStream.readInt(XdrInputStream.java:187)
at
org.firebirdsql.gds.impl.wire.AbstractJavaGDSImpl.nextOperation(AbstractJavaGDSImpl.java:2144)
at
org.firebirdsql.gds.impl.wire.AbstractJavaGDSImpl.receiveResponse(AbstractJavaGDSImpl.java:2098)
at
org.firebirdsql.gds.impl.wire.AbstractJavaGDSImpl.iscDsqlFreeStatement(AbstractJavaGDSImpl.java:1435)
- locked <0x73a71dd0> (a
org.firebirdsql.gds.impl.wire.isc_db_handle_impl)
at org.firebirdsql.gds.impl.GDSHelper.closeStatement(GDSHelper.java:316)
at
org.firebirdsql.jdbc.FBStatementFetcher.close(FBStatementFetcher.java:223)
at
org.firebirdsql.jdbc.AbstractResultSet.close(AbstractResultSet.java:291)
at
org.firebirdsql.jdbc.AbstractResultSet.close(AbstractResultSet.java:276)
at fr.microtec.db.Query.closeResultSet(Query.java:81)
at fr.microtec.db.Query.cleanup(Query.java:68)
at fr.microtec.db.Query.finalize(Query.java:424)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
This must explain why my heap eventually runs out, because objects aren't
getting destroyed, is that right ? The next question of course is : what is
making the finalizer keep that lock ?
Thanks for your insight,
Raphael
http://www.nabble.com/file/p24458247/thread%2Bdump.txt thread+dump.txt
--
View this message in context:
http://www.nabble.com/Blocked-threads-in-Tomcat-web-app-tp24457682p24458247.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
