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

Fix unsupported request type error handling and catch exception #2582

Conversation

Arun-LinkedIn
Copy link
Contributor

Catch exception in NettyRequestResponseChannel.rejectRequests so that it is not propagated to request handler threads and cause server shutdown

Copy link
Collaborator

@JingQianCloud JingQianCloud left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -37,6 +36,7 @@ public class NettyServerRequestResponseChannel implements RequestResponseChannel
private final NetworkRequestQueue networkRequestQueue;
private final ServerMetrics serverMetrics;
private final ServerRequestResponseHelper requestResponseHelper;
protected static final Logger publicAccessLogger = LoggerFactory.getLogger("PublicAccessLogger");
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure how the LoggerFactory works. With that, will publicAccessLogger write to the public log instead of the ambry log?

Also, right now we are using LogManager instead of LoggerFactory for the PublicAccessLogger. I don't know the difference between them.
private static final Logger publicAccessLogger = LogManager.getLogger("PublicAccessLogger");

Copy link
Contributor Author

@Arun-LinkedIn Arun-LinkedIn Sep 20, 2023

Choose a reason for hiding this comment

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

Yeah, I think the Logger obtained via PublicAccessLogger name will write logs to public access logs. I think log4j2 has concept of "appenders" which allows us to choose the destination for a logger via configuration. If we see in internal AmbryLI configuration, the appender for PublicAccessLogger redirects logs to public access logs.

LogManager is used for structured logging. But I think we only use it for frontends. For servers, we are still using LoggerFactory. All the server public access logging happens in AmbryRequests.java.

This is my understanding :)

sendResponse(response, networkRequest, null);
} catch (IOException | InterruptedException e) {
} catch (Exception e) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

we should capture Throwable, instead of Exception.

@codecov-commenter
Copy link

Codecov Report

Patch coverage: 3.84% and project coverage change: -39.76% ⚠️

Comparison is base (6622e11) 72.51% compared to head (e55f295) 32.76%.

Additional details and impacted files
@@              Coverage Diff              @@
##             master    #2582       +/-   ##
=============================================
- Coverage     72.51%   32.76%   -39.76%     
+ Complexity    11375     4458     -6917     
=============================================
  Files           803      803               
  Lines         64660    64684       +24     
  Branches       7897     7897               
=============================================
- Hits          46890    21191    -25699     
- Misses        15203    41260    +26057     
+ Partials       2567     2233      -334     
Files Changed Coverage Δ
...a/com/github/ambry/network/NettyServerRequest.java 58.82% <0.00%> (-32.09%) ⬇️
...hub/ambry/network/ServerRequestResponseHelper.java 6.55% <0.00%> (-0.99%) ⬇️
...bry/network/NettyServerRequestResponseChannel.java 43.28% <8.33%> (-9.35%) ⬇️

... and 539 files with indirect coverage changes

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

@Arun-LinkedIn Arun-LinkedIn merged commit c731515 into linkedin:master Sep 20, 2023
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants