[ https://issues.apache.org/jira/browse/HBASE-15437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry He updated HBASE-15437: ----------------------------- Attachment: HBASE-15437-v2.patch Attached a patch with a different approach. [~anoop.hbase], what do you think? > Response size calculated in RPCServer for warning tooLarge responses does NOT > count CellScanner payload > ------------------------------------------------------------------------------------------------------- > > Key: HBASE-15437 > URL: https://issues.apache.org/jira/browse/HBASE-15437 > Project: HBase > Issue Type: Bug > Components: IPC/RPC > Reporter: deepankar > Assignee: deepankar > Attachments: HBASE-15437-v1.patch, HBASE-15437-v2.patch, > HBASE-15437.patch > > > After HBASE-13158 where we respond back to RPCs with cells in the payload , > the protobuf response will just have the count the cells to read from > payload, but there are set of features where we log warn in RPCServer > whenever the response is tooLarge, but this size now is not considering the > sizes of the cells in the PayloadCellScanner. Code form RPCServer > {code} > long responseSize = result.getSerializedSize(); > // log any RPC responses that are slower than the configured warn > // response time or larger than configured warning size > boolean tooSlow = (processingTime > warnResponseTime && > warnResponseTime > -1); > boolean tooLarge = (responseSize > warnResponseSize && warnResponseSize > > -1); > if (tooSlow || tooLarge) { > // when tagging, we let TooLarge trump TooSmall to keep output simple > // note that large responses will often also be slow. > logResponse(new Object[]{param}, > md.getName(), md.getName() + "(" + param.getClass().getName() + > ")", > (tooLarge ? "TooLarge" : "TooSlow"), > status.getClient(), startTime, processingTime, qTime, > responseSize); > } > {code} > Should this feature be not supported any more or should we add a method to > CellScanner or a new interface which returns the serialized size (but this > might not include the compression codecs which might be used during response > ?) Any other Idea this could be fixed ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)