Warp: Upgrade to Tokio v1

Created on 15 Oct 2020  路  26Comments  路  Source: seanmonstar/warp

Dependencies which need to upgrade

  • [x] hyper (hyperium/hyper#2369)
  • [x] tokio-rustls (tokio-rs/tls#46)
  • [x] tokio-tungstenite (snapview/tokio-tungstenite#142)
feature

Most helpful comment

It was merged!
Now we only need a release :)

All 26 comments

Yep, needs to happen in hyper first: https://github.com/hyperium/hyper/issues/2302

Yep, needs to happen in hyper first: hyperium/hyper#2302

Yes, also saw that :)
The patch besides the hyper changes is quite small anyways.


bump-warp.patch

diff --git a/Cargo.toml b/Cargo.toml
index b40c2b5..89f681e 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -31,7 +31,7 @@ scoped-tls = "1.0"
 serde = "1.0"
 serde_json = "1.0"
 serde_urlencoded = "0.7"
-tokio = { version = "0.2", features = ["fs", "stream", "sync", "time"] }
+tokio = { version = "0.3", features = ["fs", "stream", "sync", "time"] }
 tracing = { version = "0.1", default-features = false, features = ["log", "std"] }
 tracing-futures = { version = "0.2", default-features = false, features = ["std-future"] }
 tower-service = "0.3"
@@ -47,7 +47,7 @@ tracing-subscriber = "0.2.7"
 tracing-log = "0.1"
 serde_derive = "1.0"
 handlebars = "3.0.0"
-tokio = { version = "0.2", features = ["macros"] }
+tokio = { version = "0.3", features = ["full"] }
 listenfd = "0.3"

 [features]
diff --git a/src/filters/fs.rs b/src/filters/fs.rs
index 1f04f6b..d4b9fc8 100644
--- a/src/filters/fs.rs
+++ b/src/filters/fs.rs
@@ -22,7 +22,6 @@ use hyper::Body;
 use mime_guess;
 use percent_encoding::percent_decode_str;
 use tokio::fs::File as TkFile;
-use tokio::io::AsyncRead;

 use crate::filter::{Filter, FilterClone, One};
 use crate::reject::{self, Rejection};
diff --git a/src/filters/sse.rs b/src/filters/sse.rs
index 8c4eda5..9d58492 100644
--- a/src/filters/sse.rs
+++ b/src/filters/sse.rs
@@ -54,7 +54,7 @@ use hyper::Body;
 use pin_project::pin_project;
 use serde::Serialize;
 use serde_json;
-use tokio::time::{self, Delay};
+use tokio::time::{self, Sleep};

 use self::sealed::{
     BoxedServerSentEvent, EitherServerSentEvent, SseError, SseField, SseFormat, SseWrapper,
@@ -467,7 +467,7 @@ impl KeepAlive {
         S::Ok: ServerSentEvent + Send,
         S::Error: StdError + Send + Sync + 'static,
     {
-        let alive_timer = time::delay_for(self.max_interval);
+        let alive_timer = time::sleep(self.max_interval);
         SseKeepAlive {
             event_stream,
             comment_text: self.comment_text,
@@ -484,7 +484,7 @@ struct SseKeepAlive<S> {
     event_stream: S,
     comment_text: Cow<'static, str>,
     max_interval: Duration,
-    alive_timer: Delay,
+    alive_timer: Sleep,
 }

 #[doc(hidden)]
@@ -505,7 +505,7 @@ where
     let max_interval = keep_interval
         .into()
         .unwrap_or_else(|| Duration::from_secs(15));
-    let alive_timer = time::delay_for(max_interval);
+    let alive_timer = time::sleep(max_interval);
     SseKeepAlive {
         event_stream,
         comment_text: Cow::Borrowed(""),

there's also the dependency on tokio-tungstenite and tokio-rustls.
tokio-rustls already has a PR upgrading it: https://github.com/tokio-rs/tls/pull/29

Note that currently, warp can start with tokio being explicitly set to 0.3, and it will then fail at run-time. I wonder if we can/should tackle this problem so that it doesn't affect us in the future? E.g. so that the same run-time error cannot appear in future tokio releases (if applicable).

I'm really happy to see that the problem is being addressed in all the referenced projects though, thanks a lot for keeping it up-to-date!

Note that currently, warp can start with tokio being explicitly set to 0.3, and it will then fail _at run-time_. I wonder if we can/should tackle this problem so that it doesn't affect us in the future? E.g. so that the same run-time error cannot appear in future tokio releases (if applicable).

I'm really happy to see that the problem is being addressed in all the referenced projects though, thanks a lot for keeping it up-to-date!

@vn971 That is a very good idea. I had this problem in my project, that I thought I successfully upgraded to tokio 0.3, but then it actually failed on runtime, since dependencies are using tokio 0.2.

What would be an approach to avoid that for the future? Let tokio check the dependency tree on compile-time?

For example, warp can explicitly take tokio::runtime::Handle for server construction. That way it's always visible in user code which tokio version is used by warp.

Is this being worked on in a branch?

Is this being worked on in a branch?

I started in #725, but feel free to take over :)

@Urhengulas ok thanks, I will try.

@Urhengulas I made my own PR, where I managed to get all tests to pass (cargo test --all-features): https://github.com/seanmonstar/warp/pull/753.

Hey everyone, wonder if tokio 0.3.0 will be merged soon?

Likewise, just ran into issues with this that were mind-boggling until I realized the versions were different, and indeed a Tokio 0.2 reactor was not running, only 0.3

I just noticed that examples/hello.rs does not run with tokio 0.3. Switching back to tokio 0.2 runs perfectly.

Are we ready to upgrade to tokio 0.3?

@hosunrise Think update to _tokio 1.0_ more likely :)
If also have in mind https://github.com/hyperium/hyper/pull/2369

Wow tokio 1.0 is released 馃殌馃殌馃殌馃殌!!
So, are we ready to upgrade to tokio 1.0?

@sinkuu Wow tokio 1.0 is released 馃殌馃殌馃殌馃殌!!
So, are we ready to upgrade to tokio 1.0?

Not yet, but I guess soon
Since hyper just released 0.14.1 which supports tokio 1.0 and tokio-rustls also upgraded
Only tokio-tungstenite left

Would it make sense to widen the scope of this issue and jump to tokio-v1.0 directly?

@simonsan My PR upgrades to tokio 1.0.

@simonsan My PR upgrades to tokio 1.0.

Is there an issue to relate to for tracking?

@simonsan This issue.

@sinkuu Wow tokio 1.0 is released 馃殌馃殌馃殌馃殌!!
So, are we ready to upgrade to tokio 1.0?

Not yet, but I guess soon
Since hyper just released 0.14.1 which supports tokio 1.0 and tokio-rustls also upgraded
Only tokio-tungstenite left

Currently, the last component tokio-tungstenite ( https://github.com/snapview/tokio-tungstenite/pull/142 ) depends on tungstenite-rs ( https://github.com/snapview/tungstenite-rs/issues/169 ) which depends on http
http v0.2.3 ( https://github.com/hyperium/http/pull/463 ) will be released soon (I guess)

Hello, is there any date for release warp with new tokio?

It was merged!
Now we only need a release :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

asaaki picture asaaki  路  7Comments

kamalmarhubi picture kamalmarhubi  路  5Comments

whitfin picture whitfin  路  3Comments

stevensonmt picture stevensonmt  路  5Comments

seanmonstar picture seanmonstar  路  8Comments