On Mon, Nov 9, 2009 at 7:25 PM, Vivek Pandey <[email protected]> wrote:
> I am investigating memory leak related to hot deployment of Rails
> application on GlassFish. One of the hanging references is the JDBC driver,
> in this case: org.sqlite.JDBC. The class loader is
> org.jruby.util.JRubyClassLoader.
Have you been able to identify what field keeps the driver alive? Are
you saying that even though the driver is constructed directly and
loaded into the JRuby class loader, it still gets registered in the
DriverManager?
> I tried to fix it by trying to do something like this:
> for (Enumeration e = DriverManager.getDrivers();
> e.hasMoreElements();) {
> Driver driver = (Driver) e.nextElement();
> if (driver.getClass().getClassLoader() ==
> getClass().getClassLoader()) {
> DriverManager.deregisterDriver(driver);
> }
> }
> This does not work because DriverManager.getDrivers() returns only the
> drivers loaded by this classloader so org.sqlite3.JDBC is not even reported
> although in the debugger I can see it very well and its loaded by
> JRubyClassLoader.
> So the right fix will be in Ruby.tearDown() to do what I am trying to do
> using JRubyClassLoader loaded class.
> I have opened a JIRA: http://jira.codehaus.org/browse/JRUBY-4226
So, I'm wondering where the best place to put this fix is. It seems
like it should be a hook that gets registered in AR-JDBC, even if the
hook is triggered by org.jruby.Ruby.tearDown() or similar. Hard-coding
JDBC-related tear down code into JRuby itself doesn't seem like the
right place.
/Nick
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
