504 gateway timeouts

[Peter Booth]

Wade, 

This reminds me of something I once saw with an application that was making web service requests to FedEx. So are you saying that the response times are bimodal? That you either get a remote response within a few seconds or the request takes more than 60 seconds, and that you have no 20sec,30sec,40sec requests?

And, if so, do those 60+ sec requests ever get a healthy response?


Sent from my iPhone

> On Jan 9, 2018, at 1:52 PM, Wade Girard <wade.girard at gmail.com> wrote:
> 
> Hi nginx group,
> 
> If anyone has any ides on this, they would be appreciated.
> 
> Thanks
> 
>> On Fri, Jan 5, 2018 at 6:28 AM, Wade Girard <wade.girard at gmail.com> wrote:
>> Hi Peter,
>> 
>> Thank You.
>> 
>> In my servlet I am making https requests to third party vendors to get data from them. The requests typically take 4~5 seconds, but every now any then one of the requests will take more than 60 seconds. So the connection from the client to nginx to tomcat will remain open, and at 60 seconds nginx is terminating the request to tomcat, even though the connection from the third party server to tomcat is still open.
>> 
>> I am also working with the third party vendor to have them see why their connections sometimes take more than 60 seconds.
>> 
>> Through googling I discovered that adding the settings proxy_send_timeout, proxy_read_timeout, proxy_connection_timeout, etc... to my location definition in my conf file could change the timeout to be different (higher) than the apparent default 60 second timeout. I use a Mac for development. I added these to my local conf file, and added the long connection request to test if the settings worked. They did. However they do not have the same effect for nginx installed on my production Ubuntu 16.x servers. I did not realize that these settings were limited by the OS that nginx is installed on. Are there are similar settings that will work for the Ubuntu 16.x OS to achieve the same result?
>> 
>> Wade
>> 
>>> On Fri, Jan 5, 2018 at 1:33 AM, Peter Booth <peter_booth at me.com> wrote:
>>> Wade,
>>> 
>>> I think that you are asking “hey why isn’t nginx behaving identically on MacOS and Linux when create a servlet that invokes Thread.sleep(300000) before it returns a response?.”
>>> 
>>> Am I reading you correctly?
>>> 
>>> A flippant response would be to say: “because OS/X and Linux are different OSes that behave differently”
>>> 
>>> It would probably help us if you explained a little more about your test, why the sleep is there and what your goals are?
>>> 
>>> 
>>> Peter
>>> 
>>> 
>>>> On Jan 4, 2018, at 11:45 PM, Wade Girard <wade.girard at gmail.com> wrote:
>>>> 
>>>> I am not sure what is meant by this or what action you are asking me to take. The settings, when added to nginx conf file on Mac OS server and nginx reloaded take effect immediately and work as expected, the same settings when added to nginx conf file on Ubuntu and nginx reloaded have no effect at all. What steps can I take to have the proxy in nginx honor these timeouts, or what other settings/actions can I take to make this work?
>>>> 
>>>> Thanks
>>>> 
>>>>> On Thu, Jan 4, 2018 at 7:46 PM, Zhang Chao <zchao1995 at gmail.com> wrote:
>>>>> > The version that is on the ubuntu servers was 1.10.xx. I just updated it to 
>>>>> >
>>>>> > nginx version: nginx/1.13.8
>>>>> >
>>>>> > And I am still having the same issue.
>>>>> >
>>>>> > How do I "Try to flush out some output early on so that nginx will know that Tomcat is alive."
>>>>> >
>>>>> > The nginx and tomcat connection is working fine for all requests/responses that take less t
>>>>> 
>>>>> Maybe you can flush out the HTTP response headers quickly.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> nginx mailing list
>>>>> nginx at nginx.org
>>>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Wade Girard
>>>> c: 612.363.0902
>>>> _______________________________________________
>>>> nginx mailing list
>>>> nginx at nginx.org
>>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>> 
>>> 
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>> 
>> 
>> 
>> -- 
>> Wade Girard
>> c: 612.363.0902
> 
> 
> 
> -- 
> Wade Girard
> c: 612.363.0902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180109/1791c89b/attachment.html>