What's does pool_max_idle_per_host do?

[morrisonlevi]

The documentation for pool_max_idle_per_host on the builder says:

Sets the maximum idle connection per host allowed in the pool.

I'm still not sure what this actually does though. For instance, what if I set it to 0? What does that mean?

I'm asking because I recently hit cases where every 2nd request to the same host would have a broken pipe. Searching around suggested that pool_max_idle_per_host(0) could fix it, and it seems to do the trick. However, I'm not sure why. Does this mean connections aren't pooled at all when set to 0? How is this different from making a new client on every request? Are there any downsides you can think of to setting this?

[seanmonstar]

It configures the maximum idle connections that can be kept per host. So setting it to 0 will make it so no connections are kept idle, and so thus none can be reused.

I wouldn't normally recommend disabling keep-alive (essentially), as that hurts performance and resources. It might be that the server has a certain amount of time it will keep the connection alive, in which case you could instead set the pool_idle_timeout to a little shorter than that. But if the server can't do it... 🤷

[morrisonlevi]

Clients in other languages are successfully using keep-alive with this server, but it seems Reqwest + hyper is somehow different. I'll keep digging through strace logs. Is there anything else you'd recommend for debugging it?

[morrisonlevi]

I sometimes get this error instead:

connection closed before message completed

Still haven't figured out what the core issue is.

[seanmonstar]

connection closed before message completed

That error happens when the client picks a connection from the pool, sends a request, and then receives a socket closure meaning the server won't be sending anything else. The pool already monitors the connection for a closure while sitting idle. So, usually, I've found this is either a) a server is closing the connection rather quickly after sending the first response, but not before the client tries to send a second request, or b) there is an inherent race of picking an idle connection that just happened to be closed on the server at the same time, and due to latency we don't know it until the request has been written.