Hi,
I’m summarising here some discussion we’ve had in another thread about
leaks of RubyThread objects that showed up using the JRuby-Rack JMS
support, since it seems like the issue is in core JRuby, rather than
in JRuby-Rack.
What we’re doing is handling received messages from ActiveMQ in Ruby,
as part of a Rails app running inside Glassfish. This means that we
have threads started by the ActiveMQ client executing inside JRuby, so
they get adopted, then die off some time later having handled a number
of requests.
It looks like a RubyThread is leaked at the death of an adopted
thread, since the cleanup in RubyRunnable isn’t called, and despite
the use of a WeakHashMap in ThreadService can’t be GC’d:
this.rubyThreadMap = Collections.synchronizedMap(new
WeakHashMap<Object, RubyThread>());
this.threadContextMap = Collections.synchronizedMap(new
WeakHashMap<RubyThread,ThreadContext>());
When the adopted thread dies, its entry in rubyThreadMap is removed,
but the corresponding entry in threadContextMap is not. This seems to
be because there’s a strong reference from ThreadContext back to
RubyThread - the WeakHashMap is only weak towards its keys, and so the
entry is leaked.
Things that help appear to be either to forcibly reap these leaked
entries based on the fact the RubyThreads are no longer alive, or to
make the thread field of ThreadContext a WeakReference to RubyThread.
Do either of these sound like reasonable fixes? I’m running my app
successfully with the WeakReference change at the moment.
Thanks,
Chris.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email