db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Harryman <Robert.Harry...@Sun.COM>
Subject Re: derby Static refs to log objects
Date Wed, 23 May 2007 14:12:54 GMT
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>, 
<http://localhost:7000/object/0xf0061fb0>, class 
<http://localhost:7000/class/0xf7b41778>, class 
<http://localhost:7000/class/0xf7b405a0>, java.util.HashMap@0xf0062128 
<http://localhost:7000/object/0xf0062128>, java.lang.String@0xf7b3e730 
<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?

View raw message