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
Compatibility with puma and Rails - "WARNING: Detected 2 Thread(s) started in app boot:" #868
Comments
Should concurrent-ruby be creating threads at require-time? I think this could create risks for anyone using a preforking webserver. |
I just noticed this warning in my app running via Puma, too. I took a look at the latest code in This PR was merged only yesterday! Lucky timing :) @pitr-ch out of interest, were you aware of this Puma-related issue when working on the changes in that PR? |
I was not, indeed a lucky timing :) |
I had a very similar if not the same issue and the patch from that pull request does eliminate the warning for concurrent-ruby. I still get the warning for ActiveRecord, but I guess that is a separate issue. Thank you all for your work! |
Released, so I think this can be closed. |
@nateberkopec please, could you confirm the warning is gone? Then I'll close. |
@pitr-ch I can confirm that I no longer see the warning using concurrent-ruby 1.1.7 (I was using concurrent-ruby 1.1.6 before). My app uses Puma 4.3.5 and Ruby 2.5 (and Sinatra, not Rails). |
@dentarg Thank you 👍 for confirming! |
Hello, I'm trying to debug a thread warning in puma. Here's the issue I opened over there: puma/puma#2237
The problem seems to be that requiring
lib/concurrent-ruby/concurrent/atomic/ruby_thread_local_var.rb
immediately starts a newThread
.Here's the stack trace when puma loads my application:
When puma is running in "clustered" mode, it forks a new process for each worker, so the Thread started by the
RubyThreadLocalVar
class is not running inside any of these worker processes. Is this a problem? My first impression is that this might cause a memory leak because none of the thread-local variables are ever getting released and garbage collected in my puma workers. (But I'm not sure which parts of Rails are using this.)New threads can be started inside
puma.on_worker_boot
, so should we doing something like:Or maybe puma should do this automatically if it detects the concurrent-ruby library?
Thanks for your time!
The text was updated successfully, but these errors were encountered: