[
https://issues.apache.org/jira/browse/HBASE-18987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201750#comment-16201750
]
Anoop Sam John commented on HBASE-18987:
----------------------------------------
The value length can be upto Integer.MAX_VALUE - 1 as we use 4 bytes to store
that. But for the row length it is 2 bytes right? Then allowing
Integer.MAX_VALUE - 1 for RK length also correct?
As the createRegionName() adding some more bytes it crossed the Short MAX value
limit.
bq. int len = tableName.getName().length + 2 + id.length + (startKey == null?
0: startKey.length);
I believe we should check this while creating the split point. We should
consider the extra bytes to be added also and should limit the split point max
length as per that. Changing the RK max length for this case is not reasonable
IMO
> 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)
