-
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -109,6 +109,7 @@ public void run() { | |
call.setStartTime(EnvironmentEdgeManager.currentTime()); | ||
if (call.getStartTime() > call.getDeadline()) { | ||
RpcServer.LOG.warn("Dropping timed out call: " + call); | ||
this.rpcServer.getMetrics().callTimedOut(); | ||
return; | ||
} | ||
this.status.setStatus("Setting up call"); | ||
|
@@ -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 commentThe 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 commentThe 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 commentThe 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. |
||
} catch (ClosedChannelException cce) { | ||
InetSocketAddress address = rpcServer.getListenerAddress(); | ||
RpcServer.LOG.warn(Thread.currentThread().getName() + ": caught a ClosedChannelException, " + | ||
|
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.