[
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)
