Following example code always produces Error: Connect(Timeout):
use actix_rt::System;
use awc::Client;
use futures::future::{
Future,
lazy
};
fn main() {
System::new("weight_version").block_on(lazy(|| {
awc::Client::new().get("https://google.com") //any address here
.header("User-Agent", "Actix-web")
.send()
.map_err(|error| {
println!("Error: {:?}", error);
})
.and_then(|response| {
println!("Response: {:?}", response);
Ok(())
})
}));
}
actix_web::client::Client also produces same error:
use actix_rt::System;
use actix_web::client::Client;
use futures::future::{
Future,
lazy
};
fn main() {
System::new("weight_version").block_on(lazy(|| {
let client = Client::default();
client.get("https://www.rust-lang.org/")
.header("User-Agent", "Actix-web")
.send()
.map_err(|error| {
println!("Error: {:?}", error);
//Err(error)
})
.and_then(|response| {
println!("Response: {:?}", response);
Ok(())
})
}));
}
Tested on 3 totally different windows machines with following:
openssl version
OpenSSL 1.1.1c 28 May 2019
I just tested the first snipped on Linux and it worked fine.
Could you post your Cargo.toml dependencies (or better yet a full reproduction). I will try to reproduce when I can get my hands on a windows laptop.
Nothing meaningful in my Cargo.toml, aside from deps:
[dependencies]
actix-rt = "0.2.4"
# actix-web = { version="1.0.5", features=["ssl"] }
# awc = { version="0.2.4", features=["ssl"] }
awc = { version="0.2.4", features=["rust-tls"] } # rustls gives the same error
futures = "0.1.28"
Let me know if you would like to get the binary.
active toolchain
----------------
stable-x86_64-pc-windows-gnu (default)
rustc 1.37.0 (eae3437df 2019-08-13)
I'm using gcc and mingw64 if this matters. OpenSSL is also compiled with these two.
I have the same issue on my windows system while the same code works perfectly fine on linux.
awc::Client::build()
.connector(
awc::Connector::new()
.timeout(Duration::from_secs(10))
.finish(),
)
.timeout(Duration::from_secs(10))
.finish()
I got it work by construct client this way but I still get very poor response time.
i think this is related to trust-dns config.
Any quick fix/workaround for this? 30 secs timeout is not very reliable solution.
Try to disable inactive network cards
Thanks, disabling one of the connections on one of the PCs seems to fix huge delay on it.
The thing is, another PC has just one network card and still had the issue the last time I checked.
I'm going to test it again and provide feedback a bit later.
I've been getting the same error/behaviour on Mac OS X as well (the same code works fine on Linux for me).
The issue only seems to occur on debug builds too (perhaps because the request takes longer and times out?). Running under a release build works fine.
In case it's of any use, this is the trace log output from my server. My server is just:
use actix_web::{client::Client, web, App, HttpResponse, HttpServer, Error};
use futures::Future;
fn index() -> impl Future<Item = HttpResponse, Error = Error> {
let client = Client::default();
client.get("http://example.com")
.send()
.map_err(Error::from)
.and_then(|mut resp| {
resp.body()
.from_err()
.and_then(|body| {
Ok(HttpResponse::Ok().body(body))
})
})
}
fn main() {
env_logger::init();
HttpServer::new(|| {
App::new()
.route("/", web::get().to_async(index))
})
.bind("127.0.0.1:8088")
.unwrap()
.run()
.unwrap();
}
and the trace logging output:
[2019-08-21T11:16:17Z TRACE tokio_reactor] event Readable Token(4194303)
[2019-08-21T11:16:17Z TRACE tokio_reactor] loop process - 1 events, 0.000s
[2019-08-21T11:16:17Z TRACE tokio_reactor] event Readable Token(4194303)
[2019-08-21T11:16:17Z TRACE tokio_reactor] loop process - 1 events, 0.000s
[2019-08-21T11:16:17Z DEBUG tokio_reactor] adding I/O source: 0
[2019-08-21T11:16:17Z TRACE mio::poll] registering with poller
[2019-08-21T11:16:17Z TRACE mio::sys::unix::kqueue] registering; token=Token(0); interests=Readable | Writable | Error | Hup
[2019-08-21T11:16:17Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2019-08-21T11:16:17Z TRACE tokio_reactor] event Readable | Writable Token(0)
[2019-08-21T11:16:17Z TRACE tokio_reactor] loop process - 1 events, 0.000s
[2019-08-21T11:16:17Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2019-08-21T11:16:17Z TRACE actix_connect::resolver] DNS resolver: resolving host "example.com"
[2019-08-21T11:16:17Z TRACE tokio_reactor] event Readable Token(4194303)
[2019-08-21T11:16:17Z TRACE tokio_reactor] loop process - 1 events, 0.000s
[2019-08-21T11:16:17Z DEBUG trust_dns_resolver::async_resolver::background] trust-dns resolver running
[2019-08-21T11:16:26Z TRACE tokio_reactor] event Readable Token(4194303)
[2019-08-21T11:16:26Z TRACE tokio_reactor] loop process - 1 events, 0.000s
[2019-08-21T11:16:26Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2019-08-21T11:16:26Z DEBUG trust_dns_proto::xfer::dns_handle] querying: example.com A
[2019-08-21T11:16:26Z TRACE tokio_reactor] event Writable Token(0)
[2019-08-21T11:16:26Z TRACE tokio_reactor] event Readable Token(4194303)
[2019-08-21T11:16:26Z TRACE tokio_reactor] loop process - 2 events, 0.000s
[2019-08-21T11:16:26Z TRACE actix_http::h1::dispatcher] Keep-alive timeout, close connection
[2019-08-21T11:16:26Z TRACE mio::poll] deregistering handle with poller
[2019-08-21T11:16:26Z DEBUG tokio_reactor] dropping I/O source: 0
[2019-08-21T11:16:26Z TRACE tokio_reactor] loop process - 0 events, 0.000s
Well that's unfortunate. Everything I was planning to do with actix-web involved the client and connecting to a host, and I'm Windows!
Someone needs to provide PR. I donβt work with windows. Linux and OS X work fine
@fafhrd91 I have the same issue on OS X too (but only on debug builds, see above). I've tried to find the problem and fix, but had no luck yet.
Current workaround I'm using is to make blocking HTTP calls with reqwest and Actix web::block instead of using actix_web::client::Client, but would be nice to move to async eventually.
@davechallis Is this about what you are doing?
https://github.com/rokit/actix-async-factory (ignore the name of this repo)
I decided to run a little experiment, and I don't see how it's blocking anything. I'm simulating a 5-second server response time with this tool called Slowwly. Here are the steps:
localhost:8000/get/rust/posts/slowwly and one pointing to localhost:8000/get/rust/posts.I was expecting the Slowwly request to block the regular request, but that doesn't appear to be the case since the regular request comes back first. Am I missing something? What is being blocked exactly?
@rokit not quite, I'm just making a single request, using the actix-web async client (the request is to an endpoint that just fetches a fast responding web page). When using the actix-web HTTP client on Mac OS X, and in a debug build, I get a connect timeout error. In a release build, it works fine.
I'm using reqwest and web::block as a workaround for the actix-web client issue (request + block works fine).
@davechallis when you mention debug builds you mean actix-web debug build or your code in debug?
Just run your snippet on mac os (catalina) without any issue.
```main.rs
use actix_web::{client::Client, web, App, HttpResponse, HttpServer, Error};
use futures::Future;
fn index() -> impl Future
let client = Client::default();
client.get("https://linuxfr.org")
.send()
.map_err(Error::from)
.and_then(|mut resp| {
resp.body()
.from_err()
.and_then(|body| {
Ok(HttpResponse::Ok().body(body))
})
})
}
fn main() {
env_logger::init();
HttpServer::new(|| {
App::new()
.route("/", web::get().to_async(index))
})
.bind("127.0.0.1:8088")
.unwrap()
.run()
.unwrap();
}
[dependencies]
actix-web = { version="1.0.5", features=["ssl"] }
futures = "0.1.28"
env_logger = "*"
```
rustc 1.41.0 (5e1a79984 2020-01-27)
@Bhaal22 sorry, should have clarified. Was running my code in a debug build. Just tried again with your code snippet and dependencies above, with the same rustc version, using the command:
$ RUST_LOG=debug cargo run
when I run curl -i localhost:8088, I get the following log output:
[2020-02-19T11:47:10Z INFO actix_server::builder] Starting 4 workers
[2020-02-19T11:47:10Z INFO actix_server::builder] Starting server on 127.0.0.1:8088
[2020-02-19T11:47:10Z DEBUG tokio_reactor] adding I/O source: 0
[2020-02-19T11:47:10Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:47:10Z DEBUG tokio_reactor] adding I/O source: 4194305
[2020-02-19T11:47:10Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:47:10Z DEBUG tokio_reactor] adding I/O source: 8388610
[2020-02-19T11:47:10Z DEBUG tokio_reactor::registration] scheduling Read for: 2
[2020-02-19T11:47:10Z DEBUG tokio_reactor] adding I/O source: 12582915
[2020-02-19T11:47:10Z DEBUG tokio_reactor::registration] scheduling Read for: 3
[2020-02-19T11:47:14Z DEBUG tokio_reactor] adding I/O source: 0
[2020-02-19T11:47:14Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:47:14Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:47:14Z DEBUG trust_dns_resolver::async_resolver::background] trust-dns resolver running
[2020-02-19T11:47:19Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:47:19Z ERROR actix_http::response] Internal Server Error: Timeout
[2020-02-19T11:47:19Z DEBUG tokio_reactor] dropping I/O source: 0
and curl outputs:
HTTP/1.1 500 Internal Server Error
content-length: 38
content-type: text/plain; charset=utf-8
date: Wed, 19 Feb 2020 11:47:14 GMT
Timeout out while waiting for response
If I instead start the server with a release build:
RUST_LOG=debug cargo run --release
and make the same curl request, the logs instead show:
2020-02-19T11:54:19Z INFO actix_server::builder] Starting 4 workers
[2020-02-19T11:54:19Z INFO actix_server::builder] Starting server on 127.0.0.1:8088
[2020-02-19T11:54:19Z DEBUG tokio_reactor] adding I/O source: 0
[2020-02-19T11:54:19Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:19Z DEBUG tokio_reactor] adding I/O source: 4194305
[2020-02-19T11:54:19Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:19Z DEBUG tokio_reactor] adding I/O source: 8388610
[2020-02-19T11:54:19Z DEBUG tokio_reactor::registration] scheduling Read for: 2
[2020-02-19T11:54:19Z DEBUG tokio_reactor] adding I/O source: 12582915
[2020-02-19T11:54:19Z DEBUG tokio_reactor::registration] scheduling Read for: 3
[2020-02-19T11:54:21Z DEBUG tokio_reactor] adding I/O source: 0
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG trust_dns_resolver::async_resolver::background] trust-dns resolver running
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer::dns_handle] querying: linuxfr.org A
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG trust_dns_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: V4(169.254.169.253:53), protocol: Udp, tls_dns_name: None }
[2020-02-19T11:54:21Z DEBUG trust_dns_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: V4(172.31.0.2:53), protocol: Udp, tls_dns_name: None }
[2020-02-19T11:54:21Z DEBUG trust_dns_resolver::name_server::connection_provider] connecting: Udp { socket_addr: V4(169.254.169.253:53), timeout: 5s }
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer] enqueueing message: [Query { name: Name { is_fqdn: false, labels: [linuxfr, org] }, query_type: A, query_class: IN }]
[2020-02-19T11:54:21Z DEBUG trust_dns_resolver::name_server::connection_provider] connecting: Udp { socket_addr: V4(172.31.0.2:53), timeout: 5s }
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer] enqueueing message: [Query { name: Name { is_fqdn: false, labels: [linuxfr, org] }, query_type: A, query_class: IN }]
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer::dns_exchange] connection established: UDP(169.254.169.253:53)
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer::dns_exchange] sending message via: UDP(169.254.169.253:53)
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer::dns_exchange] all handles closed, shutting down: UDP(169.254.169.253:53)
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer::dns_exchange] io_stream is done, shutting down
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer::dns_exchange] connection established: UDP(172.31.0.2:53)
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer::dns_exchange] sending message via: UDP(172.31.0.2:53)
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer::dns_exchange] all handles closed, shutting down: UDP(172.31.0.2:53)
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::xfer::dns_exchange] io_stream is done, shutting down
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::udp::udp_stream] created socket: UdpSocket { addr: V4(0.0.0.0:12466), fd: 29 }
[2020-02-19T11:54:21Z DEBUG tokio_reactor] adding I/O source: 4194305
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Write for: 1
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::udp::udp_stream] created socket: UdpSocket { addr: V4(0.0.0.0:46211), fd: 30 }
[2020-02-19T11:54:21Z DEBUG tokio_reactor] adding I/O source: 8388610
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Write for: 2
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 2
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::rr::record_data] reading A
[2020-02-19T11:54:21Z DEBUG trust_dns_proto::udp::udp_client_stream] received message id: 13005
[2020-02-19T11:54:21Z DEBUG tokio_reactor] dropping I/O source: 2
[2020-02-19T11:54:21Z DEBUG tokio_reactor] dropping I/O source: 1
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG tokio_reactor] adding I/O source: 12582913
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Write for: 1
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:21Z DEBUG h2::client] binding client connection
[2020-02-19T11:54:21Z DEBUG h2::client] client connection bound
[2020-02-19T11:54:21Z DEBUG h2::codec::framed_write] send; frame=Settings { flags: (0x0) }
[2020-02-19T11:54:21Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:21Z DEBUG h2::codec::framed_write] send; frame=Headers { stream_id: StreamId(1), flags: (0x5: END_HEADERS | END_STREAM) }
[2020-02-19T11:54:22Z DEBUG h2::codec::framed_read] received; frame=Settings { flags: (0x0), max_concurrent_streams: 128, initial_window_size: 65536, max_frame_size: 16777215 }
[2020-02-19T11:54:22Z DEBUG h2::codec::framed_write] send; frame=Settings { flags: (0x1: ACK) }
[2020-02-19T11:54:22Z DEBUG h2::codec::framed_read] received; frame=WindowUpdate { stream_id: StreamId(0), size_increment: 2147418112 }
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG h2::codec::framed_read] received; frame=Settings { flags: (0x1: ACK) }
[2020-02-19T11:54:22Z DEBUG h2::proto::settings] received remote settings ack
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG h2::codec::framed_read] received; frame=Headers { stream_id: StreamId(1), flags: (0x4: END_HEADERS) }
[2020-02-19T11:54:22Z DEBUG h2::codec::framed_read] received; frame=Data { stream_id: StreamId(1) }
[2020-02-19T11:54:22Z DEBUG h2::codec::framed_read] received; frame=Data { stream_id: StreamId(1) }
[2020-02-19T11:54:22Z DEBUG h2::codec::framed_read] received; frame=Data { stream_id: StreamId(1), flags: (0x1: END_STREAM) }
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:22Z DEBUG tokio_reactor::registration] scheduling Read for: 0
[2020-02-19T11:54:22Z DEBUG h2::codec::framed_write] send; frame=GoAway { last_stream_id: StreamId(0), error_code: NO_ERROR }
[2020-02-19T11:54:22Z DEBUG h2::proto::connection] Connection::poll; connection error=NO_ERROR
[2020-02-19T11:54:22Z DEBUG tokio_reactor] dropping I/O source: 1
[2020-02-19T11:54:22Z DEBUG tokio_reactor] dropping I/O source: 0
and curl returns the proxied web page as expected.
@davechallis i am definitely not sure if it can be related. Do you mind to expose your mac version?
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.3
BuildVersion: 19D76
I re-ran using exactly the same command line as you mentionned before. All works fine.
@Bhaal22 exactly the same for me:
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.3
BuildVersion: 19D76
very odd...
@davechallis
Can we double check this?
$ cargo tree | grep trust
β β β βββ trust-dns-resolver v0.11.1
β β β βββ trust-dns-proto v0.7.4
β β βββ trust-dns-resolver v0.11.1 (*)
Looks like this lib is timing out.
@Bhaal22 hmm.. also the same for me:
$ cargo tree | grep trust
β β β βββ trust-dns-resolver v0.11.1
β β β βββ trust-dns-proto v0.7.4
β β βββ trust-dns-resolver v0.11.1 (*)
So I guess that points at something specific to my environment (network setup, environment variables, etc.?).
@davechallis looks like to be exactly the same environment indeed.
let's try tonight to make a snippet using directly trust-dns-resolver library. maybe we can get more info.
@calirofpn my snippet is working fine on windows10 also.
I have the same issue on Windows 7 (7601 SP1) 64bit.
actix-web 2.0.0 (enabled openssl feature)
actix-rt 1.0.0
futures 0.3.1
OpenSSL 1.1.1d 10 Sep 2019
rustc 1.43.0-nightly (834bc5650 2020-02-24)
@gaoqiangz instead of 127.0.0.1 could you try to bind the socket to 0.0.0.0?
Here is my code:
let cli = http::client::Client::default();
let resp = cli.get("https://www.bing.com").send().await;
info!("resp: {:?}", resp);
return Ok(());
Log:
2020-03-03 17:26:43.957 DEBUG $main#13432 trust_dns_resolver::async_resolver::background> trust-dns resolver running
2020-03-03 17:26:43.958 DEBUG $main#13432 trust_dns_proto::xfer::dns_handle> querying: www.bing.com A
2020-03-03 17:26:43.958 DEBUG $main#13432 trust_dns_resolver::name_server::name_server> reconnecting: NameServerConfig { socket_addr: V6([fec0:0:0:ffff::1]:53), protocol: Udp, tls_dns_name: None }
2020-03-03 17:26:43.959 DEBUG $main#13432 trust_dns_resolver::name_server::name_server> reconnecting: NameServerConfig { socket_addr: V6([fec0:0:0:ffff::2]:53), protocol: Udp, tls_dns_name: None }
2020-03-03 17:26:43.959 DEBUG $main#13432 trust_dns_resolver::name_server::connection_provider> connecting: Udp { socket_addr: V6([fec0:0:0:ffff::1]:53), timeout: 5s }
2020-03-03 17:26:43.959 DEBUG $main#13432 trust_dns_proto::xfer> enqueueing message: [Query { name: Name { is_fqdn: false, labels: [www, bing, com] }, query_type: A, query_class: IN }]
2020-03-03 17:26:43.959 DEBUG $main#13432 trust_dns_resolver::name_server::connection_provider> connecting: Udp { socket_addr: V6([fec0:0:0:ffff::2]:53), timeout: 5s }
2020-03-03 17:26:43.959 DEBUG $main#13432 trust_dns_proto::xfer> enqueueing message: [Query { name: Name { is_fqdn: false, labels: [www, bing, com] }, query_type: A, query_class: IN }]
2020-03-03 17:26:43.959 DEBUG $main#13432 trust_dns_proto::xfer::dns_exchange> connection established: UDP([fec0:0:0:ffff::1]:53)
2020-03-03 17:26:43.959 DEBUG $main#13432 trust_dns_proto::xfer::dns_exchange> sending message via: UDP([fec0:0:0:ffff::1]:53)
2020-03-03 17:26:43.960 DEBUG $main#13432 trust_dns_proto::xfer::dns_exchange> all handles closed, shutting down: UDP([fec0:0:0:ffff::1]:53)
2020-03-03 17:26:43.960 DEBUG $main#13432 trust_dns_proto::xfer::dns_exchange> io_stream is done, shutting down
2020-03-03 17:26:43.960 DEBUG $main#13432 trust_dns_proto::xfer::dns_exchange> connection established: UDP([fec0:0:0:ffff::2]:53)
2020-03-03 17:26:43.960 DEBUG $main#13432 trust_dns_proto::xfer::dns_exchange> sending message via: UDP([fec0:0:0:ffff::2]:53)
2020-03-03 17:26:43.960 DEBUG $main#13432 trust_dns_proto::xfer::dns_exchange> all handles closed, shutting down: UDP([fec0:0:0:ffff::2]:53)
2020-03-03 17:26:43.961 DEBUG $main#13432 trust_dns_proto::xfer::dns_exchange> io_stream is done, shutting down
2020-03-03 17:26:43.961 DEBUG $main#13432 trust_dns_proto::udp::udp_stream> created socket successfully
2020-03-03 17:26:43.961 DEBUG $main#13432 trust_dns_proto::udp::udp_stream> created socket successfully
2020-03-03 17:26:44.957 INFO $main#13432 JNode> resp: Err(Connect(Timeout))
Always Err(Connect(Timeout))
I have the same issue on Windows 10 64bit.
the toml:
[dependencies
actix-web = { version = "2.0.0", features = ["openssl"] }
actix-rt = "1.0.0"
awc = "1.0.1"
the code:
use awc::Client;
#[actix_rt::main]
async fn main() {
let mut client = Client::default();
let res = client.get("https://hyper.rs")
.send()
.await;
println!("Response: {:?}", res);
}
my rust version: rustc 1.43.0-nightly (2890b37b8 2020-03-06)
The result always: Response: Err(Connect(Timeout))
I have the same issue on Windows Sub System Linux ( Ubuntu 18.04 LTS ).
The Cargo.toml
[dependencies.actix-web]
version = "2.0"
features = ["openssl"]
[dependencies.actix-rt]
version = "1.0"
[dependencies.actix-http]
version = "1.0"
the code:
use actix_web::client::Client;
use actix_http::Error;
#[actix_rt::main]
async fn main() -> Result<(), Error> {
let client = Client::new();
let mut response = client.get("https://www.rust-lang.org")
.header("User-Agent", "Actix-web")
.send().await?;
println!("Response: {:?}", response);
let body = response.body().await?;
println!("Downloaded: {:?} bytes", body.len());
Ok(())
}
The result:
Finished dev [unoptimized + debuginfo] target(s) in 0.28s
Running `target/debug/demo`
Error: Connect(Timeout)
FWIW, I'm seeing very similar behaviour on macOS using 2.0.0-alpha.6. It doesn't seem to matter what I do, I can't get anything other than Err(Connect(Timeout)).
Using the following code, taken directly from the documentation:
use actix_web::client::Client;
#[actix_rt::main]
async fn main() {
let mut client = Client::default();
// Create request builder and send request
let response = client.get("http://www.rust-lang.org")
.header("User-Agent", "Actix-web")
.send().await; // <- Send http request
println!("Response: {:?}", response);
}
[dependencies]
actix-rt = "1.0.0-alpha.3"
actix-web = {version = "2.0.0-alpha.6", features = ["openssl"]}
I have a similar issue on Linux, contacting my own API that also runs on localhost. The problem does not lie in this API as I can contact it with curl. In fact it's nearly instantaneous, as the endpoint doesn't do much.
My program sends a request every second in a loop. I construct let client = awc::Client::default(); once before the loop and use the it for all requests. It works fine for a while, then after some time (last time it took 2 minutes) it keeps consistently only returning error Connect(Timeout).
Edit: same thing happens when I set timeout to 10 seconds. It takes 2 minutes of successful requests before it's all Timeout.
Edit: Tried to make a minimal example.
It doesn't behave exactly the same as in my bigger application: instead of at some point _always_ resulting in timeout error, it only fails in periods of a few seconds, relatively rarely. Example output:
457.719295038s: Ok(_)
458.829291403s: Ok(_)
459.913657809s: Ok(_)
461.004554329s: Ok(_)
462.130364496s: Ok(_)
464.774900561s: Ok(_)
466.778764871s: Failed to connect to host: Timeout out while establishing connection
468.780354861s: Failed to connect to host: Timeout out while establishing connection
470.783918783s: Failed to connect to host: Timeout out while establishing connection
472.787729664s: Failed to connect to host: Timeout out while establishing connection
473.912647466s: Ok(_)
474.999039905s: Ok(_)
476.106520578s: Ok(_)
477.206921624s: Ok(_)
478.384364315s: Ok(_)
479.503979118s: Ok(_)
480.621567189s: Ok(_)
Code:
use std::time::Instant;
use tokio::time::{delay_for, Duration};
#[actix_rt::main]
async fn main() {
let client = awc::Client::default();
let start_time = Instant::now();
loop {
let res = client
.get("http://www.google.com/")
.header("User-Agent", "Actix-web")
.send()
.await;
let result = match res {
Ok(_) => "Ok(_)".to_string(),
Err(e) => e.to_string()
};
println!("{:?}: {}", start_time.elapsed(), result);
delay_for(Duration::from_secs(1)).await;
}
}
Dependencies:
[dependencies]
# awc = "2.0.0-alpha.2"
awc = "1.0.1"
actix-rt = "1.1.1"
tokio = {version = "0.2.21", features = ["time"]}
Same results with both above awc versions.
Edit 3: Maybe important, which makes the behaviour in my case similar to what is reported by others: The first request is always Timeout.
I think this has something to do with the lazy initialization of Actix runtime?
My second theory is the DNS resolver being too slow, so that the request is blocked. Someone mentioned try disabling network interfaces. I have 7 currently.
Same issue on Windows Server 2019. Disabling unnecessary network adapters does not affect the problem.
use actix_http::Error;
use actix_web::client::Client;
use std::time::Duration;
#[actix_web::main]
async fn main() -> Result<(), Error> {
let client = Client::new();
// Create request builder, configure request and send
let mut response = client
.get("https://httpbin.org/anything")
.header("User-Agent", "Actix-web")
.timeout(Duration::from_secs(30))
.send()
.await?;
// server http response
println!("Response: {:?}", response);
Ok(())
}
[dependencies]
actix-http = "2.0.0"
actix-web = { version = "3.1.0", features = ["rustls"]}
Most helpful comment
I have the same issue on my windows system while the same code works perfectly fine on linux.
I got it work by construct client this way but I still get very poor response time.