-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
Jruby + Puma + Zero downtime deployment #4131
Comments
any details on the actual behaviour (anything being logged/printed) ? do not know about puma details on how it does "zero down-time" but I assume its not JRuby specific. with JRuby based webservers it was possible by starting another Ruby runtime in the same JVM process and letting it take over ... which worked as long as it did not leak. |
https://github.com/puma/puma#platform-constraints Puma explicitly tells here
Now I'm getting more confused whom I should be seeking help here. @headius https://twitter.com/headius/status/771383040333455361 😰 |
sorry for confusing you - just trying to gather more info if possible on the issue. thought I get details from you guys on how puma is doing the "phased-restart" (as your "left" option sounded reasonably good to me). you're on Linux platform constraints should not apply here. I am sure @headius will step in as well. |
Puma does phased restarts using workers. Currently, it is not supported on jRuby because of the use of fork(2) is limited (I think) on jRuby (this may have changed with jruby 9.x?). |
@TheKidCoder thanks ... that is about what I expected. fork won't ever really work on a JVM. |
@kares Sorry, I should have jumped on this since I kinda prompted it. I think we may have some options for restarting an app in JRuby without forking. The idea I have would be to make it possible to take the listening sockets and just swap them into a new runtime. The new runtime would load in the background (big startup time mitigation here), then we flip a switch and it starts servicing requests. It would simply be a matter of passing the old runtime's listening channels into the new one. I'll reopen this and we can do some experimentation. @TheKidCoder There is not and probably never will be a way to fork JRuby. But I think we can do something almost as good: just start up another JRuby in the same process and pass along the sockets to it. |
I'd love to contribute anyway I can. This has been a pain point for me for over a year now when using Puma. |
well, Puma is not using any JRuby runtime APIs ... so I wonder how you'll do it on JRuby's end not being a mess. this would need redoing Puma with JRuby specific code ... anyway I am looking forward to anything. |
@kares I would do it in Puma mostly. |
...or as a plugin for Puma that people could install. |
On second thought, I think this should be driven by a Puma issue. If there are specific things that JRuby can add to support it, that's fine, but this is a very old and amorphous bug. Closing again, as invalid. |
Environment - Any stage
9.1.2.0
engine:2.3.0
-J-Xcompile.invokedynamic=true -J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=1 -J-noverify -Xcompile.mode=OFF
14.04.4 LTS
Linux my-staging-app1 3.13.0-87-generic #133-Ubuntu SMP Tue May 24 18:32:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
My puma.rb looks like this
Expected Behavior
Actual Behavior
Due to this behaviour, I am left with this option:
The text was updated successfully, but these errors were encountered: