db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: How to present a heap dump to the list - Was: Had Derby 10.8.2.2 fail today and need some thoughts
Date Thu, 01 Mar 2012 21:17:55 GMT
"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.

-- 
Knut Anders

Mime
View raw message