Connection timeouts when Client lives a long time

[mathstuf]

We have a Client object which we persist for a long time (ideal would be "forever") which has sporadic usage over the course of a day. After a longer period of being idle, we sometimes see connections immediately replied with a TCP RST packet causing a failure. Is it possible to manually flush the connection queue, remove the Keep-Alive header on the requests, or otherwise reset the connection pool after some timeout to avoid issues?

Cc: @bradking

[seanmonstar]

Currently, there isn't a good way to do this using hyper 0.10. Checking the status of a socket requires trying a read or write, and with blocking IO, that could mean that it just blocks the thread forever, since the server didn't have a request to reply to.

However, the pool in async hyper (soon to be 0.11) does have timeouts, along with cleaning out sockets that receive TCP FIN, so this should be easier to solve then.

Once hyper 0.11 is released, reqwest will make use of it internally, and keep the blocking API. This means we can take advantage of better timeouts.

[mathstuf]

OK, so just creating new Client instances for each call is the best way until hyper 0.11 is used then?

[jbg]

An alternative that would allow you to use keep-alives for multiple requests within a short time of each other (avoiding the overhead of creating a Client and connecting to the server separately for every single request) would be to catch the error and retry just the request that fails.

[mathstuf]

The problem there is detecting legitimate connection resets versus resets from Client living too long.

[seanmonstar]

I've actually implemented a pretty solid solution into master, the fix shall be part of the v0.7 release. Each socket is checked using the same technique curl uses, by using select on the socket with a 0 timeout, so it should instantly check if the socket is already known to be dead.

It's of course still possible for a server to close the connection inbetween reqwest checking the local socket status and finally sending a request, but it should be much much less frequent.