Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Wed, 23 May 2007 10:50:58 -0600
From: Robert Harryman <Robert.Harryman@Sun.COM>
Subject: Re: derby Static refs to log objects
In-reply-to: <46546408.2010909@Sun.COM>
Sender: Robert.Harryman@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <465470F2.9060903@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <46530E4F.8090406@sun.com> <465412F9.5060808@Sun.COM>
 <46544BE6.7070600@sun.com> <46546408.2010909@Sun.COM>
User-Agent: Thunderbird 1.5 (X11/20060113)

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.