-
Notifications
You must be signed in to change notification settings - Fork 36
vertx-http-proxy gets stuck when the original client is unavailable with a pending request. #117
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
Comments
Thank you for reporting, I'll look into it |
@edu-gimenez this should be fixed with #118 Any chance for you to try a snapshot build with the fix? |
Hi @tsegismont, it seems that the issue is resolved with #118. |
Great, thanks for the update. Please go ahead and file new issues if required. |
Hi @tsegismont , That said, I believe there’s more than one issue here. While I think there are some unhandled corner cases in ReverseProxy, I also suspect there’s a different corner case in vertx-core. In particular, there's a scenario where the HttpClientRequest is created, but the Http2ClientConnection stream is never initialized (for example, when the HttpServerRequest is reset when it is going to be piped).
In this case, the handler in HttpClientImpl#doRequest is never invoked:
I guess that if the recycle method is not called, the slot is not released and the connection becomes blocked. |
No problem to reopen, I thought it was fixed as per you previous comment. I'll take a look at the reproducer using the latest 4.5 version |
I also thought the issue was fixed with the previous commit, but since it's a strange race condition, it seems I wasn't able to reproduce it in my initial tests. |
Uh oh!
There was an error while loading. Please reload this page.
I am using vertx-http-proxy:4.5.13 in a Vert.x server, and sometimes the server becomes unresponsive. I have realized that when the original client dies while there are pending requests in progress, the HTTP client responsible for the proxy gets stuck.
I believe the issue comes from the interaction between ProxiedRequest and PipeImpl, but I am not 100% sure.
These are the exceptions that I get before the client gets stuck.
Do you have a reproducer?
I have created a small project to reproduce this error.
The project contains 3 main classes:
http-proxy-vertx-issue.zip
Steps to reproduce
mvn package
java -cp target/http-proxy-vertx-issue-1.0-SNAPSHOT.jar com.http.proxy.vertx.issue.backend.BackendServer
java -cp target/http-proxy-vertx-issue-1.0-SNAPSHOT.jar com.http.proxy.vertx.issue.proxy.ProxyServer
java -cp target/http-proxy-vertx-issue-1.0-SNAPSHOT.jar com.http.proxy.vertx.issue.client.App 2 200 0 100 0 0 GET http://localhost:20000/some/path 0 none
(Client can be configured, use java -cp target/http-proxy-vertx-issue-1.0-SNAPSHOT.jar com.http.proxy.vertx.issue.client.App --help` to see all options)The text was updated successfully, but these errors were encountered: