[Glass] How to deal with timeouts, fastcgi and what is the expected behavior?

[Dale Henrichs]

On Fri, Jul 18, 2014 at 7:36 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

> Hi guys,
>
> I have a strange situation with timeouts under nginx/fastCGI and I am not
> sure what is expected. I am executing a Seaside WATask, where one of its
> method takes (for sure) more then the timeout of nginx/fastCGI. My piece of
> nginx setup is something like this:
>
> location @seasidemariano {
>  include fastcgi_params;
> fastcgi_param REQUEST_URI $uri?$args;
>   fastcgi_pass seasidemariano;
>  fastcgi_connect_timeout      180;
>       fastcgi_send_timeout         180;
>       fastcgi_read_timeout         180;
>
>   fastcgi_next_upstream error invalid_header timeout http_500;
> }
>
>
> So...as you can see I have a timeout of 180 and I tell to go to the next
> upstream (gem) in any error, including timeout. Now...say I have this
> method being executed and it takes more than 180 seconds. What happens is
> that the user gets a Nginx 504 Gateway Time-out in the browser. Ok. But...
> I have some questions:
>
> 1) what happens with that gem that was executing the task (the one that
> took more than 180)? is the execution finished even if the nginx give a
> timeout and pass the reuqest to the next gem? Or the gem execution is
> aborted?  Why I ask? Because...I out a log to a file inside my method...and
> it looks like if the method were called 3 times rather than 1. And from a
> domain point of view.... it is not good that such a method is executed 3
> times...
>

It does sound like nginx is redispatching the http request on timeout...

>
> 2) If I put a larger timeout...say 1500 ... it works correct..the method
> is executed only once, no timeout. Same if I use swazoo. So it is something
> to do with the timeouts and fastCGI for sure.
>

In general I try to avoid timeouts ... it seems that timeouts fire more
often because the system is slow than for any other reason and the standard
answer: increase the timeout ...

So I guess I would wonder why the operation is taking so long ... if the
operation is slow because the system is overloaded, then a longer timeout
_is_ called for, but then what is a good value for the timeout ..

I guess the real question to ask is what is the purpose of the timeout?

You might want the gem itself to decide to terminate a request if it is
"taking too long" then you don't need  a timeout at the nginx level?


> 3) 3 times...why? It seems because I have 3 gems. I did an experiment, and
> I set only 2 gems to nginx fastcgi. And yes, the method was executed only 2
> times rather than 3.
>

It does sound like nginx is sending the request again upon a timeout ...
could that be?

>
> So....how do people normally deal with this? Of course, the immediate
> workaround seems to increase the timeout...but it seems risky to me,
> thinking that if for some reason (like GC running or whatever) one
> particular request takes more than the timeout, then my "backend code"
> could be run more than once...
>
> Thanks in advance,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140718/1936ff9b/attachment.html>