[
https://issues.apache.org/jira/browse/ACCUMULO-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075179#comment-14075179
]
David Medinets commented on ACCUMULO-3021:
------------------------------------------
That makes sense. I imagine the code that picks a split point could check the
length of the row then generating an error message instead of splitting if it
is too long. But I can also imagine that if one split point is too long
probably all of them would be too long because of design choices so the tablet
would never split.
> Limit size of split rows
> ------------------------
>
> Key: ACCUMULO-3021
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3021
> Project: Accumulo
> Issue Type: Improvement
> Affects Versions: 1.4.0
> Reporter: Keith Turner
> Fix For: 1.7.0
>
>
> Just ran into an issue where a very large split row was added to Accumulo.
> The large split row caused the metadata table to split and was pushed up into
> the root tablet. This caused the root tablet to become unresponsive as many
> clients and tservers tried to scan the root tablet. Had to write a custom
> utility for 1.4 to fix this.
> I am curious if 1.5 would have been able to merge it away. Even if 1.5 could
> merge it away, the root tablet becoming unresponsive was really bad. It took
> a lot of poking and proding to get the system to anything. It would be best
> to avoid this situation altogether.
> Could make the max split size configurable. This config would be used to
> limit automatic and user added splits.
--
This message was sent by Atlassian JIRA
(v6.2#6252)