Today I spent some time investigating why repeated deploys of a user's
app ate progressively more and more memory on Tomcat on Sun Java 6. I
managed to get from the user a heap dump of a server that had an app
deployed and undeployed plus an explicit GC. The JRuby instance sticks
around.
It appears that almost all the rootset graphs (tracing references back
to the "root set" of live objects" involve a timer thread spun up by
MySQL for cancelling statements (the "statement cancellation timer").
When MySQL is loaded, it starts up a thread, referenced from a static
field. That thread has a reference to its classloader, which in the case
of AR-JDBC is the JRubyClassLoader (but would be a webapp classloader
anyway). Ignoring for the moment this seems like a really bad idea (and
EE dictates that you're on your own if you dare to spin up threads
inside the container), it's likely this is the cause of
tomcat+jruby+mysql memory problems over successive deploys.
This bug has been reported here, but not fixed:
http://bugs.mysql.com/bug.php?id=36565
There is a workaround on the bug that involves using reflection to dig
out the timer thread and cancel it. That's obviously not great, and we
should lean on someone to fix this properly. In the interim, we may want
to consider modifying Warbler to do this workaround for you.
Thoughts?
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
