Process hangs when requiring yaml under compat-version 2.0 on JRuby 1.7.27 #4613
Labels
Comments
camlow325
changed the title
|
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 |
camlow325
added a commit
to camlow325/jruby
that referenced
this issue
May 19, 2017
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! |
camlow325
added a commit
to camlow325/jruby-utils
that referenced
this issue
May 25, 2017
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.
camlow325
added a commit
to camlow325/jruby-utils
that referenced
this issue
May 25, 2017
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.
camlow325
added a commit
to camlow325/jruby-utils
that referenced
this issue
May 25, 2017
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.
camlow325
added a commit
to camlow325/puppetserver
that referenced
this issue
May 25, 2017
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.
camlow325
added a commit
to camlow325/puppetserver
that referenced
this issue
May 25, 2017
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. |
Closed
zfletch
added a commit
to perseids-project/llt
that referenced
this issue
May 18, 2020
Because `llt.war` can no longer be updated due to [jruby/jruby#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))
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: