504 timeout

[Larry Martell]

On Tue, May 12, 2020 at 12:55 PM Norman Gray <gray at nxg.name> 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.