JRuby

Incorrect SSLSocket implementation loaded despire require 'jruby/openssl/gem_only' statement.

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: JRuby 1.7.0.pre1
  • Component/s: None
  • Labels:
    None
  • Environment:
    jruby-jars-1.5.3
    jruby-openssl-0.7.1
    rails 2.3.3
    Linux
  • Number of attachments :
    0

Description

I have a Rails app running on Linux boxes (not sure what flavour, I don't have access to them) that occassional, after a daily restart, try and load the wrong SSL class implementations raising the following error:

2010-11-10 05:40:03,588 [TP-Processor162] {} INFO jruby.rack - Exception ArgumentError occured, with wrong # of arguments(2 for 0)
file:/vhosts/dw11570/content/20101108-232418/tomcat/webapps/iris3/WEB-INF/lib/jruby-stdlib-1.5.3.jar!/META-INF/jruby.home/lib/ruby/1.8/net/http.rb:567:in `initialize'
file:/vhosts/dw11570/content/20101108-232418/tomcat/webapps/iris3/WEB-INF/lib/jruby-stdlib-1.5.3.jar!/META-INF/jruby.home/lib/ruby/1.8/net/http.rb:567:in `new'
file:/vhosts/dw11570/content/20101108-232418/tomcat/webapps/iris3/WEB-INF/lib/jruby-stdlib-1.5.3.jar!/META-INF/jruby.home/lib/ruby/1.8/net/http.rb:567:in `connect'
file:/vhosts/dw11570/content/20101108-232418/tomcat/webapps/iris3/WEB-INF/lib/jruby-stdlib-1.5.3.jar!/META-INF/jruby.home/lib/ruby/1.8/net/http.rb:553:in `do_start'
file:/vhosts/dw11570/content/20101108-232418/tomcat/webapps/iris3/WEB-INF/lib/jruby-stdlib-1.5.3.jar!/META-INF/jruby.home/lib/ruby/1.8/net/http.rb:542:in `start'
/vhosts/dw11570/content/current/contentsys/compiled/tomcat/webapps/iris3/WEB-INF/gems/gems/savon-0.7.9/lib/savon/request.rb:82:in `wsdl'
/vhosts/dw11570/content/current/contentsys/compiled/tomcat/webapps/iris3/WEB-INF/gems/gems/savon-0.7.9/lib/savon/wsdl.rb:122:in `to_s'
/vhosts/dw11570/content/current/contentsys/compiled/tomcat/webapps/iris3/WEB-INF/gems/gems/savon-0.7.9/lib/savon/wsdl.rb:131:in `stream'
/vhosts/dw11570/content/current/contentsys/compiled/tomcat/webapps/iris3/WEB-INF/gems/gems/savon-0.7.9/lib/savon/wsdl.rb:94:in `soap_actions'
/vhosts/dw11570/content/current/contentsys/compiled/tomcat/webapps/iris3/WEB-INF/gems/gems/savon-0.7.9/lib/savon/wsdl.rb:110:in `respond_to?'
/vhosts/dw11570/content/current/contentsys/compiled/tomcat/webapps/iris3/WEB-INF/gems/gems/savon-0.7.9/lib/savon/client.rb:92:in `method_missing'

I've tried adding require 'jruby/openssl/gem_only' to the environment.rb file, to try an expose the conflic, as documented here:

http://jruby.org/openssl

but the error still occurs, without reporting the conflict

I've not been able to replicate the error in console/jirb or test case so far..

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Erik Eide added a comment -

Small typo, I meant rails 2.3.8

Show
Erik Eide added a comment - Small typo, I meant rails 2.3.8
Hide
Permalink
Charles Oliver Nutter added a comment -

Very strange. Have you managed to update JRuby and jruby-openssl recently to see if it still exhibits the problem?

Show
Charles Oliver Nutter added a comment - Very strange. Have you managed to update JRuby and jruby-openssl recently to see if it still exhibits the problem?
Hide
Permalink
Erik Eide added a comment -

Yeah, we've had it from JRuby 1.5.1 (when we first migrated from MRI) through to the current 1.5.6 release.

Maybe my initial post wasn't very clear. The error is really just JRuby loading an dummy SSLSocket implementation (who's initialize method takes 0 args, not the usual 2) instead of the real one in the jruby-openssl library. We see it at the first invocation of an SSL based operation after a daily restart, and on those instances where it happens, it continues to happen until we restart it again. On those where it finds and loads the correct class, it operates normally without error.

Because it doesn't always happen after a restart, I would guess it's related to the ordering in which operations occur after a restart, so on those nodes where it fails, JRuby is loading libraries in a different order than on those where it does work.

I've tried to reproduce the issue in a standalone application, and but no luck so far.

I've also tried to force the ordering of operations by creating an intializer class that makes an SSL based request during start-up, but it still only happens on some of the restarts. At least I can now see on which nodes it's failing and keep restarting those to try and clear the issue.

Show
Erik Eide added a comment - Yeah, we've had it from JRuby 1.5.1 (when we first migrated from MRI) through to the current 1.5.6 release. Maybe my initial post wasn't very clear. The error is really just JRuby loading an dummy SSLSocket implementation (who's initialize method takes 0 args, not the usual 2) instead of the real one in the jruby-openssl library. We see it at the first invocation of an SSL based operation after a daily restart, and on those instances where it happens, it continues to happen until we restart it again. On those where it finds and loads the correct class, it operates normally without error. Because it doesn't always happen after a restart, I would guess it's related to the ordering in which operations occur after a restart, so on those nodes where it fails, JRuby is loading libraries in a different order than on those where it does work. I've tried to reproduce the issue in a standalone application, and but no luck so far. I've also tried to force the ordering of operations by creating an intializer class that makes an SSL based request during start-up, but it still only happens on some of the restarts. At least I can now see on which nodes it's failing and keep restarting those to try and clear the issue.
Hide
Permalink
Charles Oliver Nutter added a comment -

As of JRuby 1.7, we ship OpenSSL internally, so there should only be one SSLSocket now.

Show
Charles Oliver Nutter added a comment - As of JRuby 1.7, we ship OpenSSL internally, so there should only be one SSLSocket now.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Erik Eide
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: