OpenSSL 'connect_nonblock' missing/broken in 1.6.7 and 1.7.0.preview1

Jordan,

I think your ticket was JRUBY-6527, but the issue seems identical to JRUBY-6573. Could you review these errors and see if this is a duplicate?

Also, I should mention that on my MBP, the master behaves exactly as 1.6.7 does (as shown in the gist above).

$ jruby -v nonblock.rb
jruby 1.7.0.preview2.dev (ruby-1.9.3-p203) (2012-06-22 c006903) (Java HotSpot(TM) 64-Bit Server VM 1.7.0_04) [darwin-x86_64-java]
SSLSocket.java:194:in `connect_nonblock': java.lang.UnsupportedOperationException
	from MethodHandle.java:566:in `invokeWithArguments'
	from InvocationLinker.java:149:in `invocationFallback'
	from nonblock.rb:13:in `chained_0_rescue_1$RUBY$SYNTHETIC__file__'
	from nonblock.rb:12:in `__file__'
	from nonblock.rb:-1:in `load'
	from Ruby.java:778:in `runScript'
	from Ruby.java:771:in `runScript'
	from Ruby.java:648:in `runNormally'
	from Ruby.java:497:in `runFromMain'
	from Main.java:376:in `doRunFromMain'
	from Main.java:265:in `internalRun'
	from Main.java:231:in `run'
	from Main.java:215:in `run'
	from Main.java:195:in `main'

Hmm. JRUBY-6573 is a different issue. Please disregard my first comment.

Agreed, JRUBY-6573 appears to be a different problem.

I had a peak at src/org/jruby/ext/openssl/SSLSocket.java, both accept() and connect() invoke doHandshake(), and doHandshake() appears to be something like:

• while true
• wait until the socket is readable/writable
• do the next step in the handshake
• if finished, return.

That said, if you remove the 'while true', this seems to flow nicely with what connect_nonblock and accept_nonblock want anyway, right?

I'll have a go patching jruby master's sslsocket implementation to make connect_nonblock and accept_nonblock work.

Looking forward to your patch! Master is definitely the place to patch. If you can't get to this soon, let us know so we can try to fix it ourselves for pre2.

Jordan: Any update? Do we need to look into this ourselves?

I pushed a fix for this that also adds accept_nonblock. The fixed logic does run your test script to completion, but I have not confirmed that repeated connect_nonblock attempts will eventually succeed (e.g. they don't leave the socket in a bad state). We'll need to get 1.9's SSL tests running to confirm this, but in the short term you might be able to test out a master build to see if we're working well enough for you.

commit 3e280f007b298171c6d5598c7439833847c3d0f6
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Thu Jul 26 12:42:09 2012 -0500

    Fix (?) JRUBY-6746
    
    OpenSSL 'connect_nonblock' missing/broken in 1.6.7 and 1.7.0.preview1
    
    I implemented both connect_nonblock and accept_nonblock by passing
    a "blocking" flag to all methods that might block. The blocking
    methods usually did so by looping or waiting for selection events.
    
    The script given in the bug does now run to completion, but it
    does not re-attempt the connect. We still need to test that the
    socket is not in a bad state after a failed nonblocking connect,
    which I would guess means getting MRI 1.9 SSL tests running.

:100644 100644 e20167b... 3025496... M	src/org/jruby/ext/openssl/SSLSocket.java

Well, let's call it fixed. If it's not, reopen.

Your commit message describes essentially what I started working on before getting otherwise distracted with other tasks - I'll test this now. Thanks much!

% java -jar /Users/jsissel/projects/jruby/lib/jruby-complete.jar --1.9 nonblock.rb
IOError: Writing not possible during handshake

I'll debug further and try to figure out what's going on.

(the above: connect_nonblock is succeeding with no exceptions, but I don't think it's quite right)

require "openssl"
require "socket"

sslcontext = OpenSSL::SSL::SSLContext.new
sslcontext.ssl_version = "TLSv1"

tcp = TCPSocket.new("twitter.com", 443)
tls = OpenSSL::SSL::SSLSocket.new(tcp, sslcontext)

tls.connect_nonblock
tls.connect_nonblock # fails

Run:

% java -jar /Users/jsissel/projects/jruby/lib/jruby-complete.jar --1.9 x.rb       
SSLEngineImpl.java:1766:in `setUseClientMode': java.lang.IllegalArgumentException: Cannot change mode after SSL traffic has started

If I recall, the remaining issues were easy to fix in the jruby ssl code. I'll see what I can do about fixing these tonight if I get off my butt and hack on it

With respect to this ticket, though the 'missing/broken' I reported is fixed. I"ll file a separate ticket if I am able to make connect_nonblock/accept_nonblock execute correctly