hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15064) Possbile Bug in MultiByteBuffer
Date Tue, 05 Jan 2016 06:46:39 GMT

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

Anoop Sam John commented on HBASE-15064:
----------------------------------------

Thanks for the review Stack.
bq. Only odd thing is the location of the test. Is there not a better place for it than its
own class?
I think it is fine as a UT.  The issue is clearly coming up.  The issue was that even if we
are at the end of the MBB, the hasRemaining return true. It is not an issue with MBB as such.
It as an issue with ByteBufferArray#asSubBuffer() which returns the 0 length BB as the last
buffer within MBB.  That is why I thought a UT for ByteBufferArray#asSubBuffer()  for hasRemaining()
is good enough.

It might be difficult to mock the same situation in an FT which is doing the actual cells
read from a Scanner. Because this will happen for the HFileBlock read from the end of the
bucket cache.


> Possbile Bug in MultiByteBuffer
> -------------------------------
>
>                 Key: HBASE-15064
>                 URL: https://issues.apache.org/jira/browse/HBASE-15064
>             Project: HBase
>          Issue Type: Bug
>          Components: io
>    Affects Versions: 2.0.0
>            Reporter: deepankar
>            Assignee: Anoop Sam John
>            Priority: Critical
>             Fix For: 2.0.0
>
>         Attachments: HBASE-15064.patch
>
>
> While running the newer patches on our production system, I saw this error come couple
of times 
> {noformat}
> ipc.RpcServer: Unexpected throwable object 
> 2016-01-01 16:42:56,090 ERROR [B.defaultRpcServer.handler=20,queue=20,port=60020] ipc.RpcServer:
Unexpected throwable object 
> java.nio.BufferUnderflowException
> at java.nio.Buffer.nextGetIndex(Buffer.java:500)
> at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:249)
> at org.apache.hadoop.hbase.nio.MultiByteBuff.get(MultiByteBuff.java:494)
> at org.apache.hadoop.hbase.io.encoding.FastDiffDeltaEncoder$1.decode(FastDiffDeltaEncoder.java:402)

> at org.apache.hadoop.hbase.io.encoding.FastDiffDeltaEncoder$1.decodeNext(FastDiffDeltaEncoder.java:517)

> at org.apache.hadoop.hbase.io.encoding.BufferedDataBlockEncoder$BufferedEncodedSeeker.next(BufferedDataBlockEncoder.java:815)
> at org.apache.hadoop.hbase.regionserver.StoreFileScanner.next(StoreFileScanner.java:138)
> {noformat}
> Looking at the get code 
> {code}
> if (this.curItem.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.get();
> {code}
> Can the new currentItem have zero elements (position == limit), does it make sense to
change the {{if}} to {{while}} ? {{while (this.curItem.remaining() == 0)}}. This logic is
repeated may make sense abstract to a new function if we plan to change to  {{if}} to {{while}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message