[
https://issues.apache.org/jira/browse/HBASE-17258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722000#comment-15722000
]
ramkrishna.s.vasudevan commented on HBASE-17258:
------------------------------------------------
bq. Now as per the new usage ways, if they are needed, we can add.
Ya it is needed now.
In rpcServer we have now
{code}
ByteBuffer[] bufsFromPool = null;
if (bbs.size() > 0) {
bufsFromPool = new ByteBuffer[bbs.size()];
bbs.toArray(bufsFromPool);
}
if (remain > 0) {
bbs.add(ByteBuffer.allocate(remain));
}
{code}
Now this remain could be anything. So it is better we make MBB more robust.
> MultiByteBuff#getXXX() has issues
> ---------------------------------
>
> Key: HBASE-17258
> URL: https://issues.apache.org/jira/browse/HBASE-17258
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Critical
> Attachments: HBASE-17258.patch
>
>
> MBB#getInt() - the relative getXXX() API has issues.
> {code}
> int remaining = this.curItem.remaining();
> if (remaining >= Bytes.SIZEOF_INT) {
> return this.curItem.getInt();
> }
> if (remaining == 0) {
> if (items.length - 1 == this.curItemIndex) {
> // means cur item is the last one and we wont be able to read a long.
> Throw exception
> throw new BufferUnderflowException();
> }
> this.curItemIndex++;
> this.curItem = this.items[this.curItemIndex];
> return this.curItem.getInt();
> }
> {code}
> Now here if the curItem does not have anything remaining in it we just go to
> the nextItem and from that we do a getInt. But we don't check if that item is
> big enough to return an int. This may not happen in most of the real cases
> but as an API it should handle that case. Since MBB are now used in the
> RpcServer#response there could be some on demand BB created that are smaller
> in sizes and it could lead to issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)