VTC for connect_timeout?

[Federico Schwindt]

Hi,

Catching up with my email I came across your post.

The problem with your test is that while you're delaying the accept(), the
connection is not refused (the socket is in listen state) so you are
actually exercising the read timeout (first_byte_timeout).

You could use $(bad_ip} to test the connection timeout, that'd work.

On Sun, Nov 15, 2015 at 5:58 PM, Geoff Simmons <geoff at uplex.de> wrote:

> Hello all,
>
> I noticed that there is no test case for backend connect_timeout among
> the Varnish *.vtc's, so I tried to cook one up for a VMOD, but I can't
> seem to get a backend connection to fail due to the timeout when I think
> it should.
>
> The attached VTC just uses standard Varnish, and doesn't pass. I can't
> see what could be wrong about VTCP_connect(), so I assume that my
> reasoning about the test case must be flawed.
>
> The first request gets "Connection: close" from the backend, and I can
> see BackendClose in the log.
>
> Then the client sends the second request:
>
> **   c1    0.6 === txreq
> **** c1    0.6 txreq| GET / HTTP/1.1\r\n
> **** c1    0.6 txreq| \r\n
> **   c1    0.6 === rxresp
>
> But the backend delays 1.5 seconds, which is longer than
> connect_timeout, before accepting again:
>
> **   s1    0.6 === delay 1.5
> ***  s1    0.6 delaying 1.5 second(s)
> [...]
> **   s1    2.1 === accept
> **** s1    2.1 Accepting
> ***  s1    2.1 Accepted socket fd is 4
> **   s1    2.1 === rxreq
>
> So I thought the timeout should elapse and the response should be 503,
> but it's 200, no failure.
>
> How am I getting this wrong?
>
>
> Thanks,
> Geoff
> --
> ** * * UPLEX - Nils Goroll Systemoptimierung
>
> Scheffelstraße 32
> 22301 Hamburg
>
> Tel +49 40 2880 5731
> Mob +49 176 636 90917
> Fax +49 40 42949753
>
> http://uplex.de
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20151130/d6982548/attachment.html>