[
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
{code}
int totalSize = in.readInt();
{code}
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?
{code}
public static ByteBuffer getDelimitedMessageAsByteBuffer(final Message m)
throws IOException {
if (m == null) return null;
int serializedSize = m.getSerializedSize();
int vintSize = CodedOutputStream.computeRawVarint32Size(serializedSize);
{code}
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 [[email protected]].
> 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
(v6.3.4#6332)
