Hi Cyril, I have created a very simple config to reproduce this. This config always read timesout in 9 seconds.
To create a timingout service, you can just use nc as follows nc -l 8888 -------------------- Haproxy Conf: -------------------- global pidfile /var/run/haproxy/l1_webui.pid log /dev/log local0 info alert log-tag haproxy_l1_webui user haproxy group haproxy chroot /var/lib/haproxy lua-load /home/sshetty/l1_rework_unit_test/gds.lua defaults mode tcp log global option httplog timeout client 300s # Client and server timeout must match the longest timeout server 300s # time we may wait for a response from the server. timeout queue 30s # Don't queue requests too long if saturated. timeout connect 4s # There's no reason to change this one. timeout http-request 5s maxconn 20000 retries 2 option redispatch option dontlognull option http-server-close frontend http_l1_webui bind-process 1 # http front end since some webdav and image requests are made over http, send as is to L1 mode http option httplog bind 0.0.0.0:80 http-request lua.get_proxy default_backend apache_l1 backend apache_l1 mode http -------------- Lua code: -------------- gds_host="127.0.0.1" gds_port=8888 function get_from_gds(key) local sock = core.tcp() -- Connect timeout after patch sock:settimeout(3) local result = DOMAIN_NOT_FOUND local status, error = sock:connect(gds_host, gds_port) if not status then core.Alert("Error in connecting:" .. key .. ":" .. error) return "Error", "Error: " .. error end sock:settimeout(2) sock:send(key .. "\r\n") while true do local s, status, partial = sock:receive("*l") if s == "END" then break end result = s end sock:close() core.Alert("Returning from GDS:" .. key .. ":" .. result) return result end function protected_get_from_gds(key) local status, result = pcall(get_from_gds, key) if not status then core.Alert("Error in getting key: " .. key .. ":" .. result) return "Error" end return result end function get_proxy(txn) local time = os.time() local host = txn.sf:req_fhdr("host") local fqn = host host = host:gsub("%..*", "") core.Alert("Getting proxy for domain:" .. host .. ", connecting to " .. gds_host .. ":" .. gds_port) local result = protected_get_from_gds("get apache." .. host) core.Alert("Received Response:" .. host .. ":" .. result .. "<") end core.register_action("get_proxy", { "http-req" }, get_proxy) ------------------------------------------------ Sample log timing out in 9 seconds ------------------------------------------------ Aug 12 16:16:12 l1ratelimit01 haproxy_l1_webui[23965]: Getting proxy for domain:qaus16march2017, connecting to 127.0.0.1:8888 Aug 12 16:16:21 l1ratelimit01 haproxy_l1_webui[23965]: Error in getting key: get apache.qaus16march2017:execution timeout Aug 12 16:16:21 l1ratelimit01 haproxy_l1_webui[23965]: Received Response:qaus16march2017:Error< Aug 12 16:16:21 l1ratelimit01 haproxy_l1_webui[23965]: 127.0.0.1:39304 [12/Aug/2018:16:16:12.164] http_l1_webui apache_l1/<NOSRV> 9026/-1/-1/-1/9026 503 212 - - SC-- 0/0/0/0/0 0/0 "GET /123 HTTP/1.1" On Sun, Aug 12, 2018 at 4:02 PM, Cyril Bonté <cyril.bo...@free.fr> wrote: > Hi, > > Le 12/08/2018 à 08:41, Sachin Shetty a écrit : > >> Hi Cyril, >> >> Any idea how I can deterministically set the readtimeout as well? >> > > Well, currently I can't reproduce this at all. Can you provide some more > details ? or even a full configuration providing the test case ? > From the tests I've made, read and write timeouts work as expected. > > > >> Thanks >> Sachin >> >> On Fri, Jul 27, 2018 at 1:23 PM, Sachin Shetty <sshe...@egnyte.com >> <mailto:sshe...@egnyte.com>> wrote: >> >> Thankyou Cyril, your patch fixed the connect issue. >> >> Read timeout still seems a bit weird though, at settimeout(1), >> readtimeout kicks in at about 4 seconds, and at settimeout(2), >> readtimeout kicks in at about 8 seconds. >> >> is that expected? I couldn't find read timeout explicitly set >> anywhere in the same source file. >> >> Thanks >> Sachin >> >> On Fri, Jul 27, 2018 at 5:18 AM, Cyril Bonté <cyril.bo...@free.fr >> <mailto:cyril.bo...@free.fr>> wrote: >> >> Hi, >> >> Le 26/07/2018 à 19:54, Sachin Shetty a écrit : >> >> Hi, >> >> We are using a http-req lua action to dynamically set some >> app specific metadata headers. The lua handler connects to a >> upstream memcache like service over tcp to fetch additional >> metadata. >> >> Functionally everything works ok, but I am seeing that >> socket.settimeout has no effect. Irrespective of what I set >> in settimeout if the upstream service is unreachable, >> connect always timesout at 5 seconds, and read timeout >> around 10 seconds. It seems like settimeout has no effect >> and it always picks defaults of 5 seconds for connect >> timeout and 10 seconds for read timeout. >> >> >> For the connect timeout, it seems this is a hardcoded default >> value in src/hlua.c: >> socket_proxy.timeout.connect = 5000; /* By default the >> timeout connection is 5s. */ >> >> If it's possible, can you try the patch attached (for the 1.7.x >> branch) ? But please don't use it in production yet ;-) >> >> >> Haproxy conf call: >> >> http-request lua.get_proxy >> >> Lua code sample: >> >> function get_proxy(txn) >> local sock = core.tcp() >> sock:settimeout(2) >> status, error = sock:connect(gds_host, gds_port) >> if not status then >> core.Alert("1 Error in connecting:" .. key .. ":" >> .. error) >> return result, "Error: " .. error >> end >> sock:send(key .. "\r\n") >> .... >> .... >> >> >> core.register_action("get_proxy", { "http-req" }, get_proxy) >> >> Haproxy version: >> >> HA-Proxy version 1.7.8 2017/07/07 >> Copyright 2000-2017 Willy Tarreau <wi...@haproxy.org >> <mailto:wi...@haproxy.org> <mailto:wi...@haproxy.org >> >> <mailto:wi...@haproxy.org>>> >> >> >> Build options : >> TARGET = linux2628 >> CPU = generic >> CC = gcc >> CFLAGS = -O2 -g -fno-strict-aliasing >> -Wdeclaration-after-statement -fwrapv -DTCP_USER_TIMEOUT=18 >> OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 >> USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 >> >> Default settings : >> maxconn = 2000, bufsize = 16384, maxrewrite = 1024, >> maxpollevents = 200 >> >> Encrypted password support via crypt(3): yes >> Built with zlib version : 1.2.7 >> Running on zlib version : 1.2.7 >> Compression algorithms supported : identity("identity"), >> deflate("deflate"), raw-deflate("deflate"), gzip("gzip") >> Built with OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013 >> Running on OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013 >> OpenSSL library supports TLS extensions : yes >> OpenSSL library supports SNI : yes >> OpenSSL library supports prefer-server-ciphers : yes >> Built with PCRE version : 8.32 2012-11-30 >> Running on PCRE version : 8.32 2012-11-30 >> PCRE library supports JIT : no (USE_PCRE_JIT not set) >> Built with Lua version : Lua 5.3.2 >> Built with transparent proxy support using: IP_TRANSPARENT >> IPV6_TRANSPARENT IP_FREEBIND >> >> Available polling systems : >> epoll : pref=300, test result OK >> poll : pref=200, test result OK >> select : pref=150, test result OK >> Total: 3 (3 usable), will use epoll. >> >> Available filters : >> [COMP] compression >> [TRACE] trace >> [SPOE] spoe >> >> >> >> Thanks >> Sachin >> >> >> >> -- Cyril Bonté >> >> >> >> > > -- > Cyril Bonté >