I seem to have found the cause.
If I specify cache for that backend then the 'timeout tunnel' no longer
works, if I comment out caching then the timeout applies.
Is this expected behaviour?
I'm using the following in my backend:
--
http-request cache-use cache01
http-response cache-store cache01
--
And this is my Cache config
--
cache cache01
total-max-size 256
max-age 60
--
Regards
Rabie
-----Original Message-----
From: Rabie Van Der Merwe <rabie.vanderme...@appcentrix.co.za>
Sent: Monday, 30 September 2019 15:53
To: haproxy@formilux.org
Subject: RE: WebSocket connection upgrade not using tunnel timeout
Small correction I'm still on 1.8.20.
I have since managed to do a tcpdump on the HAProxy box for the backend
connection to the web/socket server.
I can see that HAProxy forwards the connection upgrade request, the
connection is upgraded and I can see websocket traffic (viewing dump in
WireShark).
The connection still times out based on the server timeout and not the
tunnel timeout setting.
How can I debug this on the HAProxy side?
R
-----Original Message-----
From: Rabie Van Der Merwe <rabie.vanderme...@appcentrix.co.za>
Sent: Friday, 27 September 2019 12:14
To: 'haproxy@formilux.org' <haproxy@formilux.org>
Subject: WebSocket connection upgrade not using tunnel timeout
Hi,
I'm on 1.8.21 and have a webapp that uses websockets.
The application works, but the app complains very quickly that the
connection to the server has been lost.
On the second line we get "sD--" Which is:
sD The server did not send nor acknowledge any data for as long as
the "timeout server" setting during the data phase. This is often caused by
too short timeouts on L4 equipments before the server (firewalls,
load-balancers, .), as well as keep-alive sessions maintained between the
client and the server expiring first on haproxy.
I have added a tunnel timeout statement, however I'm unsure if haproxy is
aware of this and if it is why is it still timing out on server timeout? I
have noticed that I can increase the server timeout which would delay the
disconnect, however this is not a solution.
Any suggestions? How can I check to see if haproxy 'sees' the connection
upgrade?
--snip--
Sep 27 11:43:52 localhost haproxy[22504]: 1.2.3.4:50137
[27/Sep/2019:11:43:52.201] mainhttps~ smartcm01/apxblvcm01 0/0/0/7/7 200
1217 - - ---- 9/9/1/2/0 0/0 {|} "GET /nui/images/settings.gif HTTP/1.1"
Sep 27 11:44:51 localhost haproxy[22504]: 1.2.3.4:48390
[27/Sep/2019:11:43:50.389] mainhttps~ smartcm01/apxblvcm01 0/0/1/7/61486
101 606 - - sD-- 3/3/0/0/0 0/0 {|} "GET /rest/events HTTP/1.1"
Sep 27 11:51:25 localhost haproxy[22504]: 1.2.3.4:22229
[27/Sep/2019:11:51:25.423] mainhttps~ smartcm01/apxblvcm01 0/0/2/7/9 304
100 - - ---- 8/8/0/1/0 0/0 {|} "GET / HTTP/1.1"
--snip--
Regards
Rabie van der Merwe
