Re: Timeout callback

[Christopher Bailey <chris@cobaltedge.com>]

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@yhbt.net> wrote:
>
> Alex Sharp <ajsharp@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@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
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying