Alan Burlison wrote:
Derby objects are still loaded, and jstack shows several instances of
this:
"derby.antiGC" daemon prio=1 tid=0x088e7000 nid=0xd in Object.wait()
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:
http://www.nabble.com/RE%3A-AntiGC-Not-Shutting-Down-p1217286.html
"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 haven't seen any details of how you unload the embedded driver, but have you
tried shutting down the Derby system explicitly as well as (or instead of)
shutting down the particular database?
When I run a small test case (outside of Tomcat) I see the AntiGC thread hanging
around after doing:
- load embedded driver (with newInstance())
- start the network server using the NetworkServerControl API
- shutdown database (example URL: "jdbc:derby:leakDB;shutdown=true")
- shutdown server (netServerControl.shutdown())
However, when I do:
- load embedded driver (with newInstance())
- start the network server using the NetworkServerControl API
- shutdown Derby system (example URL: "jdbc:derby:;shutdown=true")
- shutdown server (netServerControl.shutdown())
I don't see the AntiGC thread (using jstack).
PermGen space usage seems to be fairly stable at around 11-12 MB even after
several hundred iterations of either of the scenarios mentioned above, so I'm
not able to reproduce your case outside Tomcat (please post if you are!). I
suspect Tomcat may be a part of the problem here...
--
John
