bbeaudreault commented on code in PR #4967:
URL: https://github.com/apache/hbase/pull/4967#discussion_r1089688575
##########
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java:
##########
@@ -3616,8 +3620,9 @@ public ScanResponse scan(final RpcController controller,
final ScanRequest reque
if (region.getCoprocessorHost() != null) {
Boolean bypass = region.getCoprocessorHost().preScannerNext(scanner,
results, rows);
if (!results.isEmpty()) {
+ Object lastBlock = null;
for (Result r : results) {
- lastBlock.setValue(addSize(rpcCall, r, lastBlock.getValue()));
+ lastBlock = addSize(rpcCall, r, lastBlock);
Review Comment:
Ok I see what you're saying. Yes these blocks are not counted towards the
max size. Just counted for reporting metrics and slow log threshold.
These are two separate data sets, but I can link them. When creating the
maxQuotaResultSize, I can subtract rpcCall.getResponseBlockSize(). That will
account for the blocks accumulated in the coprocessor.
I won't need lastBlock. We can't really use that below now that we use
scanner context which is far more accurate than addSize estimation. We could
theoretically try piping it through all the way into HFileReaderImpl where we
record block sizes. But I don't think it's worth it for one block overlap.
I will make the change to subtract counter block size when setting limits on
ScannerContext.
--
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]
