Hi All, any thoughts on this one?
Regards, Sven -----Ursprüngliche Nachricht----- Von: Sven Buesing Gesendet: Mittwoch, 19. September 2018 18:29 An: 'haproxy@formilux.org' Betreff: Client Timeout - undeterministic behaviour with tcp frontends Hi All, I think we stumbled over a bug in haproxy 1.8.3 regarding "timeout client" and tcp frontends. We are using the following version of haproxy: HA-Proxy version 1.8.3-205f675 2017/12/30 Copyright 2000-2017 Willy Tarreau <wi...@haproxy.org> We have quite a complex setup, as we use a tcp listener for ssl termination which forwards the requests to another internal listener via socket where the decision for ecc or rsa certificates is made. After that the request is getting forwarded to an http mode frontend, which then decides which backend to use. Our default "timeout client" is set to 18s. Default "timeout server" is 5m. Now comes our problem. A client connects to our tcp listener; ssl termination etc. went well and the request is submitted to our backend server. After that the backend is computing which takes more than 18s. Sometimes it's about 20s, sometimes it's below 18s. However if we consistently create a request which response (ttfb) needs more than 18s we can observe a quite undeterministic behaviour. 3 out of 10 of those requests get terminated and the browser shows ERR:EMPTY_RESPONSE. If we observe the network traffic we can see that the tcp session is closed by the loadbalancer (haproxy). We assume it's haproxy, because setting the "timeout client" on the tcp listener to higher values correctly prevents this from happening. The unusual part is, that this behaviour is only reproducible in about 30% of requests and the documentation states, that "timeout client" should only apply to inactivity when the client is expected to acknowledge or send data, which is not the case here as the client already send it's full request and is waiting fort he response. Has anyone already stumbled across this problem, or can explain what the problem could be here? Regards, Sven
