WARNING: Detected 5 Thread(s) started in app boot:

I suspect this is because threads behave like file handles, and forked
processes inherit and share file handles. In the Puma case, I'd imagine
that this means you have `n` processes sharing the same thread for AR
connection pool, some file watcher (4x?).

In theory if none of the child processes close the file handle it's
probably fine. After all stdout/err are file handles, and they're shared.
The warning is probably however that if any of the child processes close or
otherwise mangle the file handles then the other processes are starved.

In a setup where you want 10 connections to AR per worker, this would also
cause problems you'd get 10 total to share.

I might be overthinking, and it's just a warning because in _theory_ this
is a antipattern because your processes are less independent.

As for how to fix it, I'd guess "don't' use Puma" or at least don't use a
pre-forking web server? Or upgrade rails and/or the Gems... I think Rails
did better in later versions at giving a "post-fork" hook for thread- and
worker-pools to be initialized.

Ahoy, HTH

Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667


On Wed, 24 Jan 2024 at 07:34, 'Rob Whittaker' via North West Ruby User
Group (NWRUG) <nwrug-members@googlegroups.com> wrote:

> Hey, everybody!
>
>
> I have a side project of getting my first proper Rails app
> <https://github.com/purinkle/radfords> up to date. The last time I
> touched the project was about six years ago. Ruby, Rails, and all the other
> gems are out of date. I'm trying to be sensible and "safe" in my approach
> to each upgrade. This is more of an exercise in approach than anything
> else. The repo is public for folks who want to have a look.
>
>
> After a chat with Will at the previous NWRUG, I decided to fix any
> warnings before moving on. This is a sensible and logical plan. The latest
> thing on my list is this list of warnings from Puma.
>
>
> 07:33:22 web.1      |  [25567] ! WARNING: Detected 5 Thread(s) started in
> app boot:
>
> 07:33:22 web.1      |  [25567] ! 
> #<Thread:0x000000013acd2090@/Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/gems/2.5.0/gems/activerecord-5.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb:300
> sleep> -
> /Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/gems/2.5.0/gems/activerecord-5.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb:302:in
> `sleep'
>
> 07:33:22 web.1      |  [25567] !
> #<Thread:0x000000013d392360@listen-wait_thread@/Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/gems/2.5.0/gems/listen-3.8.0/lib/listen/thread.rb:17
> sleep_forever> -
> /Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/2.5.0/forwardable.rb:229:in
> `pop'
>
> 07:33:22 web.1      |  [25567] !
> #<Thread:0x000000013b7d1ba8@listen-worker_thread@/Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/gems/2.5.0/gems/listen-3.8.0/lib/listen/thread.rb:17
> sleep> -
> /Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/gems/2.5.0/gems/rb-fsevent-0.11.2/lib/rb-fsevent/fsevent.rb:44:in
> `select'
>
> 07:33:22 web.1      |  [25567] !
> #<Thread:0x000000013bef6b90@listen-run_thread@/Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/gems/2.5.0/gems/listen-3.8.0/lib/listen/thread.rb:17
> sleep> -
> /Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/gems/2.5.0/gems/listen-3.8.0/lib/listen/record/entry.rb:44:in
> `realpath'
>
> 07:33:22 web.1      |  [25567] !
> #<Thread:0x000000013bef46b0@listen-wait_thread@/Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/gems/2.5.0/gems/listen-3.8.0/lib/listen/thread.rb:17
> sleep_forever> -
> /Users/purinkle/.asdf/installs/ruby/2.5.9/lib/ruby/2.5.0/forwardable.rb:229:in
> `pop'
>
>
> I only see these warnings when I start the server using heroku local. If
> I start the server using rails s, then everything is okay.
>
>
> There is no pressure here; I want to use this repo as a learning space. I
> want to understand the problem more than anything else. Is this something
> that I can fix? Is it something that a future gem bump will fix? How would
> you approach debugging this problem?
>
>
> —Rob
>
> --
> You received this message because you are subscribed to the Google Groups
> "North West Ruby User Group (NWRUG)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nwrug-members+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/nwrug-members/eb3ea539-eee2-49ce-a378-e9eb6e74ccb5n%40googlegroups.com
> <https://groups.google.com/d/msgid/nwrug-members/eb3ea539-eee2-49ce-a378-e9eb6e74ccb5n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"North West Ruby User Group (NWRUG)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nwrug-members+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/nwrug-members/CAN_%2BVLWJyeTWKr%2B1eX9DzMzgXkM%2BLuo3zVjs0ijm%2BVPYKv4h5Q%40mail.gmail.com.
  • [NWRUG] Help With S... 'Rob Whittaker' via North West Ruby User Group (NWRUG)
    • Re: [NWRUG] He... Lee Hambley
    • Re: [NWRUG] He... Tekin Süleyman
      • Re: [NWRUG... 'Rob Whittaker' via North West Ruby User Group (NWRUG)
        • Re: [N... Will Jessop
          • Re... 'Rob Whittaker' via North West Ruby User Group (NWRUG)
            • ... Lee Hambley
              • ... 'Rob Whittaker' via North West Ruby User Group (NWRUG)
                • ... Will Jessop

Reply via email to