Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Resteasy fails with NumberFormatException if file is larger than 2047 MB #17455

Closed
coperator opened this issue May 25, 2021 · 4 comments · Fixed by #17555
Closed

Resteasy fails with NumberFormatException if file is larger than 2047 MB #17455

coperator opened this issue May 25, 2021 · 4 comments · Fixed by #17555
Labels
area/vertx kind/bug Something isn't working
Milestone
1.13.7.Final

Comments

@coperator
Copy link

Describe the bug

In my service I receive an InputStream in my REST endpoint and use this inputstream directly to store the data in MinIO.
Everything is working well except if the request contains a "Content Length" header and the file is larger than 2047 MB. In this case a NumberFormatException happens because in VertxInputStream.java the header is parsed as int" in method public int readBytesAvailable() line, 297.

Stacktrace:

java.lang.NumberFormatException: For input string: "3080543800"
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.base/java.lang.Integer.parseInt(Integer.java:652)
	at java.base/java.lang.Integer.parseInt(Integer.java:770)
	at io.quarkus.vertx.http.runtime.VertxInputStream$VertxBlockingInput.readBytesAvailable(VertxInputStream.java:297)
	at io.quarkus.vertx.http.runtime.VertxInputStream.available(VertxInputStream.java:137)
	at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:359)
	at io.minio.S3Base.getAvailableSize(S3Base.java:1225)
	at io.minio.S3Base.putObject(S3Base.java:1134)
	at io.minio.MinioClient.putObject(MinioClient.java:1666)

If no Content Length header is given everythings works fine for large files as well, since the readBytesAvailable method simply returns 0 in this case.

Environment (please complete the following information):

Output of java -version

OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)

GraalVM version (if different from Java)

Quarkus version or git rev

1.11.0

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
@coperator coperator added the kind/bug Something isn't working label May 25, 2021
@coperator
Copy link
Author

The code causing this bug was introduced with 5cef24b

@famod
Copy link
Member

famod commented May 26, 2021

/cc @stuartwdouglas @geoand

geoand added a commit to geoand/quarkus that referenced this issue May 31, 2021
@geoand
Make VertxInputStream#available not fail on large content-type
017c53c 
An InputStream cannot read over 2GB of memory, but as `available`
is only an estimate, there is no good reason for that specific
method to fail if content-type indicated a larger payload.
Whether or not the processing fails or how it proceeds, should
be up to consumer of the stream and will likely have to do with
how `read` is implemented.

Fixes: quarkusio#17455
@geoand geoand mentioned this issue May 31, 2021
Merged
geoand added a commit that referenced this issue May 31, 2021
@geoand
Merge pull request #17555 from geoand/#17455
29cd508 
Make VertxInputStream#available not fail on large content-type
@quarkus-bot quarkus-bot bot added this to the 2.1 - main milestone May 31, 2021
@coperator
Copy link
Author

Thank you very much for fixing this quickly, @geoand! Would it be possible to backport this fix to 1.11. or 1.13. ?

@geoand
Copy link
Contributor

geoand commented Jun 2, 2021

Yeah, that's a good point

@gsmet gsmet modified the milestones: 2.1 - main, 2.0.0.CR3 Jun 3, 2021
gsmet pushed a commit to gsmet/quarkus that referenced this issue Jun 3, 2021
@geoand @gsmet
Make VertxInputStream#available not fail on large content-type
c4d5d9e 
An InputStream cannot read over 2GB of memory, but as `available`
is only an estimate, there is no good reason for that specific
method to fail if content-type indicated a larger payload.
Whether or not the processing fails or how it proceeds, should
be up to consumer of the stream and will likely have to do with
how `read` is implemented.

Fixes: quarkusio#17455
(cherry picked from commit 017c53c)
@gsmet gsmet modified the milestones: 2.0.0.CR3, 1.13.7.Final Jun 7, 2021
gsmet pushed a commit to gsmet/quarkus that referenced this issue Jun 7, 2021
@geoand @gsmet
Make VertxInputStream#available not fail on large content-type
f7a1ee8 
An InputStream cannot read over 2GB of memory, but as `available`
is only an estimate, there is no good reason for that specific
method to fail if content-type indicated a larger payload.
Whether or not the processing fails or how it proceeds, should
be up to consumer of the stream and will likely have to do with
how `read` is implemented.

Fixes: quarkusio#17455
(cherry picked from commit 017c53c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/vertx kind/bug Something isn't working
Projects
None yet
Milestone
1.13.7.Final
Development

Successfully merging a pull request may close this issue.

Make VertxInputStream#available not fail on large content-type geoand/quarkus
4 participants
@gsmet @geoand @coperator @famod