[
https://issues.apache.org/jira/browse/PHOENIX-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168786#comment-16168786
]
Lars Hofhansl commented on PHOENIX-4214:
----------------------------------------
Nice tests. And fix seems to make sense.
So the worst scenario would be synchronous creation of a local index, right?
In that case we scan entire regions (in the worst case) and write the index
data out.
I guess in that case we could always cause a split during, and we should let
the write finish, or else the next retry will again cause a split. I think this
would handle this, as we're just blocking *new* write RPCs, correct?
> Scans which write should not block region split or close
> --------------------------------------------------------
>
> Key: PHOENIX-4214
> URL: https://issues.apache.org/jira/browse/PHOENIX-4214
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.12.0
> Reporter: Vincent Poon
> Attachments: splitDuringUpsertSelect_wip.patch
>
>
> PHOENIX-3111 introduced a scan reference counter which is checked during
> region preSplit and preClose. However, a steady stream of UPSERT SELECT or
> DELETE can keep the count above 0 indefinitely, preventing or greatly
> delaying a region split or close.
> We should try to avoid starvation of the split / close request, and
> fail/reject queries where appropriate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
