[
https://issues.apache.org/jira/browse/PHOENIX-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680658#comment-16680658
]
Vincent Poon commented on PHOENIX-5005:
---------------------------------------
[~gjacoby] The lock isn't held the entire time during the loop, as lock.wait()
releases it.
But I added v2 with a max timeout just in case, and set to whatever the max
client timeout is.
For the record, all the code in preSplit and preClose, etc are all crappy
hacks. As discussed in PHOENIX-3111, we are doing unnatural things by trying
to write from a scan.
> 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
> Attachments: PHOENIX-5005.4.x-HBase-1.4.v1.patch,
> PHOENIX-5005.4.x-HBase-1.4.v2.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)
