[
https://issues.apache.org/jira/browse/HBASE-18987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202080#comment-16202080
]
Anoop Sam John commented on HBASE-18987:
----------------------------------------
bq. truncate approach might be the only alternative for now.
Yep. The split point has to limit its length considering the extra bytes
length we will take put put this in META region.
> 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)
