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

Question about code caching in 1.7.27 #4791

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

Comments

Projects
None yet
3 participants
@seanguo

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

This comment has been minimized.

Show comment
Hide comment
@kares

kares Sep 19, 2017

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@seanguo

seanguo Sep 19, 2017

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

seanguo commented Sep 19, 2017

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

@kares

This comment has been minimized.

Show comment
Hide comment
@kares

kares Sep 19, 2017

Member

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).

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

This comment has been minimized.

Show comment
Hide comment
@seanguo

seanguo 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.

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

This comment has been minimized.

Show comment
Hide comment
@kares

kares Sep 20, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@kares

kares Sep 20, 2017

Member

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 ...

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

This comment has been minimized.

Show comment
Hide comment
@headius

headius Oct 30, 2017

Member

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

Member

headius commented Oct 30, 2017

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

@seanguo

This comment has been minimized.

Show comment
Hide comment
@seanguo

seanguo Oct 31, 2017

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

seanguo commented Oct 31, 2017

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

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Oct 31, 2017

Member

@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).

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 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