-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Http2: Hyper client gets stuck if too many requests are spawned #2419
Comments
I think I might have found the issue. When the number of active streams exceed 250 (which is the default limit), the future polled here returns So the poll here is not called. Now in my program there there is upper limit to number of futures (controlled by a semaphore) and it waits for existing streams to be done with. All the wake-ups done to the unbounded channel req_tx are already consumed so there is no one to wake-up the future. |
Here is a work-around: Wrap If more parallel requests are needed, create multiple Edit: This workaround is only for HTTP/2 use hyper::{Body, {client::HttpConnector}};
use hyper_openssl::HttpsConnector;
use tokio::sync::Semaphore;
#[derive(Clone)]
struct CustomClient {
client: Client<HttpsConnector<HttpConnector>>,
guard: Arc<Semaphore>,
}
impl CustomClient {
fn new() -> Result<Self, Error> {
let client = CustomClient::new_hyper_client()?;
let guard = Arc::new(Semaphore::new(240)); //Harcoded limit just below threshold 250
Ok(CustomClient{
client,
guard,
})
}
async fn request(&self, req: Request<Body>) -> Result<Response<Body>, Error> {
//Is allowed to make request? If not then wait.
let _permit = self.guard.acquire().await?;
let rsp = self.client.request(req).await?;
Ok(rsp)
}
} |
Ping. Somehow I came across this issue trying out some stuff between go and tokio/hyper/h2. Since it seems like an issue with h2, it would make sense to move the issue there? |
@seanmonstar can u pls advise? |
How's this going? Is someone working on it? |
Here's a nice self-contained reproduction for this bug: https://github.com/fasterthanlime/h2-repro |
FWIW I observed that an existing waker is silently dropped here. In other words the following assert would fail if added to the top of the function : |
As a quick test / hack I added the following to the start of the function mentioned above : if let Some(task) = self.send_task.take() {
task.wake();
} This seems to fix the issue for me but still trying to figure out what is going on. Won't recommend just blindly applying this patch. |
Some further analysis: Looking at this loop's first iteration the following seems to be happening for the request that gets stuck: |
Thank you so much for debugging this. Once you feel comfortable the patch is no longer blind, I'd be happy to merge a PR. (Mega bonus points if it becomes clear how to trigger this condition in a unit test, but not required.) |
I spent some more time on this today and would definitely not recommend applying the previous "patch". With that patch applied the request that would have gotten stuck is effectively busy polled until it completes, which is not ideal. The real problem/bug is that this function, specifically the call to |
There exists a race condition in ClientTask::poll() when the request that is sent via h2::client::send_request() is pending open. A task will be spawned to wait for send capacity on the sendstream. Because this same stream is also stored in the pending member of h2::client::SendRequest the next iteration of the poll() loop can call poll_ready() and call wait_send() on the same stream passed into the spawned task. Fix this by always calling poll_ready() after send_request(). If this call to poll_ready() returns Pending save the necessary context in ClientTask and only spawn the task that will eventually resolve to the response after poll_ready() returns Ok.
I created a pull request for this issue, please see here. The actual issue turned out to be slightly different than what I originally thought the problem was. Please see the commit log in the PR for further detail. The actual issue is a race condition in ClientTask::poll() and not a problem in the h2 crate. |
There exists a race condition in ClientTask::poll() when the request that is sent via h2::client::send_request() is pending open. A task will be spawned to wait for send capacity on the sendstream. Because this same stream is also stored in the pending member of h2::client::SendRequest the next iteration of the poll() loop can call poll_ready() and call wait_send() on the same stream passed into the spawned task. Fix this by always calling poll_ready() after send_request(). If this call to poll_ready() returns Pending save the necessary context in ClientTask and only spawn the task that will eventually resolve to the response after poll_ready() returns Ok. Closes #2419
I don't quiet understand. AFAICT #3041 is merged. Doesn't this fix the issue? |
I believe it can be closed. |
0.14.20 has a bug hyperium/hyper#2419 that affects IPA
Hi @jfourie1, @seanmonstar, We want to reopen this issue. We tried the same code with semaphore value of 400, as in the repository, and we are able to hit the issue, even with https://github.com/hyperium/hyper/releases/tag/v0.14.27. Note, we have server and client running on different machines. We do acknowledge that this same issue isn't reproducible with semaphore count below 250. However, in our local setup we have 100 as max number of http2 streams at server. But even if we try with semaphore count of 90, network communications through hyper are stuck. Possibly, these issues are connected, and may have same RCA. Need your help to understand further. |
@jeromegn, @seanmonstar, @jfourie1 : Please guide us, how to reopen the issue? |
I'd recommend opening a new issue, with whatever details you can provide. Let's leave this one alone. |
I have a golang https server to which a rust client sends lot of parallel requests.
After few hundreds of requests, it stops and apparently there is no TCP communication.
The REST API accepts a byte buffer in a body and responds back with its length in a json.
To reproduce, the entire code is at: https://github.com/staticgc/hyper-stuck
It has golang server, Rust Client & Golang Client
The build instructions are very straightforward
The default max number of futures spawned are 400
This apparently is more than the max number of http2 streams at server (which is 250)
If the count is reduced to 200 it works.
Other observations:
Number of connections here refers to http2 negotiated connection which hyper (I think) creates only 1 per
Client
instance.So changing HTEST_CONN_COUNT changes the number of
Client
instances that are created.Also to prevent initial flooding at the server, the rust client makes a single http2 request on each
Client
instance and then issues the parallel requests.Able to reproduce on: Mac OS & Cent OS Linux
Edit: Apologies for some typos in build instructions in the repo above. I have fixed those. Let me know here if anything remains.
The text was updated successfully, but these errors were encountered: