[
https://issues.apache.org/jira/browse/HBASE-9189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13736509#comment-13736509
]
Jean-Marc Spaggiari commented on HBASE-9189:
--------------------------------------------
{quote}
What was the implication of this? We'd get a split request, but then not split
because there are unsplittable stores?
{quote}
Regions with references will be marked as "splittable". So when the memstore
flush and check for compactions, even if there is a reference file they might
emit a split request.
However, in the SplitRequest, there is a check for "st.prepare" which will
validate if region is splittable which, in turn, will verify if there is
references. And if any, will wait. So impact seems to be just few more pending
threads waiting for the references on the stores to be removed but I'm not 100%
sure if it's the only impact.
Also, DelimitedKeyPrefixRegionSplitPolicy and KeyPrefixRegionSplitPolicy are
extending IncreasingToUpperBoundRegionSplitPolicy so are impacted the same way.
> IncreasingToUpperBoundRegionSplitPolicy.shouldSplit() should check all the
> stores before returning.
> ---------------------------------------------------------------------------------------------------
>
> Key: HBASE-9189
> URL: https://issues.apache.org/jira/browse/HBASE-9189
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.95.1, 0.94.10, 0.96.0
> Reporter: Jean-Marc Spaggiari
> Assignee: Jean-Marc Spaggiari
> Attachments: HBASE-9189-v0-0.94.patch, HBASE-9189-v0-trunk.patch,
> HBASE-9189-v1-0.94.patch
>
>
> IncreasingToUpperBoundRegionSplitPolicy.shouldSplit() return as soon as it
> found any store big enough to be split. However, it should first go trough
> all all the stores to make sure they are all splittable before returning.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
