AW: Client Timeout - undeterministic behaviour with tcp frontends

2018-10-26 Thread Sven Buesing
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



Client Timeout - undeterministic behaviour with tcp frontends

2018-09-19 Thread Sven Buesing
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