cowboy
cowboy copied to clipboard
ninenines
Allowing download time to not be considered as "idle"
Currently, the time required to send a response is counted as idle, and as a result if it takes more than one minute (by default) the idle timeout kills the request. We've got a use case where the response is generated, and can potentially take multiple minutes to download (streamed, so it's continually producing data) and there isn't actually a fixed upper bound on the amount of time the response will take to send.
There'll be a pull request with our approach to allowing this shortly; it preserves the existing behavior but adds a new protocol option to the http and http2 backends which makes the idle timer get reset on sends.
We just ran into this exact same issue and even went so far as to move to using streaming to keep the connection "active". By any chance has this been addressed outside the context of this PR in the year-ish since it's been submitted?
You can set the idle_timeout option on a per-request basis. You have an option here: https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.cast/#_examples
I haven't had time to consider the PR yet. My focus in the coming week or two will be Gun.
Does the idle_timeout logic that is applied per-request behave differently?
The issue here is that the global idle_timeout isn't correctly tracking ongoing network activity, so a large download that is moving data but has no additional requests associated with it is incorrectly counted as idle and gets incorrectly closed.
No that's intended. The challenge here is that there can be responses that send tiny bits of data very rarely and because of the TCP half-open problem we may not notice the connection being gone for a very long time. These tend to be using SSE which has mechanisms for resuming. For just pushing data, this is a different matter and I agree that there's some issues with the current approach. You can in that case either disable idle_timeout (set infinity for this request) or make use of the fact that when you send idle_timeout it will reset the timer. You could set idle_timeout every so often to keep the mechanism working but still prolong the duration when you have new data coming in.
PR was merged, closing, thanks! New option is reset_idle_timeout_on_send and must be set to true to apply. Default behavior will probably be changed in the next major release because it only makes sense when paired with other improvements made recently.