Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No response from rails 4.2.8 with puma in production mode JRuby 9.1.8.0+9.1.9.0 on Linux #4615

Closed
donv opened this issue May 19, 2017 · 12 comments

Comments

@donv
Copy link
Member

donv commented May 19, 2017

Environment

jruby 9.1.9.0 (2.3.3) 2017-05-15 28aa830 Java HotSpot(TM) 64-Bit Server VM 25.112-b15 on 1.8.0_112-b15 +jit [linux-x86_64]

CentOS release 6.9 (Final):
Linux 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Apr 11 17:13:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu 14.04.5 LTS:
Linux 4.4.0-75-generic #96~14.04.1-Ubuntu SMP Thu Apr 20 11:06:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I create a new Rails 4.2.8 app with a controller:

rails new test_app
cd test_app
rails g controller welcome index

Make welcome#index the root route in config/routes.rb:

  root 'welcome#index'

Add puma to the Gemfile:

gem 'puma'

Start in production mode:

SECRET_KEY_BASE=secret rails s -e production

Access the app:

curl http://localhost:3000

I see the request in the log:

I, [2017-05-19T15:06:05.873179 #4809]  INFO -- : Started GET "/" for 127.0.0.1 at 2017-05-19 15:06:05 +0200
I, [2017-05-19T15:06:05.896284 #4809]  INFO -- : Processing by WelcomeController#index as */*
I, [2017-05-19T15:06:05.912821 #4809]  INFO -- :   Rendered welcome/index.html.erb within layouts/application (0.7ms)
I, [2017-05-19T15:06:05.926719 #4809]  INFO -- : Completed 200 OK in 28ms (Views: 19.4ms | ActiveRecord: 0.0ms)

...but the request never completes for the client. The client just waits for the response to complete.

Reverting to JRuby 9.1.7.0 works.

Can anybody confirm this issue?

@alkalinecoffee
Copy link

Can you try adding -Djava.security.egd=file:/dev/urandom to your JAVA_OPTS?

@kares
Copy link
Member

kares commented May 21, 2017

you should also check with VisualVM or simply issuing a thread-dump jstack where's time spent.

@donv
Copy link
Member Author

donv commented May 22, 2017

@alkalinecoffee Will try it.

@donv
Copy link
Member Author

donv commented May 22, 2017

@kares Thanks for the tip, but nothing is using CPU. The request just does not complete.

Have any of you tried this?

@donv
Copy link
Member Author

donv commented May 22, 2017

@alkalinecoffee Adding the -Djava.security.egd=file:/dev/urandom option seems to work!

Thanks! 🎉

But why?! What problem does it solve, and why does it not affect version 9.1.7.0 and older?

@kares
Copy link
Member

kares commented May 22, 2017

@donv cause you have an updated jruby-openssl which updates BC which provides a secure-random impl ...
... which (in the end) seeds itself from a default JVM entropy source (used by Rails while encrypting cookies)

@kares kares closed this as completed May 22, 2017
@kares kares added this to the Invalid or Duplicate milestone May 22, 2017
@donv
Copy link
Member Author

donv commented May 23, 2017

Thanks for the explanation!

In my case giving the option to JRuby feels like a workaround. I found that installing and running haveged will make /dev/random behave nicely.

As far as I can see, the best way to handle this is for JRuby or jruby-openssl to set the -Djava.security.egd=file:/dev/urandom property since /dev/urandom is the preferred device for most use cases.

@kares
Copy link
Member

kares commented May 23, 2017

@donv unfortunately its not possible - by the time we would reach setPropeprty the Java security stack is already initialized. there probably is room to improve jruby-openssl (via BC's generators) to rely a bit less on feeding itself from /dev/random (by default)

@donv
Copy link
Member Author

donv commented May 23, 2017

@kares What about in the JRuby launcher?

@kares
Copy link
Member

kares commented May 23, 2017

@donv not sure its worth the hustle ... newer Java is expected to handle these right

@donv
Copy link
Member Author

donv commented May 23, 2017

@kares Sounds good. What is "newer Java" in this context? I am using 8u112-b15.

@kares
Copy link
Member

kares commented May 23, 2017

@donv ah so maybe that's just the /dev/./urandom fix in 8 than ... ('.' hack no longer required)
guess it makes sense that they won't do it in 8. sorry for the confusion I did not actually check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants