geoand
commented
1 year ago Can you add the exception that is produced?
Furthermore, can you try with quarkus-resteasy-reactive-jackson instead of quarkus-resteasy-jackson ?
Closed querdenker2k closed 1 year ago
geoand
commented
1 year ago Can you add the exception that is produced?
Furthermore, can you try with quarkus-resteasy-reactive-jackson instead of quarkus-resteasy-jackson ?
querdenker2k
commented
1 year ago Tested with the reactive version produces the same error.
geoand
commented
1 year ago 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
querdenker2k
commented
1 year ago I tried this as well with curl. You could use --http2 or --http1.1. I don't want to teaser but with --http1.1 its working and with --http2 not. I can tomorrow post the command a sample request.
querdenker2k
commented
1 year ago I updated the reproducer. There are now two examples for using curl. Just start the application and run the examples.
geoand
commented
1 year ago @vietj @cescoffier there seems to be an issue with Vert.x here. If I take the reproducer by @querdenker2k and apply the following patch:
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
querdenker2k
commented
1 year ago 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.
geoand
commented
1 year ago querdenker2k
commented
1 year ago yes, this is currently set in the reproducer
vietj
commented
1 year ago 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 ?
geoand
commented
1 year ago @vietj my patch doesn't use RESTEasy Reactive at all.
It just uses Quarkus to start the application, the endpoint is pure Vert.x
vietj
commented
1 year ago 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 https://github.com/quarkusio/quarkus/issues/35180#issuecomment-1665237537, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCV234YIBYJ45QZNLULXTSYOLANCNFSM6AAAAAA3CJRHP4 . You are receiving this because you were mentioned.Message ID: @.***>
geoand
commented
1 year ago I did not try (not enough time today), but I see no reason why it would behave differently.
mschorsch
commented
1 year ago @querdenker2k What happens If you remove the dependency on org.apache.httpcomponents.client5:httpclient5? Does th error still persists?
vietj
commented
1 year ago I did not try (not enough time today), but I see no reason why it would behave differently.
that would help isolate the error and try with different version of vertx to check if there is a regression from a previous version
vietj
commented
1 year ago thanks @geoand I'll have a look soon
geoand
commented
1 year ago Thanks!
vietj
commented
1 year ago it seems a bug in HTTP/1.1 upgrade to HTTP/2 in Vert.x, with SSL and HTTP/2 it works fine
gsmet
commented
1 year ago @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.
vietj
commented
1 year ago 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.
vietj
commented
1 year ago My opinion is that this bug has been there fore a while and is somehow edgy.
querdenker2k
commented
1 year ago 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. With http2 and tls it's all fine. But in safe production environment where http is used or kubernetes where the ingress terminates the tls this could be a problem.
vietj
commented
1 year ago 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.
vietj
commented
1 year ago The bug is fixed in this PR : https://github.com/eclipse-vertx/vert.x/pull/4802
geoand
commented
1 year ago Thanks @vietj !
querdenker2k
commented
1 year ago @vietj @geoand Can you say when this will be released and then included in a new Quarkus release?
geoand
commented
1 year ago Not yet, as Vert.x upgrades in Quarkus require some work
vietj
commented
1 year ago 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 https://github.com/quarkusio/quarkus/issues/35180#issuecomment-1677045427, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCV3RCUOVKUZBFOPNJLXVH2FTANCNFSM6AAAAAA3CJRHP4 . You are receiving this because you were mentioned.Message ID: @.***>
Shivanksinghal
commented
2 months ago I am facing the same issue with quarkus 3.11.2
geoand
commented
2 months ago How about with 3.12.1?
Shivanksinghal
commented
2 months ago I am facing the same issue with quarkus 3.11.2
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