Hi Willy, The 60 second expire bug disappeared when I set the opiton http-buffer-request on. However after that we started seeing intermittent socket connection expired from our android clients. No matter what we set the expiration to this happens like every 10 minutes or so. The error lasts a while and then clients connect and everything goes back to normal. But the nature of the errors implies some kind of buffer gets filled up and haproxy stops receiving connections. This doesn't necessarily happen in high loads also. I've searched around the net for similar issues but couldn't find a solution. The problem is this connection expirations are not visible in haproxy logs. The service is an http service so option httplog is set. Do you know of any other way of catching this intermittent error and logging it somehow.
On Sun, Nov 19, 2017 at 9:56 AM Willy Tarreau <[email protected]> wrote: > On Sun, Nov 19, 2017 at 07:45:59AM +0100, Willy Tarreau wrote: > > On Thu, Nov 16, 2017 at 09:15:02PM +0500, ???? ??????? wrote: > > > Try > > > > > > proxy_buffering off; > > > proxy_request_buffering off; > > > > > > in nginx > > > > Good point, it's indeed possible that some slow clients are keeping > > application connections opened and that the default buffering in nginx > > hides it. > > > > It's also possible to do something similar within the limit of one buffer > > in haproxy by adding : > > > > option http-buffer-request > > > > Haproxy will then wait for either a full request or a full request > buffer. > > Buffers default to 16 kB so that should be enough here. > > I didn't notice that this one was already present in the original config. > > Also the fact that the application server closes after 60s is troubling, > because even a slow client shouldn't take 60s to upload 8kB of data, and > when option http-buffer-request is set, only full (or short enough) > requests are sent to the server. So it means that such requests expiring > after 60s were larger than a buffer and stopped in the middle, or were > complete and the server really failed. If there is a large count of such > errors, it's unlikely that it's caused by clients. > > Willy >
