-
Updated
Nov 13, 2020 - Rust
tokio
Here are 203 public repositories matching this topic...
-
Updated
May 31, 2018 - Rust
Here is a rough idea of what this test should do:
- It should be quite similar to the other tests which are currently in place.
- It should isolate a follower node, write a data to the cluster which will cause that node to fall behind into lagging state, but not into snapshotting state.
- It should then spawn a task which will continue to write data to the cluster.
- Just after it is spawne
-
Updated
Nov 26, 2020 - Rust
-
Updated
Nov 17, 2020 - Rust
-
Updated
Nov 9, 2020 - Rust
-
Updated
Jul 15, 2020 - Rust
-
Updated
Dec 28, 2018 - Rust
-
Updated
Nov 25, 2020 - Rust
-
Updated
Nov 1, 2020 - Rust
-
Updated
Nov 26, 2019 - Rust
-
Updated
Nov 30, 2020 - Rust
-
Updated
Nov 16, 2020 - Rust
-
Updated
Sep 30, 2020 - Rust
It looks like Nitox doesn't support client verification as of now. I made some quick changes to pass TLS config to the native-tls connector. When I tested this, I'm getting:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TlsError(Ssl(Error { code: ErrorCode(1), cause: Some(Ssl(Erro
Improve this page
Add a description, image, and links to the tokio topic page so that developers can more easily learn about it.
Add this topic to your repo
To associate your repository with the tokio topic, visit your repo's landing page and select "manage topics."
In terms of Telegram bot API the maximum polling time of
getUpdatesis referred to astimeout. That is if there are pending updates, Telegram will return them immediately. In the other case, it will wait for timeout seconds and then answer with an empty list.The telegram-bot Rust library has its own notion of timeouts. getUpdates' timeout [i