You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Zheng Hu (JIRA)" <ji...@apache.org> on 2018/11/12 03:32:00 UTC

[jira] [Comment Edited] (HBASE-21401) Sanity check in BaseDecoder#parseCell

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

Zheng Hu edited comment on HBASE-21401 at 11/12/18 3:31 AM:
------------------------------------------------------------

[~stack], Thanks for your replay.  

Read the comment in RB & JIRA.  Checked the master branch,  there isn't any checksum for request messages now, and I think the checksum calculation will have more time cost than the checkKeyValueBytes, because if n = bytes.length,  checksum need O( n ) time cost,  but checkKeyValueBytes need O(1) time cost ( it will skip to read the specific offsets & lens).  On the other hand,   the reason why we need checkKeyValueBytes is : the different hbase-client version may send the mis-encoding bytes,  the checkKeyValueBytes ensure that the good keyvalues will be accepted, and if find a bad keyvalues, it will provide the detail what's wrong with the bad keyvalues. 

and you said: 
> If a bug in the decoder, fix that rather than 'check' all values all the time?
that's some difficult for the server side  to decide how to correct the wrong keyvalue bytes.  So i think reject the bad keyvalue request is the right way.. 

Thanks. 




was (Author: openinx):
[~stack], Thanks for your replay.  

Read the comment in RB & JIRA.  Checked the master branch,  there isn't any checksum for request messages now, and I think the checksum calculation will have more time cost than the checkKeyValueBytes, because if n = bytes.length,  checksum need O(n) time cost,  but checkKeyValueBytes need O(1) time cost ( it will skip to read the specific offsets & lens).  On the other hand,   the reason why we need checkKeyValueBytes is : the different hbase-client version may send the mis-encoding bytes,  the checkKeyValueBytes ensure that the good keyvalues will be accepted, and if find a bad keyvalues, it will provide the detail what's wrong with the bad keyvalues. 

and you said: 
> If a bug in the decoder, fix that rather than 'check' all values all the time?
that's some difficult for the server side  to decide how to correct the wrong keyvalue bytes.  So i think reject the bad keyvalue request is the right way.. 

Thanks. 



> Sanity check in BaseDecoder#parseCell
> -------------------------------------
>
>                 Key: HBASE-21401
>                 URL: https://issues.apache.org/jira/browse/HBASE-21401
>             Project: HBase
>          Issue Type: Sub-task
>          Components: regionserver
>            Reporter: Zheng Hu
>            Assignee: Zheng Hu
>            Priority: Critical
>             Fix For: 3.0.0, 2.2.0, 2.0.3, 2.1.2
>
>         Attachments: HBASE-21401.v1.patch, HBASE-21401.v2.patch, HBASE-21401.v3.patch, HBASE-21401.v4.patch, HBASE-21401.v4.patch, HBASE-21401.v5.patch
>
>
> In KeyValueDecoder & ByteBuffKeyValueDecoder,  we pass a byte buffer to initialize the Cell without a sanity check (check each field's offset&len exceed the byte buffer or not), so ArrayIndexOutOfBoundsException may happen when read the cell's fields, such as HBASE-21379,  it's hard to debug this kind of bug. 
> An earlier check will help to find such kind of bugs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)