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
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
