On Sat, May 9, 2015 at 1:03 AM, Eric Wong <e...@80x24.org> wrote: > "Lin Jen-Shin (godfat)" <god...@godfat.org> wrote: > Ugh, I guess since it happened in a thread, the error message got > swallowed unless you were running in $DEBUG.
I like the idea of setting $DEBUG, however it's too noisy given current state :( See how many messages got printed with this: $ ruby -dS gem list > /dev/null > Loading code after the server is ready and serving requests is a bad > idea. It leads to really nasty thread-safety problems as well as > invalidating the method/constant caches. Yeah, I did that in the first place because I don't want my runtime being polluted with those methods from activesupport. However at some point we just need to use some stuffs from activesupport in some cases. Therefore I put those requires in that particular method. Only a few cases it would be used, that's what I was thinking. But eventually it got triggered from some unexpected places. Now it's removed and replaced with codes copied directly from activesupport. No activesupport and requires need now. >> When this happened, the client just hanged forever with yahns. >> Is there something we can do about this? Would yahns respawn >> a new worker thread? Can we close the socket when this happen? > > It's unfortunately difficult to detect thread death from ruby (no > SIGCHLD handler unlike for processes) besides polling Thread#join > > We had this issue in ruby-core a few years back, but apparently > it was forgotten/ignored by matz. Care to chime in? > https://bugs.ruby-lang.org/issues/6647 I just sent a few characters, hope that would speed up the process. >> I am aware that yahns is *extremely sensitive to fatal bugs in the >> applications it hosts*, so I am just curious. >> >> For reference, Puma would immediately close the socket without >> sending anything, and Unicorn would log the error backtrace and >> kill the worker (If I read it correctly). >> >> In this case, Unicorn helped me figure out what's happened. > > yahns can probably rescue Exception (or Object(!) like puma) > and then log + abort the entire process. I think rescuing Object is misleading. AFAIK, we cannot raise an instance which is not a kind of Exception. I learned that rescuing Exception is a bad idea because like signal handling and some other stuffs are also using Exception to communicate, and of course we won't want to interfere. However for a worker thread, I guess that might be ok? Cheers,
