[
https://issues.apache.org/jira/browse/PHOENIX-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692092#comment-16692092
]
Vincent Poon commented on PHOENIX-5005:
---------------------------------------
I don't think this is necessarily related to PHOENIX-5007, since this is for a
corner case where splits are not retried due to balancer movement of regions.
It could be related if DELETEs can trigger splits as well. But then we'd see
an issue with UPSERT SELECT performance as well.
> Server-side delete / upsert-select potentially blocked after a split
> --------------------------------------------------------------------
>
> Key: PHOENIX-5005
> URL: https://issues.apache.org/jira/browse/PHOENIX-5005
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.14.1
> Reporter: Vincent Poon
> Assignee: Vincent Poon
> Priority: Major
> Fix For: 4.15.0
>
> Attachments: PHOENIX-5005.4.x-HBase-1.4.v1.patch,
> PHOENIX-5005.4.x-HBase-1.4.v2.patch, PHOENIX-5005.4.x-HBase-1.4.v3.patch
>
>
> After PHOENIX-4214, we stop inbound writes after a split is requested, to
> avoid split starvation.
> However, it seems there can be edge cases, depending on the split policy,
> where a split is not retried. For example, IncreasingToUpperBoundSplitPolicy
> relies on the count of regions, and balancer movement of regions at t1 could
> make it such that the SplitPolicy triggers at t0 but not t2.
> However, after the first split request, in UngroupedAggregateRegionObserver
> the flag to block inbound writes is flipped indefinitely.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
