You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "dennislee (JIRA)" <ji...@apache.org> on 2014/11/19 05:38:34 UTC
[jira] [Created] (HBASE-12531) bug in cachedataonwrite
dennislee created HBASE-12531:
----------------------------------
Summary: bug in cachedataonwrite
Key: HBASE-12531
URL: https://issues.apache.org/jira/browse/HBASE-12531
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.98.6.1
Reporter: dennislee
when configuring {color:red}hbase.rs.cacheblocksonwrite{color} as true on a region server ,or setting cacheDataOnWrite as true on a column family in a table ,we flush the header bytes,ondisk bytebuffer and checksum bytes to disk,but only store the header and uncompressedBytesWithoutHeader to the block cache .
so if we read a block from block cache which cached on write ,the method {color:red} getBufferWithoutHeader{color}of{color:red} org.apache.hadoop.hbase.io.hfile.HFileBlock{color} will cut off the head and checksum bytes,even if the checksum was never written ,and then we get a IllegalArgumentException thrown by ByteBuffer cause there is not enough bytes to read or skip at the end of the ByteBuffer.
I fixed this problem but I don't know how to commit a patch ,so I paste my code here :
{code:title=org.apache.hadoop.hbase.io.hfile.HFileBlock.java|borderStyle=solid}
public ByteBuffer getBufferWithoutHeader() {
int length,lengthWithoutHeader=buf.limit()-headerSize(),lengthWithoutHeaderAndCheckSum=lengthWithoutHeader - totalChecksumBytes();
if(lengthWithoutHeader==uncompressedSizeWithoutHeader){ // NO check sum tail
length=lengthWithoutHeader;
} else if(lengthWithoutHeaderAndCheckSum==uncompressedSizeWithoutHeader){ // has check sum tail
length=lengthWithoutHeaderAndCheckSum;
} else {
throw new IllegalArgumentException(this.toString()+",this block may be crashed");
}
ByteBuffer buffer =ByteBuffer.wrap(buf.array(),
buf.arrayOffset() + headerSize(),length)//length
.slice();
return buffer;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)