John thank you to the reply. I ran the two examples.
John Embretsen wrote:
Robert Harryman wrote:
Next I added classloading of the embedded derby driver, did a
shutdown of the database and unregistered the
driver. Using jmap/jhat (jdk 1.6) I see that all my objects are being
kept alive and that there are a lot
of derby static refs around to java.util.logging.Logger. This leak
will force me to bounce the container during
redeploy since PermGen will eventually exhaust and cause an out of
memory condition.
Is this a known problem? Does derby/javaDB have a bug against static
references to log objects?
As far as I know, Derby does not use the java.util.logging package at
all, so your findings puzzle me. Then again, maybe I am
misunderstanding what you are asking...
(Derby (and Java DB) versions up to and including 10.2 support J2SE
1.3, which does not include the logging API).
Do you get similar results (references to java.util.logging.Logger) if
you run the following query in jhat's OQL tool?
select referrers(f) from java.util.logging.Logger f
(lists Java objects that hold reference to java.util.logging.Logger)
I did not see any references in this result.
or for example
select
referees(heap.findClass("org.apache.derby.impl.services.monitor.BaseMonitor"))
(returns an array of Java objects to which the given Java object
directly refers to).
[ class java.lang.Class <http://localhost:7000/class/0xf7017d68>, class
java.lang.Object <http://localhost:7000/class/0xf7017a68>,
[EMAIL PROTECTED]
<http://localhost:7000/object/0xf0049378>,
[EMAIL PROTECTED]
<http://localhost:7000/object/0xf0061fb0>, class
org.apache.derby.iapi.services.monitor.PersistentService
<http://localhost:7000/class/0xf7b41778>, class
org.apache.derby.io.StorageFactory
<http://localhost:7000/class/0xf7b405a0>, [EMAIL PROTECTED]
<http://localhost:7000/object/0xf0062128>, [EMAIL PROTECTED]
<http://localhost:7000/object/0xf7b3e730> ]
Is there a way from this result to tell what is keeping the derby
objects alive? I can see jhat provides
many useful methods to hunt with, I just don't have the skill yet to
know what to hunt for. Since this
is a container there appears to be a shared classloader in the in the
ancestry, could it have something to
do with a class being shared?
