db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: How to present a heap dump to the list - Was: Had Derby fail today and need some thoughts
Date Mon, 05 Mar 2012 10:34:32 GMT
On 01.03.2012 22:17, Knut Anders Hatlen wrote:
> "Bergquist, Brett"<BBergquist@canoga.com>  writes:
>> Looking at a heap dump today, it does appear the instances stabilize
>> so the growth is not unbounded but rather a function of the
>> transaction rate as indicated.  That is good!
>> I do think that the proposed more complex solution would be better.
>> Looking at the patch attached to the issue, one might have a separate
>> timer be available from the factory for XA transactions so as to not
>> affect the generic statement timeout capability.  Then the more
>> complex solution could do something like call the "purge" every X
>> cancels or every N seconds for example.  Either/both could be
>> properties that could be configured in derby.properties.
> While we're on the topic of complex solutions... :)
> SingletonTimerFactory is a separate module, and Derby's module
> management system supports loading different implementations of the
> module on different platforms.
> So we could have another version of the module that uses
> ScheduledThreadPoolExecutor instead of java.util.Timer on the platforms
> where that class is available. In Java 7, ScheduledThreadPoolExecutor
> got a new method called setRemoveOnCancelPolicy(), which seems to have
> been added for this exact reason.
> Setting a policy on an executor feels a little bit cleaner than
> periodically purging the timer queue. The downside is that it'll only
> fix the problem on Java 7 and newer. And that we'll have two modules as
> long as we need to support CDC/FP.

+1 to using newer and improved APIs.
I don't know if there are users out there that can't yet upgrade to Java 
7 and who are seeing this issue - in that case we may end up with three 
modules instead of two...

There is talk about tighter synchronization between Java ME and Java SE 
releases. It will be interesting to see how that plays out.


View raw message