Aargh, 4fd558e27df6fb1a6019bc9322d96361e5ae536a is the culprit.
Author: Hiroshi Nakamura <email@example.com>
Date: Thu Dec 2 23:43:38 2010 +0900
Proof of concept fix for JRUBY-5200: configureBlocking free select.
RubyThread.select for both sysread and syswrite is a source of deadlock
when 2 operations are running by different Thread. RubyThread.select try
to synchronize SelectableChannel.blockingLock first so it cannot be used
for different SelectionKey.OP_* operations.
This commit copies RubyThread.select to SSLSocket and remove
blockingLock. This impl just set
SelectableChannel.configureBlocking(false) permanently instead of
setting temporarily. SSLSocket requires wrapping IO to be selectable so
it should be OK to set configureBlocking(false) permanently I think...
I copied Thread.select to SSLSocket.waitSelect. As the result, Timeout task cannot interrupt the selector used in SSLSocket (The task interrupts Thread#currentSelector.) So, we cannot copy Thread.select to avoid the deadlock that is fixed by above commit.
JRuby 1.7 should fix this issue by merging SSLSocket.waitSelect back into Thread.select. We need to find a workaround for jruby-1_6...