JRuby 1.4.0 - RubyThread leak on adopted thread death

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

On Tue, Nov 17, 2009 at 12:28 PM, Chris A. [email protected]
wrote:

When the adopted thread dies, its entry in rubyThreadMap is removed,
successfully with the WeakReference change at the moment.
Chris, yes, this sounds like a fix we should make. Would you mind
filing a bug (and patch too if you like) at
http://jira.codehaus.org/browse/JRUBY?

Thanks,
/Nick


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email