On 13.07.2009 11:05, Raphael Neve wrote: > > 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 ?
Yup, and the code run by the finalizer makes a network call (likely to the database), which seems to be a very bad pattern. Finalizers are not a great idea by themselves, but one needs to keep them as simple as possible. Doing network communication in a finalizer doesn't sound right. Looks like you should check the firebird bug database and/or open an issue there. > Thanks for your insight, > Raphael Regards, Rainer > http://www.nabble.com/file/p24458247/thread%2Bdump.txt thread+dump.txt --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
