bbeaudreault commented on code in PR #5424:
URL: https://github.com/apache/hbase/pull/5424#discussion_r1337788208
##########
hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/QuotaCache.java:
##########
@@ -160,6 +172,27 @@ protected boolean isExceedThrottleQuotaEnabled() {
return exceedThrottleQuotaEnabled;
}
+ /**
+ * Applies a request attribute user override if available, otherwise returns
the UGI's short
+ * username
+ * @param ugi The request's UserGroupInformation
+ */
+ private String getQuotaUserName(final UserGroupInformation ugi) {
+ if (userOverrideRequestAttributeKey == null) {
+ return ugi.getShortUserName();
+ }
+
+ Optional<RpcCall> rpcCall = RpcServer.getCurrentCall();
+ if (
+ rpcCall.isPresent()
+ &&
rpcCall.get().getRequestAttributes().containsKey(userOverrideRequestAttributeKey)
Review Comment:
I might recommend just looping the raw
`rpcCall.get().getHeader().getAttributes()` here. For a small N (as i expect
attributes to be), it is typically faster to iterate the list than to lookup in
a map. This is especially true if we have to actually build the map as well (as
we are likely to here). So in a vacuum, this call loops all the attributes and
populates a map (which involves hashcode and equals for each, not to mention
converting from ByteString to byte[] and string). Then we do a lookup, which
involves another hashcode and equals. On the other hand, a loop can exit out
early if a match is found and only requires equals.
So if we planned to do many operations on the map, it might start to pay off
to do those conversions. But if we are just looking for a single key in an
empty or very small list, it'd be cheaper to skip all of that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
