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 16:50:58 GMT
John Embretsen wrote:
> Robert Harryman wrote:
>
>>> 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>, 
>> com.sun.cacao.impl.ModuleClassLoader@0xf0049378 
>> <http://localhost:7000/object/0xf0049378>, 
>> java.security.ProtectionDomain@0xf0061fb0 
>> <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>, 
>> 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?
>
> I'm on very thin ice here, but yeah, I guess this could be related to 
> shared classloaders. Anyway, I was just curious to see if those 
> queries showed references to the logging API, which I would not have 
> been able to explain. Your OQL results look similar to the results I 
> get from running a short Derby test, which was somewhat comforting. 
> There may be some OQL query or some other jhat feature that may be 
> helpful, but unfortunately I don't have any specific suggestions at 
> the moment. Others are welcome to chime in!
>
> You mentioned that you would eventually run out of PermSpace memory if 
> you do not do anything about this. Did you actually test that, so that 
> you know it for a fact?
I did not push it to the limit but used jConsole's memory tab to watch a 
series of deploy/undeploys;  Permgen just  kept
ratcheting up. That plus the inspection of objects remaining  seemed 
good reason to try and find out why.

>
> There was an issue [1] recently with OutOfMemoryErrors after repeated 
> calls to boot and shutdown a database, it may or may not be related. 
> It has been fixed in the trunk (and will be included in the next 
> feature release). If you do run out of memory, and nothing else helps, 
> you may want to try out some jars from a trunk build (see [2] for easy 
> access).
It sure seems related. Is there a trail of that on this archive?  Sorry, 
this is my first exposure to derby so I'm groping a bit.
Thanks again.

Mime
View raw message