On Tue, May 12, 2020 at 12:55 PM Norman Gray <gray@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.
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx