[jira] [Resolved] (HBASE-18987) Raise value of HConstants#MAX_ROW_LENGTH

["Esteban Gutierrez (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HBASE-18987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Esteban Gutierrez resolved HBASE-18987.
---------------------------------------
    Resolution: Later

Solving as later since we could only do this with a new HFile format.

> Raise value of HConstants#MAX_ROW_LENGTH
> ----------------------------------------
>
>                 Key: HBASE-18987
>                 URL: https://issues.apache.org/jira/browse/HBASE-18987
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 1.0.0, 2.0.0
>            Reporter: Esteban Gutierrez
>            Assignee: Esteban Gutierrez
>            Priority: Minor
>         Attachments: HBASE-18987.master.001.patch, HBASE-18987.master.002.patch
>
>
> Short.MAX_VALUE hasn't been a problem for a long time but one of our customers ran into an  edgy case when the midKey used for the split point was very close to Short.MAX_VALUE. When the split is submitted, we attempt to create the new two daughter regions and we name those regions via {{HRegionInfo.createRegionName()}} in order to be added to META. Unfortunately, since {{HRegionInfo.createRegionName()}} uses midKey as the startKey {{Put}} will fail since the row key length will now fail checkRow and thus causing the split to fail.
> I tried a couple of alternatives to address this problem, e.g. truncating the startKey. But the number of changes in the code doesn't justify for this edge condition. Since we already use {{Integer.MAX_VALUE - 1}} for {{HConstants#MAXIMUM_VALUE_LENGTH}} it should be ok to use the same limit for the maximum row key. 



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