Timeout callback

Timeout callback

[Alex Sharp]

 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



_______________________________________________
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

Re: Timeout callback

[Eric Wong]

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

Re: Timeout callback

[Christopher Bailey]

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

Re: Timeout callback

[Alex Sharp]

Makes sense. Thanks for the explanation -- I'm pretty sure this exact topic has been discussed a few times on this list ;)

- Alex
_______________________________________________
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

Re: Timeout callback

[Alex Sharp]

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 


_______________________________________________
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