Would there be any support for a worker-level timeout callback, for workers that get killed by the master process for violating the Unicorn::Configurator.timeout setting? I''m thinking the method could be on the Unicorn::Configurator class, something like ".at_timeout_exit". My thinking here is I want to be able to invoke caller() and get a backtrace to figure out the code that''s resulting in timeouts. -- Alex Sharp github.com/ajsharp twitter.com/ajsharp alexjsharp.com
Alex Sharp <ajsharp at gmail.com> wrote:> Would there be any support for a worker-level timeout callback, for > workers that get killed by the master process for violating the > Unicorn::Configurator.timeout setting?Something like this /cannot/ be done right. The unicorn timeout uses SIGKILL because SIGKILL is a last resort and not catchable/blockable/trappable in user space. (SIGSTOP is in the same boat as SIGKILL).> I''m thinking the method could be on the Unicorn::Configurator class, > something like ".at_timeout_exit". My thinking here is I want to be > able to invoke caller() and get a backtrace to figure out the code > that''s resulting in timeouts.Getting a backtrace relies on Ruby being in a runnable state. If user space (and Ruby) is capable of accepting non-SIGKILL/SIGSTOP, you could already be using something along the lines of the Timeout module in Ruby stdlib, SystemTimeout, or the Rainbows::ThreadTimeout middleware. In other words, you can already use an application-level timeout (even around the entire app dispatch) if you could get a backtrace.
Alex, we were having problems with timeouts, and it killing our logs, making it near impossible to figure out what was causing the timeout, etc. We too looked into a solution within Unicorn, but as Eric explains, it''s not possible. What we wound up doing, which may or may not work for you, is to put an explicit Timeout wrapper around the code we knew caused this (we are lucky and knew a specific API call/controller action that was getting the timeouts). ?e.g. wrap with: ? Timeout::timeout(...) do This wound up actually being a far better solution for us, because our mobile clients that call this API timeout the HTTP request at 20 seconds anyway, so it was pointless to even get to 60. ?So, we now have a far better solution, one where we can time it out ourselves, handle the exception, and log the timeout/problem (e.g. we create a Zendesk ticket, etc.). ?Anyway, figured I''d mention that in case it could work in your case as well... On Sun, Sep 25, 2011 at 6:42 PM, Eric Wong <normalperson at yhbt.net> wrote:> > Alex Sharp <ajsharp at gmail.com> wrote: > > ?Would there be any support for a worker-level timeout callback, for > > ?workers that get killed by the master process for violating the > > ?Unicorn::Configurator.timeout setting? > > Something like this /cannot/ be done right. ?The unicorn timeout uses > SIGKILL because SIGKILL is a last resort and not > catchable/blockable/trappable in user space. ?(SIGSTOP is in the same > boat as SIGKILL). > > > I''m thinking the method could be on the Unicorn::Configurator class, > > something like ".at_timeout_exit". My thinking here is I want to be > > able to invoke caller() and get a backtrace to figure out the code > > that''s resulting in timeouts. > > Getting a backtrace relies on Ruby being in a runnable state. > If user space (and Ruby) is capable of accepting non-SIGKILL/SIGSTOP, > you could already be using something along the lines of the Timeout > module in Ruby stdlib, SystemTimeout, or the Rainbows::ThreadTimeout > middleware. > > In other words, you can already use an application-level timeout > (even around the entire app dispatch) if you could get a backtrace. > _______________________________________________ > Unicorn mailing list - mongrel-unicorn at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-unicorn > Do not quote signatures (like this one) or top post when replying-- Christopher Bailey Cobalt Edge LLC http://cobaltedge.com
Makes sense. Thanks for the explanation -- I''m pretty sure this exact topic has been discussed a few times on this list ;) - Alex
On Sunday, September 25, 2011 at 11:06 PM, Christopher Bailey wrote:> What we wound up doing, which may or may not work for you, is to put > an explicit Timeout wrapper around the code we knew caused this (we > are lucky and knew a specific API call/controller action that was > getting the timeouts). e.g. wrap with: > > Timeout::timeout(...) do > > This wound up actually being a far better solution for us, because our > mobile clients that call this API timeout the HTTP request at 20 > seconds anyway, so it was pointless to even get to 60. So, we now > have a far better solution, one where we can time it out ourselves, > handle the exception, and log the timeout/problem (e.g. we create a > Zendesk ticket, etc.). Anyway, figured I''d mention that in case it > could work in your case as well...Great, thanks for sharing. - Alex