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>,
[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?
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.
