Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Question about code caching in 1.7.27 #4791

Closed
seanguo opened this issue Sep 19, 2017 · 9 comments
Closed

Question about code caching in 1.7.27 #4791

seanguo opened this issue Sep 19, 2017 · 9 comments
Labels
feedback needed JRuby 1.7.x
Milestone
Won't Fix

Comments

@seanguo
Copy link

seanguo commented Sep 19, 2017

We have the following JRuby loading issue after we upgraded from 1.7.21 to 1.7.27:

org.jruby.embed.EvalFailedException: (NameError) uninitialized constant JSON::Ext::Parser with cause: org.jruby.embed.EvalFailedException: (NameError) uninitialized constant JSON::Ext::Parser@T: javax.script.ScriptException: org.jruby.embed.EvalFailedException: (NameError) uninitialized constant JSON::Ext::Parser
 at org.jruby.embed.jsr223.JRubyEngine.wrapException(JRubyEngine.java:104)
 at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:93)
 at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:142)
 ...
 at java.lang.Thread.run(Thread.java:748)
Caused by: org.jruby.embed.EvalFailedException: (NameError) uninitialized constant JSON::Ext::Parser
 at org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:132)
 at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:90)
 ... 7 more
Caused by: org.jruby.exceptions.RaiseException: (NameError) uninitialized constant JSON::Ext::Parser
 at org.jruby.RubyModule.const_missing(org/jruby/RubyModule.java:2746)
 at RUBY.Ext(app/jruby/lib/ruby/shared/json/ext.rb:16)
 at RUBY.JSON(app/jruby/lib/ruby/shared/json/ext.rb:12)
 at RUBY.(root)(app/jruby/lib/ruby/shared/json/ext.rb:9)
 at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1040)
 at RUBY.(root)(app/jruby/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:1)
 at RUBY.require(app/jruby/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:54)
 at RUBY.JSON(app/jruby/lib/ruby/shared/json.rb:58)
 at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1040)
 at RUBY.(root)(app/jruby/lib/ruby/shared/json.rb:54)
 at RUBY.(root)(app/jruby/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:1)

The script is just a simple require for the library.

And we suspected that it may be caused by our Java security manager settings. But after turning off the security manager and turning it on again we can not reproduce this issue.

So are there any caches generated somewhere which led to this behavior? How can I invalidate the cache?

Thanks.
@kares
Copy link
Member

kares commented Sep 19, 2017

no caches are being kept - it must be an issue related to concurrent loading (requires from multiple threads)

@seanguo
Copy link
Author

seanguo commented Sep 19, 2017

Anything I can provide to help you debug this issue?
Thanks

@kares
Copy link
Member

kares commented Sep 19, 2017

not really, we could come up with a way to make it happen less (by avoiding multiple threads as assumed previously). JRuby 1.7.x is EOL so its not much worth reproducing since there's no 1.7.x release planned...

give it a go on latest 9K ... if it does its likely worth digging deeper (creating an isolated reproducable .rb).

@seanguo
Copy link
Author

seanguo commented Sep 20, 2017

Thanks for your suggestion.
One thing I don't understand is that we can always reproduce for the first time. But after a JVM restart we can not reproduce again no matter how many times I tried. If it's a threading issue it should be reproducible at a certain probability, right?
Also the script is executed in a single thread and no other threads running the same script at the same time.

@kares
Copy link
Member

kares commented Sep 20, 2017

first cold JVM start might always be a bit slower, if you have a simple enough script to reproduce we can take a look if there's a reasonable workaround.

@kares
Copy link
Member

kares commented Sep 20, 2017

also give 1.7.26 a try, as the autoloading patch might have been back ported in 27 or simply stay with 21 there isn't that much difference. preferably go for JRuby 9.1 in the long run ...

@headius
Copy link
Member

headius commented Oct 30, 2017

Are you able to test this on a recent 9k?

@seanguo
Copy link
Author

seanguo commented Oct 31, 2017

Recent 9k does not have this issue but we are blocked on #4796

@headius
Copy link
Member

headius commented Oct 31, 2017

@seanguo I could find no evidence of a bug for #4796 so hopefully that won't block you (or my workarounds for your particular issue will be good enough).

@headius headius closed this as completed Nov 28, 2017
@headius headius added this to the Won't Fix milestone Nov 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feedback needed JRuby 1.7.x
Projects
None yet
Milestone
Won't Fix
Development

No branches or pull requests
3 participants
@headius @kares @seanguo