quarkus: Resteasy Reactive first POST with InputStream hang
Describe the bug Using resteasy-reactive the first POST with an input stream hang forever
Expected behavior Return the payload
Actual behavior The socket stay connected forever if the client doesn’t implement a timeout
To Reproduce Clone this repo:
https://github.com/masini/test-case-resteasy-reactive-first-post-bug
Steps to reproduce the behavior:
- mvn quarkus:dev
- attach e debugger
- run the curl in the readme.md
Configuration
####HTTP #########
quarkus.http.port=8082
quarkus.http.ssl-port=9081
quarkus.http.access-log.enabled=true
quarkus.http.root-path=/resources
####SECURITY Start#########
quarkus.http.auth.basic=true
quarkus.security.users.embedded.enabled=true
quarkus.security.users.embedded.plain-text=true
quarkus.security.users.embedded.users.admin=admin
quarkus.security.users.embedded.roles.admin=TERMINAL_ROLE,APP_ROLE,TECHNICAL_ROLE
quarkus.http.ssl.certificate.key-store-file=tls/keystore.p12
quarkus.http.ssl.certificate.key-store-password=infogroup
quarkus.http.ssl.certificate.key-store-file-type=PKCS12
Environment (please complete the following information):
uname -a: Darwin WMICTLM1P.lan 19.6.0 Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64 x86_64java -version: openjdk version “11.0.10” 2021-01-19 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode)- Quarkus version or git rev: 1.12.0.Final (also tried with 1.12.1.Final, pushed this version)
mvnw --version: Maven home: /Users/ictlm1/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3 Java version: 11.0.10, vendor: AdoptOpenJDK, runtime: /Applications/sviluppo/java/jdk-11.0.10+9/Contents/Home Default locale: en_GB, platform encoding: UTF-8 OS name: “mac os x”, version: “10.15.7”, arch: “x86_64”, family: “mac”
Additional context This is a reproducer of a real problem in a real application.
In the real application this happens also without debugger and with the quarkus-run.jar, the reproducer instead is able to reproduce only with a debugger attached and not always. I think it’s a matter of timings, but I’m not sure, I need to debug more.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 57 (53 by maintainers)
Commits related to this issue
- Fix race condition on reading input in RESTEasy Reactive Fixes: #15479 — committed to geoand/quarkus by geoand 3 years ago
- Merge pull request #15553 from geoand/#15479 Fix race condition on reading input in RESTEasy Reactive — committed to quarkusio/quarkus by geoand 3 years ago
- Fix race condition on reading input in RESTEasy Reactive Fixes: #15479 (cherry picked from commit 1fd5305a7a82c370d7706bb8b608e1f8b16f0b9f) — committed to gsmet/quarkus by geoand 3 years ago
It’s unlikely I’ll be able to run it today. Hopefully tomorrow or Friday.
I launched this on the root:
mvn -T C1 -Dquickly install -DskipTests
Now I check about the quarkus-bom, everytime I forget to change for the SNAPSHOT…
Thanks again @geoand
More context.
Adding the @Blocking annotation resolve the problem for the test-case and also for the real application.
I don’t want to make it blocking, I’ll debug a little bit more to understand what is going on.
Thanks @geoand , now I ask a colleague out of context if he can reproduce.