[
https://issues.apache.org/jira/browse/PHOENIX-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680604#comment-16680604
]
Vincent Poon commented on PHOENIX-5005:
---------------------------------------
Turns out in-flight PHOENIX-4214 already made it such that operations already
in progress would fail once they get close to the max memstore size (see
commitBatch method). So it should be safe to do the same thing we do in
preClose()
1) block new writes
2) fail existing writes if they get close to max memstore size , so we don't
hit deadlock
3) wait for all other operations to finish
[~tdsilva] can you review?
> 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
> Priority: Major
> Attachments: PHOENIX-5005.4.x-HBase-1.4.v1.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)
