Add connect, read, and write timeouts to client

[sfackler]

[hjr3]

I am going to try get a PR up for this. There are two options for timers, but I am unsure of which is best for hyper. The tokio_timer crate is more accurate but uses a dedicated thread. The Timeout in tokio-core is less accurate but does not require the extra thread.

If I was making the decision, I would create a single tokio-timer Timer (1 dedicated thread), configure it properly and then use that for any timeout needs. Does anyone else have any opinions?

[seanmonstar]

hyper 0.11 didn't ship with these for a couple reasons:

• It's possible to have a rough overall timeout by using timeouts outside of hyper.
• I didn't want to pick a timer implementation that was different than the user, and then end up that multiple timer implementations were running.

Still, I realize it would be useful to have these in hyper, so let's explore!

• For anyone wanting it immediately, you can largely get most of it working externally. A "connect" timeout can be used by providing a custom Connect that wraps the HttpConnector and a Timeout. A "write" timeout (for a body) can be sort of hacked in by providing a custom Body stream. And a "read" timeout could be used by selecting on the FutureResponse, and/or the response body. I realize it's not super accurate, but it's there for the urgent.
• For the implementation in hyper, unless there the coarser timeouts are bad (it shouldn't be seconds off, just perhaps a few milliseconds if the timer isn't quite reached, and another loop of the Core would take a few milliseconds to get back), I'm leaning towards using tokio-core timeouts. They're lighter weight, doesn't start a new thread, and doesn't require another dependency.

[sfackler]

I wrote up a little crate handling read and write timeouts via the standard tokio-core timer: https://crates.io/crates/tokio-io-timeout

[nielsle]

Withoutboats has a pull request that adds middleware wrappers to tokio_service::Service. Perhaps that could be used to add logging and timing and retries to the hyper::Client

tokio-rs/tokio-service#21

This solution would be fairly generic and extendable, but it might also be slightly complicated.

[hjr3]

Based on the discussion, I wrote a TimeoutConnector that wraps an existing Connect implementation here https://github.com/hyperium/hyper/compare/master...hjr3:issue-1234?expand=1. I left the code in the connect.rs file for now, so as not to deal with module shenanigans. The TimeoutConnector can be used with the HttpsConnector in hyper_tls too. This may also get use closer to the suggestion from @nielsle about using Middleware. I say may because I did not like very closely that how the PR works. I still owe some tests.

The alternative is to embed the timeout in HttpConnector too, but the wrapper seemed better/cleaner.

I will start playing around with the crate from @sfackler and see if I can get read/write timeouts setup.

[skinowski]

Could you please update the 'advanced' client example with an overall timeout? This is the general case and if it's in the example, it'll be super helpful.

[hjr3]

@skinowski Definitely. Where is the advanced example? I only see the simple example.

[skinowski]

@hjr3 Here: https://hyper.rs/guides/client/advanced/

I've also figured how to do this myself:

let dur = Duration::from_millis(1000);
let work = client.get(...).and_then(...)....;
let tm = timer.timeout(work, dur);

But it's really easy to get caught in wrapped types of these futures: map, and_then, map_err, select2, join, etc. are not easy to follow for a beginner.

[hjr3]

I have read/write timeouts in place. After putting those in, it seems natural to want to configure the client with a connect_timeout instead of wrapping the Connect implementation. I am trying to figure out how to do that.

[hjr3]

@skinowski I also added a PR to add the general timeout to the guide hyperium/hyperium.github.io#13

[hjr3]

I created https://crates.io/crates/hyper-timeout to get connect, read and write timeout functionality. So far, it has been working for my use case. There may be some changes required to tokio-io-timeout, including this comment from @seanmonstar:

As a side note, looking at the tokio-io-timeout crate, the implementations of AsyncRead and AsyncWrite don't pass forward the read_buf and write_buf methods, which would mean readv and writev are no longer used for TcpStream.

I will see about getting some PRs up for tokio-io-timeout.