I got it working but still I cannot use wait method I see there's a wait meting on future but I cannot call wait on the response how do I fix that do you have any clue ? @vorner
You can't wait the future, you need to chain other stuff to the end of it and return the whole bigger future to the executor in actix.
I'd suggest you invest the time and learn what Futures in Rust actually are, I have the impression you might have come from another language and are hitting these problems because they act differently. I believe tokio.io might have a good tutorial/explanation. I think actix intro might mention them too.
(The coming await syntax might help in that regard too, but under the hood it would still only chain more futures together and return it).
How do I return my response to the user then this is not supposed to be an async op reqwest sync is not working and reqwest async is not what I need that's the problem
actix-web has own client library, if you're on 1.0 then use awc
On side note, if you want to use reqwest from within handlers, you better use async client
P.s. using sync reqwest within async handlers is bad idea anyway. You should either use combinators (and_then, then and etc) from request future or spawn future on actix runtime
I thought I could rewrite my code as examplified in reqwest docs for async send -- and handling the response using match rt_block_on(…) like I previously did by match …send().
But I end up getting a reqwest::async::response (instead of the non-async), and doing take() on that gives me:
error[E0599]: no method named `take` found for type `reqwest::async::Response` in the current scope
--> src/urlinfo.rs:27:21
|
27 | if resp.take(10 * 1024).read_to_end(&mut buf).is_err() {
| ^^^^
|
= note: the method `take` exists but the following trait bounds were not satisfied:
`&mut reqwest::async::Response : std::io::Read`
`&mut reqwest::async::Response : std::iter::Iterator
It feels like I might have to chain all my code that deals with the response onto the impl Future<Item = Response, Error = Error> that the async-send() returns. It also feels like there should be some way around that... um.
In case of irc crate you might be troubled also because it uses tokio-core and spins own event loop. You better look at 0.14 branch and avoid using client that spins own event loop
just doing reqwest::r#async::client::new().post("https://foo").basic_auth("uname","passwd").form(someSerdeSeriazible).send() and then nothing just happens. when i try to wait then the entire app just freezes until i do a kill -9 and this is the only place so far where i need to send an http request and i dont really care how slow its gonna be all i want is to block the current thread and wait until the response comes which is impossible also with the async api. Thats why reqwest is completely useless in my case and actually its not even working. after send normally nothing just happens the request is not sent.
You might argue that i need to do a couple more incantations to get this working because i dont understand the futures and stuff but thats the point i dont really want to deal with all these i dont also care in this context what is going on behind the scenes all i want is to send my request without reinventing the entire internet. The community is really nice but often i notice the preferred way to do simplest things are really getting complicated. Is it too stupid to just open a thread open a connection inside and write a bunch of string to it and wait for the answer through a channel or something. I believe a lot of people like myself who is new to rust would happily use that nice and simple library just seems the community in general forgets sometimes that not everyone is writing kernels or game engines and stuff. some of us just need stupid simple solutions for certain contexts.
I sympathize with your feeling. Due to Rust's high-performance focus, we as a community do tend to have a bias towards suggesting the most performant / scalable solution over the easiest one, even when all the performance isn't necessarily needed.
Thankfully, the two objectives aren't necessarily always at odds. Libraries like Rayon or Serde are good examples of that. But the asynchronous ecosystem is definitely an example where there is such a trade-off currently.
In this particular example, I'm pretty sure that the library which you are using, actix, supports both asynchronous and synchronous tasks. So it should definitely be possible to get something running quickly with the synchronous version of reqwest inside of a synchronous actix actor, and then try the asynchronous version later once you are more comfortable with this part of the Rust ecosystem.
You do not need to make the reqwest-dependent code reliant on the reqwest r#async implementation. Instead you can isolate this synchronous call to a service and call it inside of a Handler. I too ran into the same issue and this is how I resolved it. Referencing gitlab issue:
I have been in the same situation. Digging deep in the code shows that both actix_web and reqwest start an executor - which is the cause of the troubles.
Reqwest::Client::execute hides the asynchronicity of the underlying hyper calls by starting and running an executor if it is needed. I not completely sure in which situations that is - I have'nt looked deeply enough.
The upshot of this is that you can use reqwest for "applications that only require a few HTTP requests, and wish to handle them synchronously" (as they write in the docs). When you use actix you are outside that area and must change to an asynchronous handling of your HTTP-calls - ie. use hyper.