[ https://issues.apache.org/jira/browse/HBASE-22933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919587#comment-16919587 ]
Hudson commented on HBASE-22933: -------------------------------- Results for branch branch-2.2 [build #555 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/555/]: (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/555//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/555//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/branch-2.2/555//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 3. [see log for details|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/555//artifact/output-integration/hadoop-3.log]. (note that this means we didn't check the Hadoop 3 shaded client) > Do not need to kick reassign for rs group change any more > --------------------------------------------------------- > > Key: HBASE-22933 > URL: https://issues.apache.org/jira/browse/HBASE-22933 > Project: HBase > Issue Type: Improvement > Components: rsgroup > Reporter: Duo Zhang > Assignee: Duo Zhang > Priority: Major > Fix For: 3.0.0, 2.3.0, 2.2.2 > > > The old implementation is a bit strange, the isStuck method is like this: > {code} > public boolean isStuck() { > return isInState(State.FAILED_OPEN) && getProcedure() != null; > } > {code} > It can only return true when there are ongoing procedures. But if we have a > procedure, then the procedure will try to reassign region. Scheduling a new > procedure does not make sense here, at least for branch-2.2+. > I suggest we just remove the related code, since the default retry number for > assigning a region is Integer.MAX_VALUE. And even if user set this to small > value and finally the region is left in FAILED_OPEN state without a > procedure, HBCK2 is used to deal with this, it is not necessary to deal it > automatically. -- This message was sent by Atlassian Jira (v8.3.2#803003)