db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Burlison <Alan.Burli...@sun.com>
Subject Re: Derby causes PermGen leaks in Tomcat
Date Mon, 24 Sep 2007 16:02:05 GMT
> Derby objects are still loaded, and jstack shows several instances of this:
> "derby.antiGC" daemon prio=1 tid=0x088e7000 nid=0xd in Object.wait() 
> [0xc64ce000..0xc64ceb60]
>    java.lang.Thread.State: WAITING (on object monitor)
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0xcaff88f0> (a 
> org.apache.derby.impl.services.monitor.AntiGC)
>         at java.lang.Object.wait(Object.java:485)
>         at org.apache.derby.impl.services.monitor.AntiGC.run(Unknown 
> Source)
>         - locked <0xcaff88f0> (a 
> org.apache.derby.impl.services.monitor.AntiGC)
>         at java.lang.Thread.run(Thread.java:619)
> So it's clear that although the Derby server is stopped, it's still 
> zombified somewhere inside the Tomcat JVM.  How do I cleanly and 
> completely remove Derby from a running JVM?

I found this thread that looked relevant: 

"Shutting down the databases before shutting down the server has solved 
all of my problems."

I've modified my code to do the same, and I've even tried explicitly 
unloading the Derby JDBC driver, but I still get an instance of AntiGC 
hanging around, although all the other Derby threads do terminate.

I'm using the embedded driver to access the database from other threads 
within the JVM that Derby is running in, and running the network server 
to provide external access to the DB.

Alan Burlison

View raw message