[
https://issues.apache.org/jira/browse/PHOENIX-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009101#comment-16009101
]
Chia-Ping Tsai commented on PHOENIX-3576:
-----------------------------------------
bq. Wouldn't it be easier to just create a different thread pool executor for
same thread execution (Executors.sameThreadExecutor()) in the
ParallelWriterIndexCommitter.setup() method instead of copy/pasting so much
code?
Nice catch. The committer is plugable so we just create the simple committer
and deploy its binary in our env to avoid invasive modification into source
code.
The patch is not completed. We need to catch regiontoobusyexception, wait
region to be free, and retry the update of local index. Otherwise, it is hard
to ensure that the updates of data and local index is atomic.
> The local index updates will be blocked when the region is preparing to split
> -----------------------------------------------------------------------------
>
> Key: PHOENIX-3576
> URL: https://issues.apache.org/jira/browse/PHOENIX-3576
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.9.0
> Reporter: Chia-Ping Tsai
> Fix For: 4.11.0
>
> Attachments: hbase-root-regionserver-node06.ncku.edu.tw.log,
> PHOENIX-3576.v0.patch
>
>
> ParallelWriterIndexCommitter uses the AP to update the local index after the
> region#batchMutate fails. If the region is splitting, all later updates will
> fail (RegionTooBusyException) due to the write lock. The AP will retry the
> failed updates until it reaches the retry threshold, so the read lock of
> region is released after a long time. The read lock blocks the HRegion#close,
> so the region splitting is also blocked.
> {noformat}
> try {
> if (allowLocalUpdates
> && env != null
> && tableReference.getTableName().equals(
>
> env.getRegion().getTableDesc().getNameAsString())) {
> try {
> throwFailureIfDone();
> IndexUtil.writeLocalUpdates(env.getRegion(),
> mutations, true);
> return null;
> } catch (IOException ignord) {
> // when it's failed we fall back to the
> standard & slow way
> if (LOG.isDebugEnabled()) {
> LOG.debug("indexRegion.batchMutate failed
> and fall back to HTable.batch(). Got error="
> + ignord);
> }
> }
> }
> table = factory.getTable(tableReference.get());
> throwFailureIfDone();
> table.batch(mutations);
> } catch (SingleIndexWriteFailureException e) {
> throw e;
> } catch (IOException e) {
> throw new
> SingleIndexWriteFailureException(tableReference.toString(), mutations, e);
> } catch (InterruptedException e) {
> // reset the interrupt status on the thread
> Thread.currentThread().interrupt();
> throw new
> SingleIndexWriteFailureException(tableReference.toString(), mutations, e);
> }
> finally{
> if (table != null) {
> table.close();
> }
> }
> return null;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
