-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
HBASE-26727 Fix CallDroppedException reporting #4088
Conversation
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
13f284b
to
2fc2d5f
Compare
@@ -62,4 +63,5 @@ | |||
void quotaExceededException(); | |||
void rpcThrottlingException(); | |||
void callDroppedException(); | |||
void callTimedOut(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this in this PR because it's a type of call drop that can happen a lot under excess load. I did not roll it into callDroppedException, because it does not manifest as a CallDroppedException on the client side.
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
@@ -222,6 +223,7 @@ public void drop() { | |||
call.setResponse(null, null, CALL_DROPPED_EXCEPTION, "Call dropped, server " | |||
+ (address != null ? address : "(channel closed)") + " is overloaded, please retry."); | |||
call.sendResponseIfReady(); | |||
this.rpcServer.getMetrics().exception(CALL_DROPPED_EXCEPTION); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do we call this method in the past? Will this introduce double accounting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell, we do not report them. We added this exception in https://issues.apache.org/jira/browse/HBASE-26623, but the problem is when we drop a call here it doesn't end up hitting any of the other invocations of this method. So the value is always 0 despite throwing these exceptions to clients.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typically this is called in a few places, for example in RpcServer or in a few try/catches in RSRpcServices. But a couple exceptions need to be handled a level above this. For example CallQueueTooBigException is handled in the connection and RequestTooBig in the netty frame decoder.
So this exception is another example of a special case like CallQueueTooBig/RequestTooBig, that doesn't get handled by the default try/catches we have in RpcServer/RSRpcServices.
@Apache9 any other thoughts here? Would love to get it merged, it's been working ok for us. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Apache9 I assume you have no objection to merging but please lmk if you do. Otherwise will merge this tomorrow.
Signed-off-by: Andrew Purtell <[email protected]>
Signed-off-by: Andrew Purtell <[email protected]>
No description provided.