955422512366379010 2018-07-16T07:55:00 2018-07-16T07:55:00Z 47022513 pb-com 22.214.171.124 Local7 Info app/web.2  ! Terminating timed out worker: 14459 955422516652969998 2018-07-16T07:55:01 2018-07-16T07:55:01Z 47022513 pb-com 126.96.36.199 Local7 Info app/web.2 I, [2018-07-16T07:55:01.116331 #14500] INFO -- : Installing Puma worker loop. 955422516787187716 2018-07-16T07:55:01 2018-07-16T07:55:01Z 47022513 pb-com 188.8.131.52 Local7 Info app/web.2  - Worker 0 (pid: 14500) booted, phase: 0
Sep 12 10:27:23 pb-com heroku/web.3: Stopping all processes with SIGTERM Sep 12 10:27:53 pb-com heroku/web.3: Error R12 (Exit timeout) -> At least one process failed to exit within 30 seconds of SIGTERM Sep 12 10:27:53 pb-com heroku/web.3: Stopping remaining processes with SIGKILL Sep 12 10:27:53 pb-com heroku/web.3: Process exited with status 137
I’m moving my Ruby MRI Rails app to JRuby and I’m worried about multi threading.
I used to use the Unicorn server which is a multi-processes server and I’m moving to JRuby and Puma (multi-threaded).
I’m looking, thanks to VisualVM, how the threads behave when I’m pushing several HTTP calls to the app and I see a lot of thread doing nothing.
How can I check that calls are correctly dispatched to threads ?
Here’s a screenshot of visualVM: https://www.dropbox.com/s/w43paa57m5jf8l3/Screenshot%202018-11-14%2015.18.55.png?dl=0
Anyone here that can help me with puma not starting with a Sinatra app?
workers Integer(ENV['WEB_CONCURRENCY'] || 2) threads_count = Integer(ENV['THREAD_COUNT'] || 5) threads threads_count, threads_count rackup DefaultRackup port ENV['PORT'] || 3000 environment ENV['RACK_ENV'] || 'development'
$ bundle exec puma -C config/puma.rb bundler: failed to load command: puma (/home/dhollinger/.asdf/installs/ruby/2.5.1/bin/puma) NoMethodError: undefined method `workers' for main:Object /home/dhollinger/workspace/ruby/puppet_webhook/config/puma.rb:1:in `<top (required)>' /home/dhollinger/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/puma-3.12.0/lib/puma/cli.rb:4:in `require' /home/dhollinger/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/puma-3.12.0/lib/puma/cli.rb:4:in `<top (required)>' /home/dhollinger/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/puma-3.12.0/bin/puma:6:in `require' /home/dhollinger/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/puma-3.12.0/bin/puma:6:in `<top (required)>' /home/dhollinger/.asdf/installs/ruby/2.5.1/bin/puma:23:in `load' /home/dhollinger/.asdf/installs/ruby/2.5.1/bin/puma:23:in `<top (required)>'
Thread.currentvariables being nil in the model, despite being initialized by Rails initializers. The gem in question is PublicActivity and I'm running Rails 6. I tried before_fork and on_worker_boot, but my presumption is, that Rails 6 does some threading on top of whatever server it is running on. Is that possible?
I have a rails app (written by an outside company) running in Puma 3.11.4 on Ruby 2.2 (I know, sorry) and am running into all sorts of errors that I think have already been fixed in newer versions. As part of figuring out what's going on sorting out TLS problems and 100% CPU puma, our vendor tells us that it is "best practice" to not have Puma handle TLS but instead have nginx in front.
currently we have (more or less):
puma (in docker container) <---TLS port--- AWS Application Load Balancer <---TLS port------ some browser
and the vendor says that the well established best practice is:
puma (in docker container) <---TCP port--- nginx <----TLS port---- AWS Application Load Balancer <---TLS port------ some browser
because "puma isn't meant to handle TLS"
is that correct at all? I can't find anything to support it with some rudimentary searching. Also having two proxies seems like we're just asking for trouble.
I'm also just trying to update their code to use newer Puma and newer Ruby where I suspect those TLS issues will be fixed (at least from reading the
I have a change for those that might be using Puma + JRuby; to enable Netty's OpenSSL native bindings.
I'd welcome feedback from JRuby users
Speed: In local testing, we've seen performance improvements of 3x over the JDK. GCM, which is used by the only cipher suite required by the HTTP/2 RFC, is 10-500x faster.