Open yuriy-odonnell-epic opened 2 months ago
Looks like pool_timer()
should be used to actually trigger the idle interval checking (just timer()
is not enough). However, it does not kick in until the 2nd iteration of the loop, which means that if the client only performs a single request, the idle connection lingers.
I've updated the initial bug report to reflect this.
Interesting. I can't remember why, maybe it was so a task wasn't started if the client never sent a request? Might be a simple fix, have you tried that modification?
It looks like dropping resp
returns the connection to the pool and triggers the idle trimming task.
Honestly, it might be reasonable to maintain the connection until response future is dropped. It may be just worth adding a small note to the docs, for posterity. In real applications, I don't expect response futures to stick around indefinitely.
I'm happy to close the issue, if you deem this "working as designed".
Version Latest hyper (1.3.1) & hyper-util (0.1.3)
Platform Windows11
Description The issue reproduces in a modified hyper-util client example:
Client is configured with idle timeout of 1 sec and the example performs several requests with 5 second delay. The expectation is that a connection should be dropped from the pool after 1 second during each loop iteration. In practice, the connections start to get dropped only on the second iteration of the loop.
In a real application, this results in connections lingering until a new request is issued.