On 18.02.10 20:45, Charlie Hubbard wrote:
Actually I see this as well. I had over 690,000 of these laying around, and
I am using Derby 10.5.3. I don't know if I have a test case that I can
share, but within my program when I profile it I see a lot of these. They
look like they are weakly referenced, but the GC doesn't want to give them
up.
Hi Charlie,
To rule out problems in the VM, would it be possible for you to try
running with a different JVM? (preferably from a different vendor)
From time to time we do see problems that occur only in a single VM.
In a different post you said you suspected the debugger to cause some
lock issues. Do you see this issue in a debugger as well, or is this
during normal operation?
Regards,
--
Kristian
Charlie
On Wed, Feb 17, 2010 at 6:34 PM, Knut Anders Hatlen<[email protected]>wrote:
Sumedh Wale<[email protected]> writes:
Hi
I noticed OOM issues in one of the test runs that creates quite a good
number of PreparedStatements. Looking at the hprof dump and the code,
it looks like GenericPreparedStatements are being held on to by
BasicDependencyManager even after having being expired from LCC's
CacheManager. I looked at JIRA but did not find any existing bug for
this -- is it a known issue? One fix can be to explicitly invoke
DependencyManager#clearDependencies() for the GenericPreparedStatement
from CachedStatement#clearIdentity(). This is with 10.4.x and I have
not yet tried with latest 10.5 release.
Hi Sumedh,
I haven't heard about this issue before, so if you still see it with
10.5 it would be great if you could file a bug report with instructions
on how to reproduce it.
Thanks,
--
Knut Anders
