HADOOP-18288. Total requests and total requests per sec served by RPC servers#4431
HADOOP-18288. Total requests and total requests per sec served by RPC servers#4431tomscut merged 5 commits intoapache:trunkfrom
Conversation
...-project/hadoop-common/src/main/java/org/apache/hadoop/fs/CommonConfigurationKeysPublic.java
Show resolved
Hide resolved
|
💔 -1 overall
This message was automatically generated. |
|
|
||
| NameNodeAdapter.getRpcServer(nn).refreshCallQueue(configuration); | ||
| assertEquals(1, NameNodeAdapter.getRpcServer(nn).getTotalRequests()); | ||
| assertTrue(NameNodeAdapter.getRpcServer(nn).getTotalRequests() > 0); |
There was a problem hiding this comment.
if you have an assertion where a useful message isn't autogenerated the way assertequals does, afraid you will need to add a message or use assertJ to describe the assert. sorry.
There was a problem hiding this comment.
I agree, this is bit painful for debugging purpose. Updated with assertJ as it has better APIs to deal with such conditions (assertThat(x).isGreaterThan(y)).
Updated with the same, thanks for the suggestion @steveloughran
There was a problem hiding this comment.
thanks! it is pretty verbose for the little things, but i find assertj lovely for complex things, especially collections
steveloughran
left a comment
There was a problem hiding this comment.
javadocs good, but now you've moved to assertTrue i have to esk for the failure message for the assert. think of whoever tries to debug a failing jenkins build: what information do they need.
assertj asserts are great here, FWIW
tomscut
left a comment
There was a problem hiding this comment.
On the whole, it looks good to me. Add some comments.
| long totalRequestsDiff = currentTotalRequests - lastSeenTotalRequests; | ||
| lastSeenTotalRequests = currentTotalRequests; | ||
| if ((currentTime - lastExecuted) > 0) { | ||
| double totalRequestsPerMillis = |
There was a problem hiding this comment.
The unit here is second, so the variable name should be changed.
| try { | ||
| RpcMetrics rpcMetrics = server.getRpcMetrics(); | ||
| assertEquals(0, rpcMetrics.getTotalRequests()); | ||
| assertEquals(0.0, rpcMetrics.getTotalRequestsPerSecond(), 0.0); |
There was a problem hiding this comment.
RpcMetrics#getTotalRequestsPerSecond return long, so we can make some change.
| assertEquals(0.0, rpcMetrics.getTotalRequestsPerSecond(), 0.0); | |
| assertEquals(0, rpcMetrics.getTotalRequestsPerSecond()); |
|
Thanks @tomscut, addressed comments. |
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
+1 from me, merge into trunk and branch-3.3 |
|
Thanks @virajjasani for your contribution! Thanks @steveloughran for your review! |
|
Hi @virajjasani , I found some conflicts when cherry-pick this to branch-3.3. For security, could you please submit a new PR to branch-3.3 separately? Thanks a lot! |
… servers (apache#4431) Reviewed-by: Steve Loughran <stevel@apache.org> Signed-off-by: Tao Li <tomscut@apache.org>
Description of PR
RPC Servers provide bunch of useful information like num of open connections, slow requests, num of in-progress handlers, RPC processing time, queue time etc, however so far it doesn't provide accumulation of all requests as well as current snapshot of requests per second served by the server. Exposing them would benefit from operational viewpoint in identifying how busy the servers have been and how much load they are currently serving in the presence of cluster wide high load.
How was this patch tested?
Local dev cluster and UT.
For code changes: