Fix broken SSL support in jruby #106
Comments
|
😢 |
|
What needs to be done to support JRuby again? Just ran into this issue today because of a library that uses excon underneath. |
|
Dug around a little bit, and the issue seems to be caused by this problem: http://jira.codehaus.org/browse/JRUBY-5529 |
|
I wrote a quick hack that (somewhat) gets around these issues by using the blocking write and readpartial calls in jruby-openssl. It seems that using the non-blocking calls is a non-starter until these are implemented in jruby-openssl. At present, any non-blocking call would seems to raise an exception: https://github.com/jruby/jruby-ossl/blob/master/src/java/org/jruby/ext/openssl/SSLSocket.java#L576 And modifying the IO.select / exception rescue loops to catch this exception in excon results in an infinite loop. My hacks are at https://github.com/jasonl/excon/commit/13adcb3cbdd712d05ed40a30ae089d4c57966569 With this commit included, the majority of the tests pass, with the exception of the HTTP POST tests with an empty body. My socket-fu isn't good enough to work out why this is so. |
|
@mattmatt - That issue disappears when you run Jruby in 1.9 mode - there are differences between the 1.8 and 1.9 implementations of OpenSSL in Ruby, and that's one of them. When you run in 1.9 mode, you see different errors - the "read would raise" and "write would raise" exceptions from SSLSocket.java referenced above. |
|
@jasonl You are correct, sir. That was my bad, the library in question uses an outdated version of excon. I've updated it with the most recent one and your patch, and that seems to do the trick. |
|
The part that really got me is that it USED to work consistently and suddenly started failing (on travis). Guess their config for jruby perhaps changed to 1.9. |
|
Nope, 1.8 is default, you have to specify if you want 1.9. The JRuby version got updated though (we update it when needed). On 21/02/2012, at 4:54 PM, Wesley Beary wrote:
|
|
@joshk Yeah, not saying it was your fault. Just frustrating for read_nonblock to become undefined when I pushed some unrelated code... |
|
ARE YOU BLAMING ME!!! :D If there is anything we can help with Travis wise please pop into #travis Also, we now support matrix lines which 'can fail' and not affect the build, maybe you might want to turn the hook back on and allow JRuby to fail. On 21/02/2012, at 4:57 PM, Wesley Beary wrote:
|
|
@joshk how do I specify to build and ignore? I just browsed the docs and didn't have luck finding it. |
|
Sorry, we have yet to update the docs, check out the Rspec travis yml (rspec-mocks) :) On 21/02/2012, at 5:05 PM, Wesley Beary wrote:
|
|
@joshk cool, found it on rspec-rails. So excon should now build jruby + rbx again, but just allow failures. Hopefully that will help us keep track of how close we are to them working. |
|
❤️❤️❤️ On 21/02/2012, at 5:25 PM, Wesley Beary wrote:
|
|
I created an issue in the jruby-ossl issue tracker here: jruby/jruby-ossl#19 As long as I use an older jruby-ossl version (0.7.4 is the newest version that works) I can still use fog. So something changed after the 0.7.4 release to break write_nonblock. |
|
@atambo thanks for reporting that and figuring out which version works. I've update the gemfile dependency for it to try and get it working on travis again (but no luck so far, seems to be timing out now). Let me know if you see fixes on the jruby side and we'll change the version lock again. Thanks! |
|
@nirvdrum yes, I believe the HTTP POST portion was fixed. My concern was performance and support related in terms of adding all the extra conditionals to have different behavior between different platforms. That said, it used to work on jruby and my understanding had been that it breaking had been somebodies fault on that end (that I was hopeful they would fix). It has been long enough that it appears that may have been an unreasonable assumption. I'll look into some sort of fix, but I think the mechanics might differ a bit from the proposed patch here. |
|
Gotcha. I tried 0.7.4 and 0.7.6.1 in both 1.8 and 1.9 mode and was unable to get any combo to work. I'm happy to help out in any way I can. |
|
Released in 0.13.0. Sorry for the delay, should have taken action sooner instead of hoping that it would become fixed again from jruby-openssl... |
|
Thanks for this! Working successfully with excon 0.13.0 and jruby-openssl 0.7.4! (downgraded from 0.7.6.1) (using jruby 1.9 mode) |
|
In jruby 1.8 mode I'm able to use excon 0.13.0 and jruby 0.7.6.1 with fog master. |
|
Still getting - Excon::Errors::SocketError: write would raise The fix seems to be on the TODO list of jruby-ossl |
|
@jedi4ever - I think that might actually be a somewhat different error than the one I worked on before. Could you get me a stack trace to work from? Also it appears to have passed after the last push on CI, fwiw, you might check against those versions to see: http://travis-ci.org/#!/geemus/excon/jobs/1077989 (related to this, if you could see if the tests will run for you that would be great). Thanks and I hope with that extra info I can help you get it fixed. |
|
Simple code: require 'rubygems' With both excon from latest gem or from master $ jruby --1.9 g.rb Excon::Errors::SocketError: write would raise $ jruby --1.8 g.rb I'm convinced it's somewhere deep on the jruby/openssl stack :( |
|
Further investigation shows that using 0.7.4 of jruby-openssl works. The issue is that when using rvm , the jruby-openssl is installed in the global gemset |
|
Just wanted to add that I experienced the same bug, and also fixed it by downgrading to jruby-openssl 0.7.4. |
|
Quite glad that there is at least a viable workaround. |
|
It appears 0.7.7 is now available, is this still a problem for people or has it been fixed on their side? |
|
Tested on version 0.7.7 and the problem is still there. |
|
@azolotko - thanks for the update. If this keeps up maybe I will have to do something on our end after all. |
|
Another way around this should now be available. If you set |
|
@geemus is that option available on v0.15.5? It doesn't change anything for me: still getting “write would raise” |
|
@geemus My bad, I just realized there was a 0.16 release. Works with nonblock => false! |
|
@mislav - Awesome, glad to hear it. |
|
JRuby 1.7.1 seems to have fixed all the SSL problems I was having with Excon. |
|
@nirvdrum - awesome, thanks for the update! |
Description of http_backend_excon_nonblock: - If http_backend_excon_nonblock is true, Farday create Excon instance with nonblocking option which perform http request in nonblocking fassion - If http_backend_excon_nonblock is false, Fardday create Excon instance with blocking option which perform http request in blocking fassion Special Note about http_backend_excon_nonblock: If user use jRuby, you need to consider to configure http_backend_excon_nonblock=false. Since you may experince some issue. - excon/excon#106 - jruby/jruby-ossl#19 But if user is not using jRuby, you'd better to configure http_backend_excon_nonblock=true to prvent fluent-plugine-elasticsearch from stucking Background: The older version of v1.0.0(latest as of 23 March 2020) in Fardday(https://github.com/lostisland/farada), When we use excon(https://github.com/excon/excon) as a adapter for https, Faraday force to configure Excon to disable nonblock due to following jRuby specific problem - excon/excon#106 - jruby/jruby-ossl#19 That's why currently when fluent-plugin-elasticsearch plugin connect to Elastic Search, If it use http, Farday generate Excon instance with nonblocking=true(default of Excon), but in the case of https, Farady generate Excon instance with nonblocking=falase This actually cause the problem making Farday HTTP Client stuck when SSL Server(Elastic Search in current context) stuck during SSL Handshake since Excon SSLSocket can not respecting to timeout, and rely on timeout of SSL::SSLSocket in Ruby Standard Library which have exaclty process-hang problem. That's why sometimes flusth_thread of fluent-plugin-elasticsearch got stuck when Elastic Search had something problem during SSL Session handling. Root cause of this problem is actually implementation of SSL::SSLSocket in Ruby Standard Library(https://redmine.ruby-lang.org/issues/15729), so better to fix Ruby side but it will take a time, and require ruby version up, so better to provide the way to perform workaround.
Also, re-enable in travis.
The text was updated successfully, but these errors were encountered: