[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-20 Thread Hudson (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1679#comment-1679
 ] 

Hudson commented on HBASE-22061:


Results for branch branch-2.2
[build #122 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/122/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/122//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/122//JDK8_Nightly_Build_Report_(Hadoop2)/]


(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/122//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for 
details|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/122//artifact/output-integration/hadoop-2.log].
 (note that this means we didn't run on Hadoop 3)


> SplitTableRegionProcedure should hold the lock of its daughter regions
> --
>
> Key: HBASE-22061
> URL: https://issues.apache.org/jira/browse/HBASE-22061
> Project: HBase
>  Issue Type: Bug
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0, 2.1, 2.2
>
> Attachments: HBASE-22061.master.001.patch, 
> HBASE-22061.master.002.patch
>
>
> Currently SplitTableRegionProcedure only hold the region of parent region. 
> But during processing of this procedure, after the daughter regions are 
> updated to meta, other procedures can grab the lock of them, which is the 
> situation we don't want to see.
>  So I think SplitTableRegionProcedure should hold the lock of parent region 
> and its daughter regions like MergeTableRegionsProcedure holding the lock of 
> merged region.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-20 Thread Hudson (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16797660#comment-16797660
 ] 

Hudson commented on HBASE-22061:


Results for branch branch-2
[build #1764 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1764/]: 
(/) *{color:green}+1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1764//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1764//JDK8_Nightly_Build_Report_(Hadoop2)/]


(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1764//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


(/) {color:green}+1 client integration test{color}


> SplitTableRegionProcedure should hold the lock of its daughter regions
> --
>
> Key: HBASE-22061
> URL: https://issues.apache.org/jira/browse/HBASE-22061
> Project: HBase
>  Issue Type: Bug
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0, 2.1, 2.2
>
> Attachments: HBASE-22061.master.001.patch, 
> HBASE-22061.master.002.patch
>
>
> Currently SplitTableRegionProcedure only hold the region of parent region. 
> But during processing of this procedure, after the daughter regions are 
> updated to meta, other procedures can grab the lock of them, which is the 
> situation we don't want to see.
>  So I think SplitTableRegionProcedure should hold the lock of parent region 
> and its daughter regions like MergeTableRegionsProcedure holding the lock of 
> merged region.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-20 Thread Hudson (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16797108#comment-16797108
 ] 

Hudson commented on HBASE-22061:


Results for branch master
[build #872 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/872/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/872//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/872//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/872//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


(/) {color:green}+1 client integration test{color}


> SplitTableRegionProcedure should hold the lock of its daughter regions
> --
>
> Key: HBASE-22061
> URL: https://issues.apache.org/jira/browse/HBASE-22061
> Project: HBase
>  Issue Type: Bug
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0, 2.1, 2.2
>
> Attachments: HBASE-22061.master.001.patch, 
> HBASE-22061.master.002.patch
>
>
> Currently SplitTableRegionProcedure only hold the region of parent region. 
> But during processing of this procedure, after the daughter regions are 
> updated to meta, other procedures can grab the lock of them, which is the 
> situation we don't want to see.
>  So I think SplitTableRegionProcedure should hold the lock of parent region 
> and its daughter regions like MergeTableRegionsProcedure holding the lock of 
> merged region.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-20 Thread Hadoop QA (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796796#comment-16796796
 ] 

Hadoop QA commented on HBASE-22061:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}  
0m  0s{color} | {color:orange} The patch doesn't appear to include any new or 
modified tests. Please justify why no new tests are needed for this patch. Also 
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
29s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  2m 
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
34s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
 9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
34s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}  
8m 49s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  2m 
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
33s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}144m 
50s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
22s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}185m 53s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22061 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12963050/HBASE-22061.master.002.patch
 |
| Optional Tests |  dupname  asflicense  javac  javadoc  unit  findbugs  
shadedjars  hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 64ebd76976c6 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct 
31 10:55:11 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / b4b4854371 |
| maven | version: Apache Maven 3.5.4 
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/16437/testReport/ |
| Max. process+thread count | 4849 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-19 Thread Jingyun Tian (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796838#comment-16796838
 ] 

Jingyun Tian commented on HBASE-22061:
--

Pushed to master, branch-2 and branch-2.2, thanks [~allan163] for reviewing.

> SplitTableRegionProcedure should hold the lock of its daughter regions
> --
>
> Key: HBASE-22061
> URL: https://issues.apache.org/jira/browse/HBASE-22061
> Project: HBase
>  Issue Type: Bug
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0, 2.1, 2.2
>
> Attachments: HBASE-22061.master.001.patch, 
> HBASE-22061.master.002.patch
>
>
> Currently SplitTableRegionProcedure only hold the region of parent region. 
> But during processing of this procedure, after the daughter regions are 
> updated to meta, other procedures can grab the lock of them, which is the 
> situation we don't want to see.
>  So I think SplitTableRegionProcedure should hold the lock of parent region 
> and its daughter regions like MergeTableRegionsProcedure holding the lock of 
> merged region.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-19 Thread Allan Yang (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795950#comment-16795950
 ] 

Allan Yang commented on HBASE-22061:


+1 for the patch

> SplitTableRegionProcedure should hold the lock of its daughter regions
> --
>
> Key: HBASE-22061
> URL: https://issues.apache.org/jira/browse/HBASE-22061
> Project: HBase
>  Issue Type: Bug
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Major
> Attachments: HBASE-22061.master.001.patch
>
>
> Currently SplitTableRegionProcedure only hold the region of parent region. 
> But during processing of this procedure, after the daughter regions are 
> updated to meta, other procedures can grab the lock of them, which is the 
> situation we don't want to see.
>  So I think SplitTableRegionProcedure should hold the lock of parent region 
> and its daughter regions like MergeTableRegionsProcedure holding the lock of 
> merged region.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-19 Thread Hadoop QA (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795882#comment-16795882
 ] 

Hadoop QA commented on HBASE-22061:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
10s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}  
0m  0s{color} | {color:orange} The patch doesn't appear to include any new or 
modified tests. Please justify why no new tests are needed for this patch. Also 
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
31s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  2m 
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
36s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m  
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
14s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red}  0m  
0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git 
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply 
{color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
31s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}  
8m 42s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  2m 
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
33s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}149m 
17s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
21s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}189m 58s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22061 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12962928/HBASE-22061.master.001.patch
 |
| Optional Tests |  dupname  asflicense  javac  javadoc  unit  findbugs  
shadedjars  hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux b2c7ca21ce24 4.4.0-138-generic #164~14.04.1-Ubuntu SMP Fri Oct 
5 08:56:16 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
 |
| git revision | master / f65bf79d1d |
| maven | version: Apache Maven 3.5.4 
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| whitespace | 
https://builds.apache.org/job/PreCommit-HBASE-Build/16423/artifact/patchprocess/whitespace-eol.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreComm

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-18 Thread Jingyun Tian (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795727#comment-16795727
 ] 

Jingyun Tian commented on HBASE-22061:
--

[~Apache9] Yes.
{code}
  protected LockState acquireLock(final MasterProcedureEnv env) {
if (env.getProcedureScheduler().waitRegions(this, getTableName(),
mergedRegion, regionsToMerge[0], regionsToMerge[1])) {
  try {
LOG.debug(LockState.LOCK_EVENT_WAIT + " " + 
env.getProcedureScheduler().dumpLocks());
  } catch (IOException e) {
// Ignore, just for logging
  }
  return LockState.LOCK_EVENT_WAIT;
}
return LockState.LOCK_ACQUIRED;
  }
{code}

> SplitTableRegionProcedure should hold the lock of its daughter regions
> --
>
> Key: HBASE-22061
> URL: https://issues.apache.org/jira/browse/HBASE-22061
> Project: HBase
>  Issue Type: Bug
>Reporter: Jingyun Tian
>Priority: Major
>
> Currently SplitTableRegionProcedure only hold the region of parent region. 
> But during processing of this procedure, after the daughter regions are 
> updated to meta, other procedures can grab the lock of them,  which is the 
> situation we don't want to see.
> So I think SplitTableRegionProcedure should hold the lock of parent region 
> and its daughter regions like MergeTableRegionsProcedure. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-18 Thread Jingyun Tian (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795731#comment-16795731
 ] 

Jingyun Tian commented on HBASE-22061:
--

Yes. It's not daughter region. It's merged region.

> SplitTableRegionProcedure should hold the lock of its daughter regions
> --
>
> Key: HBASE-22061
> URL: https://issues.apache.org/jira/browse/HBASE-22061
> Project: HBase
>  Issue Type: Bug
>Reporter: Jingyun Tian
>Priority: Major
>
> Currently SplitTableRegionProcedure only hold the region of parent region. 
> But during processing of this procedure, after the daughter regions are 
> updated to meta, other procedures can grab the lock of them,  which is the 
> situation we don't want to see.
> So I think SplitTableRegionProcedure should hold the lock of parent region 
> and its daughter regions like MergeTableRegionsProcedure. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-18 Thread Duo Zhang (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795728#comment-16795728
 ] 

Duo Zhang commented on HBASE-22061:
---

OK, so this should be a typo?

> SplitTableRegionProcedure should hold the lock of its daughter regions
> --
>
> Key: HBASE-22061
> URL: https://issues.apache.org/jira/browse/HBASE-22061
> Project: HBase
>  Issue Type: Bug
>Reporter: Jingyun Tian
>Priority: Major
>
> Currently SplitTableRegionProcedure only hold the region of parent region. 
> But during processing of this procedure, after the daughter regions are 
> updated to meta, other procedures can grab the lock of them,  which is the 
> situation we don't want to see.
> So I think SplitTableRegionProcedure should hold the lock of parent region 
> and its daughter regions like MergeTableRegionsProcedure. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (HBASE-22061) SplitTableRegionProcedure should hold the lock of its daughter regions

2019-03-18 Thread Duo Zhang (JIRA) 


[ 
https://issues.apache.org/jira/browse/HBASE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795724#comment-16795724
 ] 

Duo Zhang commented on HBASE-22061:
---

Do we hold the lock for the daughter region when merging?

> SplitTableRegionProcedure should hold the lock of its daughter regions
> --
>
> Key: HBASE-22061
> URL: https://issues.apache.org/jira/browse/HBASE-22061
> Project: HBase
>  Issue Type: Bug
>Reporter: Jingyun Tian
>Priority: Major
>
> Currently SplitTableRegionProcedure only hold the region of parent region. 
> But during processing of this procedure, after the daughter regions are 
> updated to meta, other procedures can grab the lock of them,  which is the 
> situation we don't want to see.
> So I think SplitTableRegionProcedure should hold the lock of parent region 
> and its daughter regions like MergeTableRegionsProcedure. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)