JRuby 1.4.0 monitor.rb thread safety

Hi All,

We recently upgraded a rails based webapp to jruby 1.4.0 and are
seeing intermittent exceptions thrown around the activerecord
connection pool. After some narrowing down it appears that a timeout
on the connection pool monitor is happening however it’s happening in
the thread that was just woken up to receive a checked in connection
just as it attempts to call Thread.critical = true (in the wait method
on ConditionVariable in the MonitorMixin). This causes it to bail out
but a level up an ensure block in the mon_synchronize method that
causes the thread to try and release the monitor when it never re-took
it after waking up from waiting.

Exception:
file:/var/lib/tomcat6/webapps/ROOT/WEB-INF/lib/jruby-complete-1.4.0.jar!/META-INF/jruby.home/lib/ruby/1.8/monitor.rb:278:in
mon_check_owner' file:/var/lib/tomcat6/webapps/ROOT/WEB-INF/lib/jruby-complete-1.4.0.jar!/META-INF/jruby.home/lib/ruby/1.8/monitor.rb:224:in mon_exit’
file:/var/lib/tomcat6/webapps/ROOT/WEB-INF/lib/jruby-complete-1.4.0.jar!/META-INF/jruby.home/lib/ruby/1.8/monitor.rb:242:in
mon_synchronize' /var/lib/tomcat6/webapps/ROOT/WEB-INF/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:183:in checkout’
/var/lib/tomcat6/webapps/ROOT/WEB-INF/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:98:in
connection' /var/lib/tomcat6/webapps/ROOT/WEB-INF/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:326:in retrieve_connection’
/var/lib/tomcat6/webapps/ROOT/WEB-INF/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:123:in
retrieve_connection' /var/lib/tomcat6/webapps/ROOT/WEB-INF/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:115:in connection’

If we replace monitor.rb in jruby-complete-1.4.0.jar with the one from
1.3.1 the problem goes away, that appears to be due to 1.3.1
containing a version of monitor.rb that was implemented using a mutex
instead
(remove use of TimeoutError, since it was controversial on ruby-core · jruby/jruby@3750f3a · GitHub,
similar to the one that’s on the ruby trunk but never made it into
1.8). Is it possible to have certain unsafe modules/classes excluded
when a new tag of ruby is supported? Although I understand that it’s
hard to claim compatibility with a certain version of ruby if jruby is
running different code.

Cheers,
Lucas


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Sun, Mar 21, 2010 at 5:11 PM, Lucas [email protected] wrote:

If we replace monitor.rb in jruby-complete-1.4.0.jar with the one from
1.3.1 the problem goes away, that appears to be due to 1.3.1
containing a version of monitor.rb that was implemented using a mutex
instead (remove use of TimeoutError, since it was controversial on ruby-core · jruby/jruby@3750f3a · GitHub,
similar to the one that’s on the ruby trunk but never made it into
1.8). Is it possible to have certain unsafe modules/classes excluded
when a new tag of ruby is supported? Although I understand that it’s
hard to claim compatibility with a certain version of ruby if jruby is
running different code.

That’s really unfortunate. I thought we had fixed monitor.rb at some
point, but then we started getting bugs about it in 1.4. It looks like
it may have gotten wiped out when we updated 1.8 stdlib to 1.8.7:

commit 69c2de549ac00c18f3d3df19489064a238210b0b
Author: Ola B. [email protected]
Date: Mon Aug 3 21:10:48 2009 +0200

[1.8.7] Merge 1.8.7 stdlib

commit 3750f3a4556775bf9520115ed3ec9f2987542390
Author: MenTaLguY [email protected]
Date: Wed Mar 12 21:44:10 2008 +0000

remove use of TimeoutError, since it was controversial on ruby-core

This is part of our challenge when updating stdlib; we have to be
careful about updating and not overwrite files we need to keep the
same. It may be time for us to commit and manage a patchset of some
kind (or I’m open to other options).

I’ll revert the bad change this time.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Thanks for that Charlie, we’ll continue to use a patched 1.4.0 jar
until the next release is made.

  • Lucas

On Mon, Mar 22, 2010 at 7:24 PM, Charles Oliver N.
[email protected] wrote:

commit 3750f3a4556775bf9520115ed3ec9f2987542390
I’ll revert the bad change this time.

  • Charlie

To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email