hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15202) Reduce garbage while setting response
Date Tue, 02 Feb 2016 05:54:39 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15127713#comment-15127713

ramkrishna.s.vasudevan commented on HBASE-15202:

bq. Or is it that our protocol expects to see a non-vint'd int at this stage?
Yes that is the reason. Infact wanted to go with existing int related APIs in COS. But here
in RpcClientImpl 
int totalSize = in.readInt();
Here we want the way that DataInputStream can decode it. Hence we have to go with the byte[]
way of writing int.
bq.If so, might want to doc what is going on with a comment.
Okie. Will add comment.
bq.Should we take care we don't overflow int calculating the message size?
  public static ByteBuffer getDelimitedMessageAsByteBuffer(final Message m) throws IOException
    if (m == null) return null;
    int serializedSize = m.getSerializedSize();
    int vintSize = CodedOutputStream.computeRawVarint32Size(serializedSize);
Previously also we were doing the same. Am not sure whether the message sizes will overflow
int because they are given by the Protobuf Message APIs. If it had the problem of overflowing
then we should have had the same problem previously also?
Thanks for the immediate review [~saint.ack@gmail.com].

> Reduce garbage while setting response
> -------------------------------------
>                 Key: HBASE-15202
>                 URL: https://issues.apache.org/jira/browse/HBASE-15202
>             Project: HBase
>          Issue Type: Sub-task
>          Components: regionserver
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>            Priority: Minor
>             Fix For: 2.0.0
>         Attachments: HBASE-15202.patch
> Probably this can move under HBASE-15177.  During RpcServer#setResponse we do IPCUtil.getDelimitedMessageAsByteBuffer
for the header and result. This internally creates a byte[], CodedOutputStream and a BB. Then
the totalSize is also wrapped in a BB. 
> Finally all these BB are passed to BufferChain along with the Cellblock.
> This JIRA is to reduce the number of objects that we create here and allow one BB from
this header, result and total Size along with one CodedOutputStream and pass this BB along
with the Cellblocks to the Bufferchain. From the JMC tool can observe around 2% lesser object
allocation arising out of these objects. 

This message was sent by Atlassian JIRA

View raw message