db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: GenericPreparedStatements leak due to DependencyManager?
Date Mon, 22 Feb 2010 07:33:08 GMT
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?


> Charlie
> On Wed, Feb 17, 2010 at 6:34 PM, Knut Anders Hatlen<Knut.Hatlen@sun.com>wrote:
>> Sumedh Wale<sumwale@fastmail.fm>  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

View raw message