[jira] [Commented] (HBASE-19309) Lower HConstants#MAX_ROW_LENGTH as guardrail in order to avoid HBASE-18987

["Anoop Sam John (JIRA)" <ji...@apache.org>]

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

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

So for this, do we need to reduce the max rk size globally?  When the split happens and the split key is been generated, can we do truncation to make sure the length is < this new value (which is lesser than Short.MAX_VALUE).    Also lesser till what value?  It all depends on what are all added to it to create the Put to META right? Eg: u say table name.  So what if there a crazy very long table name?  I feel like this has to be handled there at split code area only.  Get the split key which is less that max RK length. And then check by adding the extra things like tabName, where we reach wrt put's rk length.  Accordingly truncate the split key.  (I did not see any code around this area and not sure how easy or diff it will be).

> Lower HConstants#MAX_ROW_LENGTH as guardrail in order to avoid HBASE-18987
> --------------------------------------------------------------------------
>
>                 Key: HBASE-19309
>                 URL: https://issues.apache.org/jira/browse/HBASE-19309
>             Project: HBase
>          Issue Type: Bug
>          Components: HFile, regionserver
>            Reporter: Esteban Gutierrez
>
> As discussed in HBASE-18987. A problem of having a row about the maximum size of a row (Short.MAX_VALUE) is when a split happens, there is a possibility that the midkey could be that row and the Put created to add the new entry in META will exceed the maximum row size since the new row key will include the table name and that will cause the split to abort. Since is not possible to raise that row key size in HFileV3, a reasonable solution is to reduce the maximum size of row key in order to avoid exceeding Short.MAX_VALUE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)