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.

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

Avoid closing response stream while downloading instance logs #14730

Merged
merged 2 commits into from
Jan 17, 2025

Conversation

shounakmk219
Copy link
Collaborator

@shounakmk219 shounakmk219 commented Dec 30, 2024

Description

Due to the response stream being closed on controller, client is unable to download the logs from other instances and facing

2024/12/24 08:11:46.111 ERROR [WebApplicationExceptionMapper] [grizzly-http-server-0] Server error: 
org.apache.hc.core5.http.StreamClosedException: Stream already closed

builder.contentLocation(uri);
builder.header(HttpHeaders.CONTENT_LENGTH, httpResponse.getEntity().getContentLength());
return builder.build();
CloseableHttpResponse httpResponse = _fileUploadDownloadClient.getHttpClient().execute(requestBuilder.build());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not clear to me why this may end up closing the resource for other instances and specially it is not clear to me who is closing this closeable now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah even I am not 100% sure but my understanding is that while controller is streaming log file from other instance its acting like a proxy and passing the same stream to the client/caller. Right now controller is closing the stream before client consumes it.
Maybe jersey is managing closing the stream as we don't handle it in /loggers/download flow as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also very confused. Does this change intentionally leak connection?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given these downloads may be large, we need to be sure we are cleaning these resources in a correct fashion. Alternatively we can dump the content of the stream to a file and use that file to stream data to the incoming request, but then we will need to be sure we end up deleting the file

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the code to handle the connection properly. Thanks a lot @gortiz for helping out with the right approach!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kudos to @KKcorps, who gave me the idea of asking Claude. 😆

@codecov-commenter
Copy link

codecov-commenter commented Dec 30, 2024

Codecov Report

Attention: Patch coverage is 0% with 20 lines in your changes missing coverage. Please review.

Project coverage is 63.73%. Comparing base (59551e4) to head (1c03af8).
Report is 1592 commits behind head on master.

Files with missing lines Patch % Lines
...ontroller/api/resources/PinotControllerLogger.java 0.00% 20 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master   #14730      +/-   ##
============================================
+ Coverage     61.75%   63.73%   +1.98%     
- Complexity      207     1611    +1404     
============================================
  Files          2436     2708     +272     
  Lines        133233   151225   +17992     
  Branches      20636    23345    +2709     
============================================
+ Hits          82274    96385   +14111     
- Misses        44911    47597    +2686     
- Partials       6048     7243    +1195     
Flag Coverage Δ
custom-integration1 100.00% <ø> (+99.99%) ⬆️
integration 100.00% <ø> (+99.99%) ⬆️
integration1 100.00% <ø> (+99.99%) ⬆️
integration2 0.00% <ø> (ø)
java-11 63.71% <0.00%> (+2.00%) ⬆️
java-21 63.62% <0.00%> (+2.00%) ⬆️
skip-bytebuffers-false 63.73% <0.00%> (+1.98%) ⬆️
skip-bytebuffers-true 63.61% <0.00%> (+35.88%) ⬆️
temurin 63.73% <0.00%> (+1.98%) ⬆️
unittests 63.73% <0.00%> (+1.98%) ⬆️
unittests1 56.30% <ø> (+9.41%) ⬆️
unittests2 34.04% <0.00%> (+6.31%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@gortiz gortiz merged commit 44b07b0 into apache:master Jan 17, 2025
20 of 21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants