[
https://issues.apache.org/jira/browse/HBASE-19309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260840#comment-16260840
]
ramkrishna.s.vasudevan commented on HBASE-19309:
------------------------------------------------
Am seeing this issue now and did not realise there was a parent issue that
caused this. I read all the discussions there. I agree to all the points in
HBASE-18987.
bq.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.
This seems to be difficult in terms of impl but ideally we need to do some
thing like this only I believe.
Because in the place where we actually get the split key it is at the block
index layer and later in the Split code we get this split key and add all the
meta data like table name.
Should we also add a restriction on the length of TableName? In terms of
existing users this is going to be a problem if they have a table with big name.
> 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)
