4 ms·

Anyone know if puma would be susceptible to the same bug or if it’s unicorn specific?

• jakswa 6y ago
  This is what I'm going to be digging for later... I'm wondering if puma also shares `env` objects across requests.
  • Freaky 6y ago
    Each server does share a "proto env" object, but it is duplicated for each Client: https://github.com/puma/puma/blob/0cc3f7d71d1550dfa8f545ece8da03a696b47be5/lib/puma/client.rb#L53 https://github.com/puma/puma/blob/0cc3f7d71d1550dfa8f545ece8... and Client objects are not reused: https://github.com/puma/puma/blob/0cc3f7d71d1550dfa8f545ece8da03a696b47be5/lib/puma/server.rb#L337 https://github.com/puma/puma/blob/0cc3f7d71d1550dfa8f545ece8...
• rantwasp 6y ago
  nope. puma does the right thing. this is exactly what i looked at when i saw unicorn in the article
  • ksec 6y ago
    I thought Github at one point looked at Puma and decided not to switch over. I wonder if they will reconsider that now.
    • rantwasp 6y ago
      to be fair, switching over is probably non-trivial and/or risky
• vemv 6y ago
  It would not trigger the same bug. But since it's a multi-threaded server, it will exercise arbitrary code (Rails core, your app, depended-on gems) in a concurrent manner. This can unmask race conditions that wouldn't manifest themselves under a single-threaded environment. ...that's been my experience with Puma - brilliant server in itself, somewhat risky approach when considering the Ruby ecosystem.