JRuby

Glassfish failing to load JRUBY

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.4, JRuby 1.5.0.RC1, JRuby 1.5.0.RC2
  • Fix Version/s: JRuby 1.6RC1
  • Component/s: None
  • Labels:
    None
  • Environment:
    ubuntu server 10.04
    jruby 1.5.0.RC1
    java 1.6.0_u20
    glassfish v3
    rails 2.3.5
  • Number of attachments :
    1

Description

while starting, Glassfish failing to load JRUBY with the following errors:

[#|2010-05-10T20:28:11.613+0300|SEVERE|glassfishv3.0|org.glassfish.scripting.jruby.JRubyContainer|_ThreadID=23;_ThreadName=Thread-1;|library `socket' could not be loaded: java.lang.LinkageError: loader (instance of java/net/URLClassLoader): attempted duplicate class definition for name: "org/jruby/ext/socket/RubySocket"
from /usr/local/lib/jruby-1.5.0.RC1/lib/ruby/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:134:in `process'
from /usr/local/lib/jruby-1.5.0.RC1/lib/ruby/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:113:in `run'
from /opt/glassfishv3/glassfish/domains/domain1/applications/apa/config/environment.rb:9
from /opt/glassfishv3/glassfish/domains/domain1/applications/apa/config/environment.rb:31:in `require'
from /usr/local/lib/jruby-1.5.0.RC1/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
from file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/rack/adapter/rails.rb:98:in `load_application'
from file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/rack/adapter/rails.rb:75:in `initialize'
from file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/jruby/rack/rails.rb:25:in `new'
from file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/jruby/rack/rails.rb:25:in `new'
from <script>:1

/usr/local/lib/jruby-1.5.0.RC1/lib/ruby/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:271:in `require_frameworks': library `socket' could not be loaded: java.lang.LinkageError: loader (instance of java/net/URLClassLoader): attempted duplicate class definition for name: "org/jruby/ext/socket/RubySocket" (RuntimeError)
from /usr/local/lib/jruby-1.5.0.RC1/lib/ruby/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:134:in `process'
from /usr/local/lib/jruby-1.5.0.RC1/lib/ruby/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:113:in `run'
from /opt/glassfishv3/glassfish/domains/domain1/applications/apa/config/environment.rb:9
from /opt/glassfishv3/glassfish/domains/domain1/applications/apa/config/environment.rb:31:in `require'
from /usr/local/lib/jruby-1.5.0.RC1/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
from file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/rack/adapter/rails.rb:98:in `load_application'
from file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/rack/adapter/rails.rb:75:in `initialize'
from file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/jruby/rack/rails.rb:25:in `new'
from file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/jruby/rack/rails.rb:25:in `new'
from <script>:1
...internal jruby stack elided...
from Rails::Initializer.require_frameworks(/usr/local/lib/jruby-1.5.0.RC1/lib/ruby/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:134)
from Rails::Initializer.process(/usr/local/lib/jruby-1.5.0.RC1/lib/ruby/gems/1.8/gems/rails-2.3.5/lib/initializer.rb:113)
from #<Class:01x5a372f43>.run(/opt/glassfishv3/glassfish/domains/domain1/applications/apa/config/environment.rb:9)
from (unknown).(unknown)(/opt/glassfishv3/glassfish/domains/domain1/applications/apa/config/environment.rb:31)
from Kernel.require(/usr/local/lib/jruby-1.5.0.RC1/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31)
from Kernel.require(file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/rack/adapter/rails.rb:98)
from Rack::Adapter::Rails.load_application(file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/rack/adapter/rails.rb:75)
from Rack::Adapter::Rails.initialize(file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/jruby/rack/rails.rb:25)
from (unknown).new(file:/opt/glassfishv3/glassfish/modules/grizzly-jruby.jar!/jruby/rack/rails.rb:25)
from #<Class:01x330a9da7>.new(<script>:1)
from (unknown).(unknown)(:1)

#]

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

I think we have seen this before and it was determined to be a GlassFish thing, but I don't recall for certain now... I know it didn't appear to be something we were doing.

Show
Charles Oliver Nutter added a comment - I think we have seen this before and it was determined to be a GlassFish thing, but I don't recall for certain now... I know it didn't appear to be something we were doing.
Hide
Permalink
Hiro Asari added a comment -

This was opened from a discussion on IRC. There, this thread was mentioned:

http://www.ruby-forum.com/topic/202272

Show
Hiro Asari added a comment - This was opened from a discussion on IRC. There, this thread was mentioned: http://www.ruby-forum.com/topic/202272
Hide
Permalink
robot ebobot added a comment -

Charles,

but is it really GlassFish? Seems like the problem appeared after 1.6.0u17, so seems like it is java issue. Or maybe it is not an issue, but smth has changed in loading logic or whatever.

The situation for now is that nobody can really run jruby-on-rails applications on glassfish v3 (every java below u20 has a bug and exploit available).

So maybe it is possible to find some workaround from jruby side?

Show
robot ebobot added a comment - Charles, but is it really GlassFish? Seems like the problem appeared after 1.6.0u17, so seems like it is java issue. Or maybe it is not an issue, but smth has changed in loading logic or whatever. The situation for now is that nobody can really run jruby-on-rails applications on glassfish v3 (every java below u20 has a bug and exploit available). So maybe it is possible to find some workaround from jruby side?
Hide
Permalink
Charles Oliver Nutter added a comment -

If we knew what was causing it, we would gladly try to find a workaround. The current logic for loading the socket subsystem loads them lazily using either the classloader that loaded JRuby (if it's loaded by an application, for example) or from the system classloader if the classloader that loaded JRuby is null. In either case, it's pretty much a simple reflective load of a class. The errors in GF also don't appear to match what I'd expect from the normal load process...so I'm confused by this.

Show
Charles Oliver Nutter added a comment - If we knew what was causing it, we would gladly try to find a workaround. The current logic for loading the socket subsystem loads them lazily using either the classloader that loaded JRuby (if it's loaded by an application, for example) or from the system classloader if the classloader that loaded JRuby is null. In either case, it's pretty much a simple reflective load of a class. The errors in GF also don't appear to match what I'd expect from the normal load process...so I'm confused by this.
Hide
Permalink
Hiro Asari added a comment -

Here is the glassfish ticket on this issue: https://glassfish.dev.java.net/issues/show_bug.cgi?id=11447

Show
Hiro Asari added a comment - Here is the glassfish ticket on this issue: https://glassfish.dev.java.net/issues/show_bug.cgi?id=11447
Hide
Permalink
Ryan Steckler added a comment -

I found a code workaround in JRuby that fixes this. It's a hack, but hopefully it sets a JRuby expert off in the right direction.

1) The exception is actually thrown from org.jruby.ext.socket.RubySocket line 101 (RubySocket.createSocket(runtime). This isn't surprising, as it's the first time the RubySocket class is actually utilized. I didn't actually expect it would make it all the way into RubySocket.Service.load, but it does.

2) The problem can be "fixed" by modifying RubySocket and adding a new public static method called doNothing(). The method can have an empty definition.

3) Now, in org.jruby.Ruby.java, add a call to the doNothing() method at line 1449 (just before addLazyBuiltin("socket.jar", "socket", "org.jruby.ext.socket.RubySocket$Service").

That's it. It works. I wish I knew why, but I'll leave that up to someone who better understands the jruby class/library loading model.

Hope this helps.

Show
Ryan Steckler added a comment - I found a code workaround in JRuby that fixes this. It's a hack, but hopefully it sets a JRuby expert off in the right direction. 1) The exception is actually thrown from org.jruby.ext.socket.RubySocket line 101 (RubySocket.createSocket(runtime) . This isn't surprising, as it's the first time the RubySocket class is actually utilized. I didn't actually expect it would make it all the way into RubySocket.Service.load, but it does. 2) The problem can be "fixed" by modifying RubySocket and adding a new public static method called doNothing(). The method can have an empty definition. 3) Now, in org.jruby.Ruby.java, add a call to the doNothing() method at line 1449 (just before addLazyBuiltin("socket.jar", "socket", "org.jruby.ext.socket.RubySocket$Service") . That's it. It works. I wish I knew why, but I'll leave that up to someone who better understands the jruby class/library loading model. Hope this helps.
Hide
Permalink
Nick Sieger added a comment -

I wonder if the fact that RubySocket$Service is an inner class is part of the problem? I committed a workaround in 58ee674, maybe someone can try it with a trunk build?

Show
Nick Sieger added a comment - I wonder if the fact that RubySocket$Service is an inner class is part of the problem? I committed a workaround in 58ee674, maybe someone can try it with a trunk build?
Hide
Permalink
Charles Oliver Nutter added a comment -

Nick's workaround seems to be solving the problem for most folks. I would bet on this being either a JDK or a Felix (GF's OSGI container) bug; reflectively loading an inner class should work just fine.

At any rate, I've modified all other inner-class libraries (in r2821265) to be normal toplevel classes, to avoid seeing this for other libraries.

Another workaround is to reflectively access the outer class (e.g. RubySocket) before loading the library through normal means. This causes the init sequence to work properly and prevents the blow-up. That's not always possible, though, since the library load may be triggered before user code.

Show
Charles Oliver Nutter added a comment - Nick's workaround seems to be solving the problem for most folks. I would bet on this being either a JDK or a Felix (GF's OSGI container) bug; reflectively loading an inner class should work just fine. At any rate, I've modified all other inner-class libraries (in r2821265) to be normal toplevel classes, to avoid seeing this for other libraries. Another workaround is to reflectively access the outer class (e.g. RubySocket) before loading the library through normal means. This causes the init sequence to work properly and prevents the blow-up. That's not always possible, though, since the library load may be triggered before user code.
Hide
Permalink
Alan O'Leary added a comment -

I'm hitting this error at the moment the following is my environment:

jruby-1.5.2
java-1.6.0_20
glassfish 3.0.1
rails 2.3.5

What trunk version is referred to by the workaround ?
I assumed 1.5.2 might resolve this - kinda stuck at the moment
Causing big headaches at the moment
I will try to downgrade the JVM (b17) in a test environment, but dont want to have to do that on the target production server

Show
Alan O'Leary added a comment - I'm hitting this error at the moment the following is my environment: jruby-1.5.2 java-1.6.0_20 glassfish 3.0.1 rails 2.3.5 What trunk version is referred to by the workaround ? I assumed 1.5.2 might resolve this - kinda stuck at the moment Causing big headaches at the moment I will try to downgrade the JVM (b17) in a test environment, but dont want to have to do that on the target production server
Hide
Permalink
Hiro Asari added a comment -

Workaround is http://github.com/jruby/jruby/commit/282126570e79430f48c2a9b925effe03cf2d4fe6

This is not in the 1.5 branch. Can you try the snapshot from http://ci.jruby.org/snapshots/ and see if it fixes your problem?

Show
Hiro Asari added a comment - Workaround is http://github.com/jruby/jruby/commit/282126570e79430f48c2a9b925effe03cf2d4fe6 This is not in the 1.5 branch. Can you try the snapshot from http://ci.jruby.org/snapshots/ and see if it fixes your problem?
Hide
Permalink
Alan O'Leary added a comment -

I can confirm that both workarounds worked independently

1) Downgrading to b17 worked

or

2) Using the latests 1.6.0.dev snapshot

Having both of those for now should help most people until a final 1.6.0 is released

Thanks - A

Show
Alan O'Leary added a comment - I can confirm that both workarounds worked independently 1) Downgrading to b17 worked or 2) Using the latests 1.6.0.dev snapshot Having both of those for now should help most people until a final 1.6.0 is released Thanks - A
Hide
Permalink
Charles Oliver Nutter added a comment -

Fixed in 1.6 (and I think in 1.5.2 or 1.5.3), workaround is to downgrade Java version.

Show
Charles Oliver Nutter added a comment - Fixed in 1.6 (and I think in 1.5.2 or 1.5.3), workaround is to downgrade Java version.
Hide
Permalink
asbrus putin added a comment -

I'm trying to get this to work. Can someone please explain how to download my Java version, or download the new Jruby1.6 version?

Show
asbrus putin added a comment - I'm trying to get this to work. Can someone please explain how to download my Java version, or download the new Jruby1.6 version?
Hide
Permalink
gab added a comment -

Found remaining inner classes, which cause problems running Redmine on JRuby and Glassfish. The attached patch moves the inner classes of org.jruby.util.ReferenceReaper into top level classes PhantomReferenceReaper, SoftReferenceReaper and WeakReferenceReaper.
Please note I don't have any significant knowledge about JRuby, nor git.

Show
gab added a comment - Found remaining inner classes, which cause problems running Redmine on JRuby and Glassfish. The attached patch moves the inner classes of org.jruby.util.ReferenceReaper into top level classes PhantomReferenceReaper, SoftReferenceReaper and WeakReferenceReaper. Please note I don't have any significant knowledge about JRuby, nor git.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    robot ebobot
Vote (1)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: