504 timeout

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

504 timeout

Larry Martell
I have a django app using nginx and uwsgi. There can be cases when a
request from a user does not come back from the db for 15-20 minutes.
This is expected as it's calling a stored proc that does a lot and
this is an internal app. Issue is that after some amount of time I get
a 504 timeout error - but it's not always the same time - sometimes 10
minutes, sometimes 15, sometimes 16. My config file has:

uwsgi_read_timeout 60m;
uwsgi_send_timeout 60m;
client_body_timeout 60m;

Are there any other settings I need to set to avoid the 504?
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: 504 timeout

Larry Martell
On Tue, May 12, 2020 at 11:33 AM Larry Martell <[hidden email]> wrote:

>
> I have a django app using nginx and uwsgi. There can be cases when a
> request from a user does not come back from the db for 15-20 minutes.
> This is expected as it's calling a stored proc that does a lot and
> this is an internal app. Issue is that after some amount of time I get
> a 504 timeout error - but it's not always the same time - sometimes 10
> minutes, sometimes 15, sometimes 16. My config file has:
>
> uwsgi_read_timeout 60m;
> uwsgi_send_timeout 60m;
> client_body_timeout 60m;
>
> Are there any other settings I need to set to avoid the 504?

Also just tried adding these to the global settings:

proxy_connect_timeout   60m;
proxy_send_timeout      60m;
proxy_read_timeout      60m;

But no joy.
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: 504 timeout

Norman Gray
In reply to this post by Larry Martell

Larry, hello.

On 12 May 2020, at 16:33, Larry Martell wrote:

> There can be cases when a
> request from a user does not come back from the db for 15-20 minutes.
> This is expected as it's calling a stored proc that does a lot and
> this is an internal app.

(open-parenthesis

This isn't an answer to your question, but that sort of interaction does
go pretty much against the grain of the HTTP protocol, and the 'REST'
interaction style that it led to, so there may be architectural reasons,
rather than merely implementation ones, for this application to have
further problems, further down the line.  If a proxy were ever to be
involved, you'd acquire a separate set of headaches.

There is an HTTP response code '202 Accepted' (which is a success code,
of course), glossed as 'The request has been accepted for processing,
but the processing has not been completed' -- details below.  That's
pretty much intended for just this sort of interaction.  The idea is
that the server would respond promptly with 202, perhaps with a
retry-after header, and the client knows to try again later, possibly
repeatedly, until it gets either a 200 or a 4xx.

Of course, this would require changes at server and client end, so it's
not immediately helpful.

Good luck,

Norman

close-parenthesis)



The text of RFC 7231 says:

6.3.3.  202 Accepted

    The 202 (Accepted) status code indicates that the request has been
    accepted for processing, but the processing has not been completed.
    The request might or might not eventually be acted upon, as it might
    be disallowed when processing actually takes place.  There is no
    facility in HTTP for re-sending a status code from an asynchronous
    operation.

    The 202 response is intentionally noncommittal.  Its purpose is to
    allow a server to accept a request for some other process (perhaps a
    batch-oriented process that is only run once per day) without
    requiring that the user agent's connection to the server persist
    until the process is completed.  The representation sent with this
    response ought to describe the request's current status and point to
    (or embed) a status monitor that can provide the user with an
    estimate of when the request will be fulfilled.

--
Norman Gray  :  https://nxg.me.uk
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: 504 timeout

Larry Martell
On Tue, May 12, 2020 at 12:55 PM Norman Gray <[hidden email]> wrote:

>
>
> Larry, hello.
>
> On 12 May 2020, at 16:33, Larry Martell wrote:
>
> > There can be cases when a
> > request from a user does not come back from the db for 15-20 minutes.
> > This is expected as it's calling a stored proc that does a lot and
> > this is an internal app.
>
> (open-parenthesis
>
> This isn't an answer to your question, but that sort of interaction does
> go pretty much against the grain of the HTTP protocol, and the 'REST'
> interaction style that it led to, so there may be architectural reasons,
> rather than merely implementation ones, for this application to have
> further problems, further down the line.  If a proxy were ever to be
> involved, you'd acquire a separate set of headaches.
>
> There is an HTTP response code '202 Accepted' (which is a success code,
> of course), glossed as 'The request has been accepted for processing,
> but the processing has not been completed' -- details below.  That's
> pretty much intended for just this sort of interaction.  The idea is
> that the server would respond promptly with 202, perhaps with a
> retry-after header, and the client knows to try again later, possibly
> repeatedly, until it gets either a 200 or a 4xx.
>
> Of course, this would require changes at server and client end, so it's
> not immediately helpful.
>
> Good luck,
>
> Norman
>
> close-parenthesis)
>
>
>
> The text of RFC 7231 says:
>
> 6.3.3.  202 Accepted
>
>     The 202 (Accepted) status code indicates that the request has been
>     accepted for processing, but the processing has not been completed.
>     The request might or might not eventually be acted upon, as it might
>     be disallowed when processing actually takes place.  There is no
>     facility in HTTP for re-sending a status code from an asynchronous
>     operation.
>
>     The 202 response is intentionally noncommittal.  Its purpose is to
>     allow a server to accept a request for some other process (perhaps a
>     batch-oriented process that is only run once per day) without
>     requiring that the user agent's connection to the server persist
>     until the process is completed.  The representation sent with this
>     response ought to describe the request's current status and point to
>     (or embed) a status monitor that can provide the user with an
>     estimate of when the request will be fulfilled.

Thanks for the reply. Yes, I knew someone would say this ;-). To
clarify, this is an async ajax call (so I am surprised it gets a
timeout), and this is just an internal connivence function for the
DBAs to run a pipeline of stored procs. In any case, I should have
mentioned we are running at AWS using the Elastic Load Balancer, and
the timeout there is what I was hitting. Once that was increased I no
longer get the 504.
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx