Server fails receiving large data over http/2 #35180
Comments
|
Can you add the exception that is produced? Furthermore, can you try with |
|
Tested with the reactive version produces the same error. |
|
Right, I just tried it myself as well. It it yet to be seen however if this is an HTTP Client issue, I'll have to try that tomorrow |
|
I tried this as well with curl. You could use --http2 or --http1.1. |
|
I updated the reproducer. There are now two examples for using curl. |
|
@vietj @cescoffier there seems to be an issue with Vert.x here. From b585b8cac4f5d030f2f96021248cb6cd9eb66fd7 Mon Sep 17 00:00:00 2001
From: Georgios Andrianakis <geoand@gmail.com>
Date: Fri, 4 Aug 2023 08:26:37 +0300
Subject: [PATCH] Demonstrate the problem with Vert.x only
---
pom.xml | 4 ++--
.../quarkus/http2_reproducer/MyService.java | 12 -----------
.../io/quarkus/http2_reproducer/Vertx.java | 20 +++++++++++++++++++
.../http2_reproducer/MyServiceTest.java | 2 +-
4 files changed, 23 insertions(+), 15 deletions(-)
delete mode 100644 src/main/java/io/quarkus/http2_reproducer/MyService.java
create mode 100644 src/main/java/io/quarkus/http2_reproducer/Vertx.java
diff --git a/pom.xml b/pom.xml
index 6311dfd..7562bcc 100644
--- a/pom.xml
+++ b/pom.xml
@@ -44,7 +44,7 @@
<dependencies>
<dependency>
<groupId>io.quarkus</groupId>
- <artifactId>quarkus-resteasy-reactive-jackson</artifactId>
+ <artifactId>quarkus-vertx-http</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
@@ -56,4 +56,4 @@
<artifactId>httpclient5</artifactId>
</dependency>
</dependencies>
-</project>
\ No newline at end of file
+</project>
diff --git a/src/main/java/io/quarkus/http2_reproducer/MyService.java b/src/main/java/io/quarkus/http2_reproducer/MyService.java
deleted file mode 100644
index 9180c82..0000000
--- a/src/main/java/io/quarkus/http2_reproducer/MyService.java
+++ /dev/null
@@ -1,12 +0,0 @@
-package io.quarkus.http2_reproducer;
-
-import jakarta.ws.rs.POST;
-import jakarta.ws.rs.Path;
-
-@Path("/bigdata")
-public class MyService {
- @POST
- public String receiveBigData(byte[] data) {
- return "received: " + data.length;
- }
-}
diff --git a/src/main/java/io/quarkus/http2_reproducer/Vertx.java b/src/main/java/io/quarkus/http2_reproducer/Vertx.java
new file mode 100644
index 0000000..1af3365
--- /dev/null
+++ b/src/main/java/io/quarkus/http2_reproducer/Vertx.java
@@ -0,0 +1,20 @@
+package io.quarkus.http2_reproducer;
+
+import io.vertx.core.http.HttpMethod;
+import io.vertx.ext.web.Router;
+import io.vertx.ext.web.handler.BodyHandler;
+import jakarta.enterprise.event.Observes;
+import jakarta.inject.Singleton;
+
+@Singleton
+public class Vertx {
+
+ public void init(@Observes Router router) {
+ router.route().handler(BodyHandler.create());
+
+
+ router.route(HttpMethod.POST, "/bigdata").handler(rc -> {
+ rc.response().end("\"received: \" + data.length");
+ });
+ }
+}
diff --git a/src/test/java/io/quarkus/http2_reproducer/MyServiceTest.java b/src/test/java/io/quarkus/http2_reproducer/MyServiceTest.java
index 84df1c3..40cf12d 100644
--- a/src/test/java/io/quarkus/http2_reproducer/MyServiceTest.java
+++ b/src/test/java/io/quarkus/http2_reproducer/MyServiceTest.java
@@ -30,7 +30,7 @@ public class MyServiceTest {
HttpClient client = HttpClient.newBuilder()
.version(version)
.build();
- HttpRequest request = HttpRequest.newBuilder(URI.create("http://localhost:8081/rs/bigdata"))
+ HttpRequest request = HttpRequest.newBuilder(URI.create("http://localhost:8081/bigdata"))
.POST(HttpRequest.BodyPublishers.ofByteArray(new byte[size]))
.build();
HttpResponse<String> response =
--
2.34.1the problem still persists |
|
By the way, i came from Quarkus 2.16.3 where this wasn't a problem. But maybe just because the client uses HTTP/1.1 per default. |
|
yes, this is currently set in the reproducer |
|
it could also be a bug in resteasy reactive that happens with HTTP/2 protocol and not HTTP/1.1, I think the best to figure out would be to reproduce it with Vert.x HTTP/2 without Quarkus. Perhaps the test can be modified to add a reactive route in Quarkus and have it implemented with Vert.x doing the same operation than resteasy reactive do ? |
|
@vietj my patch doesn't use RESTEasy Reactive at all. It just uses Quarkus to start the application, the endpoint is pure Vert.x |
|
ok great, can you reproduce it in a project with vertx without quarkus then
?
…On Fri, Aug 4, 2023 at 10:40 AM Georgios Andrianakis < ***@***.***> wrote:
@vietj <https://github.com/vietj> my patch doesn't use RESTEasy Reactive
at all.
It just uses Quarkus to start the application, the endpoint is pure Vert.x
—
Reply to this email directly, view it on GitHub
<#35180 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABXDCV234YIBYJ45QZNLULXTSYOLANCNFSM6AAAAAA3CJRHP4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I did not try (not enough time today), but I see no reason why it would behave differently. |
|
@querdenker2k What happens If you remove the dependency on |
that would help isolate the error and try with different version of vertx to check if there is a regression from a previous version |
|
thanks @geoand I'll have a look soon |
|
Thanks! |
|
it seems a bug in HTTP/1.1 upgrade to HTTP/2 in Vert.x, with SSL and HTTP/2 it works fine |
|
@vietj is it a regression? (to know if it's a red flag for 3.2). 2.13.x is using Vert.x 4.3.4. |
|
no @gsmet , this is a bug that has been discovered, it affects the Vert.x HTTP server for client that want to use HTTP/2 in plaintext with an HTTP/1.1 upgrade that do not use SSL with a request body greater than the initial window size of an HTTP/2 connection (the server window size). In such situation, the vertx server believes that the extra data below the window size is erroneous and reject it. |
|
My opinion is that this bug has been there fore a while and is somehow edgy. |
|
It's not so edgy. I tried a large request with http2 (via curl) against my productive deployment and it failed. I think that currently all clients are using http1.1 and therefor the error doesn't occur. |
|
I agree, I might be wrong, my only assumption is that based on the fact I do not recommend to use H2C with upgrade in production because of potential bottleneck it introduces and the fact that it has not been reported in years of availability. As said above if anyone would to use H2C in production then I would recommend to use direct H2C instead (without HTTP/1.1 upgrade) because the HTTP/1.1 to HTTP/2 upgrade can be a performance bottleneck, the first HTTP request performed by the client uses HTTP/1.1 to send the body and will be the only request allowed on the connection until the HTTP/1.1 request is fully sent. The Vert.x HTTP server does support this on the server and the client. |
|
The bug is fixed in this PR : eclipse-vertx/vert.x#4802 |
|
Thanks @vietj ! |
|
Not yet, as Vert.x upgrades in Quarkus require some work |
|
we also need to release vertx 4.4.5
…On Mon, Aug 14, 2023 at 12:07 PM Georgios Andrianakis < ***@***.***> wrote:
Not yet, as Vert.x upgrades in Quarkus require some work
—
Reply to this email directly, view it on GitHub
<#35180 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABXDCV3RCUOVKUZBFOPNJLXVH2FTANCNFSM6AAAAAA3CJRHP4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
cescoffier
added
area/vertx
triage/upstream
Also bump Quarkus HTTP to 5.0.3.Final to handle a breaking change in the Vert.x API. Fix quarkusio#35180 Fix quarkusio#34719
Also bump Quarkus HTTP to 5.0.3.Final to handle a breaking change in the Vert.x API. Fix quarkusio#35180 Fix quarkusio#34719 Fix quarkusio#35278
Also bump Quarkus HTTP to 5.0.3.Final to handle a breaking change in the Vert.x API. Fix quarkusio#35180 Fix quarkusio#34719 Fix quarkusio#35278
Also bump Quarkus HTTP to 5.0.3.Final to handle a breaking change in the Vert.x API. Fix quarkusio#35180 Fix quarkusio#34719 Fix quarkusio#35278
|
I am facing the same issue with quarkus 3.11.2 |
|
How about with 3.12.1? |
nvm it was the issue with the wiremock stub server |
Describe the bug
While sending data to a Quarkus rest endpoint with 1000 bytes it's all fine regardless of http or http/2.
But sending for example 1MB it fails using http/2. Because http/2 is the standard for most clients thats a problem.
Expected behavior
Http/2 calls with ~1MB should not fail.
Actual behavior
Http/2 calls with huge data (e.g. 1MB fails) throws an exception java.io.EOFException: EOF reached while reading
How to Reproduce?
Clone and mvn clean package
https://github.com/querdenker2k/http2-reproducer
Output of
uname -aorverLinux s2140414 5.15.0-78-generic #85-Ubuntu SMP Fri Jul 7 15:25:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -versionjava version "17.0.7" 2023-04-18 LTS Java(TM) SE Runtime Environment Oracle GraalVM 17.0.7+8.1 (build 17.0.7+8-LTS-jvmci-23.0-b12) Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.7+8.1 (build 17.0.7+8-LTS-jvmci-23.0-b12, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
3.2.2.Final
Build tool (ie. output of
mvnw --versionorgradlew --version)3.8.1
Additional information
No response
The text was updated successfully, but these errors were encountered: