On Tue, May 12, 2020 at 12:55 PM Norman Gray <[email protected]> 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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
