[
https://issues.apache.org/jira/browse/HBASE-22810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16910973#comment-16910973
]
stack commented on HBASE-22810:
-------------------------------
Ok. This did not make it into 2.0.6RC1 which just became 2.0.6. I moved fix
version to 2.0.7 though there will be no more releases on branch-2.0.
I just saw this issue and how it breaks TestFlushSnapshotFromClient. I looked
at the TestFlushSnapshotFromClient failures independently and to me the test
looked flakey anyways and was seemingly written flakey in the first place so
just removed it with the below commit. Did not go back to branch-1. After
seeing this issue, I was a mite reactionary it seems.
{code}
commit 05b88af057d35e247bf37b725f2735292f944387 (HEAD -> 2.0, origin/branch-2.0)
Author: stack <st...@apache.org>
Date: Mon Aug 19 14:25:21 2019 -0700
HBASE-22882 TestFlushSnapshotFromClient#testConcurrentSnapshottingAttempts
is flakey (was written flakey)
Addendum; just remove the test altogether
{code}
> Initialize an separate ThreadPoolExecutor for taking/restoring snapshot
> ------------------------------------------------------------------------
>
> Key: HBASE-22810
> URL: https://issues.apache.org/jira/browse/HBASE-22810
> Project: HBase
> Issue Type: Improvement
> Reporter: Zheng Hu
> Assignee: Zheng Hu
> Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0, 2.2.1, 2.1.6, 1.3.6, 1.4.11, 2.0.7
>
>
> In EventType class, we have the following definition, means taking snapshot
> & restoring snapshot are use the MASTER_TABLE_OPERATIONS Executor now.
> {code}
> /**
> * Messages originating from Client to Master.<br>
> * C_M_SNAPSHOT_TABLE<br>
> * Client asking Master to snapshot an offline table.
> */
> C_M_SNAPSHOT_TABLE (48, ExecutorType.MASTER_TABLE_OPERATIONS),
> /**
> * Messages originating from Client to Master.<br>
> * C_M_RESTORE_SNAPSHOT<br>
> * Client asking Master to restore a snapshot.
> */
> C_M_RESTORE_SNAPSHOT (49, ExecutorType.MASTER_TABLE_OPERATIONS),
> {code}
> But when I checked the MASTER_TABLE_OPERATIONS thread pool initialization, I
> see :
> {code}
> private void startServiceThreads() throws IOException{
> // ... some other code initializing ....
> // We depend on there being only one instance of this executor running
> // at a time. To do concurrency, would need fencing of enable/disable of
> // tables.
> // Any time changing this maxThreads to > 1, pls see the comment at
> // AccessController#postCompletedCreateTableAction
>
> this.executorService.startExecutorService(ExecutorType.MASTER_TABLE_OPERATIONS,
> 1);
> startProcedureExecutor();
> {code}
> That's to say, for CPs enable or disable table sequencely, we will create
> a ThreadPoolExecutor with threadPoolSize=1. Then we actually cann't
> accomplish the snapshoting concurrence even if they are total difference
> tables, says if there are two table snapshoting request, and the Table A cost
> 5min for snapshoting, then the Table B need to wait 5min and once Table A
> finish its snapshot , then Table B will start the snapshot.
> While we've setting the snapshot timeout, so it will be easy to timeout for
> table B snapshoting . Actually, we can create a separate thead pool for
> snapshot operations only.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
