-
-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process hangs when requiring yaml under compat-version 2.0 on JRuby 1.7.27 #4613
Comments
From doing some git bisecting, it appears that the problem originates with 45047a. |
unfortunately auto-loading was never done "right" on JRuby 1.7.x ... and since its EOL it might just stay as is |
Fix for jruby#4613, an infinite loop in module name parsing logic which had been introduced into RubyModule.const_get_2_0 in 45047a.
I found a possible fix for this, submitted in PR #4614. With this change, the error no longer occurs for me. |
@camlow325 It is great you dug in and figured this out but we just EOLd 1.7.x. Another point is that our --2.0 has always been an experimental feature of 1.7.x so we stopped working on it a long time ago. Have you tried 9.1.9.0? It is a Ruby 2.3 impl which pretty robust now. |
@enebo Thanks for the response. Yeah, we've tried out JRuby 9k, including 9.1.9.0, and agree that this is definitely the direction we want to go in the future for Ruby 2.x language support. We've only continued supporting our users on JRuby 1.7.x because of some issues we'd reported previously here, #4112 (comment). We're continuing to work on our JRuby 9k migration, though, and very much have appreciated the community's help along the way. In the event that you might have to do another JRuby 1.7.x roll, I think it might be nice to include the fix from the attached PR if it seems reasonable. Thanks again for your help! |
This commit removes support for the compat-version setting from jruby-utils. The compat-version setting was introduced in jruby-utils version 0.4.0 to allow for JRuby 1.7 to optionally run under Ruby language version 2.0 instead of the default version, 1.9. JRuby 1.7.27 effectively breaks the ability to use Ruby language version 2.0, however, due to a regression - see: jruby/jruby#4613 - and is unlikely to be fixed in the future. JRuby 9k also does not support compat-version configurability. Now that jruby-utils can be used with JRuby 9k for Ruby language 2+ support, it is no longer valuable to be able to set compat-version to 2 for use with JRuby 1.7. This commit effectively fixes JRuby 1.7 to always use Ruby language version 1.9 - as was the case before jruby-utils version 0.4.0. jruby-utils will now have to be used with JRuby 9k for Ruby language 2+ version support.
This commit removes support for the compat-version setting from jruby-utils. The compat-version setting was introduced in jruby-utils version 0.4.0 to allow for JRuby 1.7 to optionally run under Ruby language version 2.0 instead of the default version, 1.9. JRuby 1.7.27 effectively breaks the ability to use Ruby language version 2.0, however, due to a regression - see: jruby/jruby#4613 - and is unlikely to be fixed in the future. JRuby 9k also does not support compat-version configurability. Now that jruby-utils can be used with JRuby 9k for Ruby language 2+ support, it is no longer valuable to be able to set compat-version to 2 for use with JRuby 1.7. This commit effectively fixes JRuby 1.7 to always use Ruby language version 1.9 - as was the case before jruby-utils version 0.4.0. jruby-utils will now have to be used with JRuby 9k for Ruby language 2+ version support.
This commit removes support for the compat-version setting from jruby-utils. The compat-version setting was introduced in jruby-utils version 0.4.0 to allow for JRuby 1.7 to optionally run under Ruby language version 2.0 instead of the default version, 1.9. JRuby 1.7.27 effectively breaks the ability to use Ruby language version 2.0, however, due to a regression - see: jruby/jruby#4613 - and is unlikely to be fixed in the future. JRuby 9k also does not support compat-version configurability. Now that jruby-utils can be used with JRuby 9k for Ruby language 2+ support, it is no longer valuable to be able to set compat-version to 2 for use with JRuby 1.7. This commit effectively fixes JRuby 1.7 to always use Ruby language version 1.9 - as was the case before jruby-utils version 0.4.0. jruby-utils will now have to be used with JRuby 9k for Ruby language 2+ version support.
This commit removes support for the jruby-puppet.compat-version setting. The compat-version setting was introduced in Puppet Server 2.7.0 to allow for JRuby to run under Ruby language version 2.0 instead of the default version, 1.9. Setting compat-version to "2.0" for JRuby 1.7.27, however, was broken due to a regression - see: jruby/jruby#4613 - and is unlikely to be fixed in the future. For Puppet Server 5+, users will be able to, via the JRUBY_JAR environment variable in packaging, configure JRuby 9k to be used instead of JRuby 1.7 for Ruby language version 2+ support. In conjunction with a corresponding jruby-utils bump, this commit causes the presence of the jruby-puppet.compat-version setting to throw an error at startup, with a message indicating how users can configure the use of JRuby 9k for Ruby language version 2+ support.
This commit bumps the jruby-deps dependency for 1.7 from 1.7.26-2 to 1.7.27-1 and jruby-utils dep from 0.9.0 to 0.10.0. This commit removes support for the jruby-puppet.compat-version setting. The compat-version setting was introduced in Puppet Server 2.7.0 to allow for JRuby to run under Ruby language version 2.0 instead of the default version, 1.9. Setting compat-version to "2.0" for JRuby 1.7.27, however, was broken due to a regression - see: jruby/jruby#4613 - and is unlikely to be fixed in the future. For Puppet Server 5+, users will be able to, via the JRUBY_JAR environment variable in packaging, configure JRuby 9k to be used instead of JRuby 1.7 for Ruby language version 2+ support. In conjunction with a corresponding jruby-utils bump, this commit causes the presence of the jruby-puppet.compat-version setting to throw an error at startup, with a message indicating how users can configure the use of JRuby 9k for Ruby language version 2+ support.
Okay, back to 1.7.26 it is .. that was quite annoying! be aware that people might still stuck on 1.7.* and upgrading to the latest 1.7 (1.7.27) might lead to this extremely confusing bug. I had to add "$stderr.puts 'here'" at various locations to find it. |
Because `llt.war` can no longer be updated due to [https://github.com/jruby/jruby/issues/4613](https://github.com/jruby/jruby/issues/4613) Manually update `/usr/share/tomcat6/webapps/llt/WEB-INF/gems/bundler/gems/llt-review-517c60c50457/lib/llt/review/api.rb` to use `https` (incorporating [https://github.com/perseids-project/llt-review/commit/617b60a2be01c4010eb9b17bb7b7680525a205fb](https://github.com/perseids-project/llt-review/commit/617b60a2be01c4010eb9b17bb7b7680525a205fb))
Environment
Provide at least:
jruby -v
) and command line (flags, JRUBY_OPTS, etc)uname -a
)Expected Behavior
Requiring and using the yaml library should work.
When I run the following under JRuby 1.7.26...
... the command returns the version and exits properly:
Actual Behavior
When I run the jruby command from above on JRuby 1.7.27, the command hangs indefinitely. I waited several minutes before killing the process. The process has hung on every attempt I've made.
Note that the command completes successfully (without hanging) if I run it under the default compatibility version, 1.9 (with or without setting the -Djruby.compat.version property).
Here is a stack trace on the hanging thread:
The text was updated successfully, but these errors were encountered: