[ https://issues.apache.org/jira/browse/HBASE-24588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147345#comment-17147345 ]
Hudson commented on HBASE-24588: -------------------------------- Results for branch master [build #1771 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/1771/]: (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/1771/General_20Nightly_20Build_20Report/] (x) {color:red}-1 jdk8 hadoop2 checks{color} -- For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/master/1600//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/1771/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/] (/) {color:green}+1 jdk11 hadoop3 checks{color} -- For more information [see jdk11 report|https://builds.apache.org/job/HBase%20Nightly/job/master/1771/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/] (/) {color:green}+1 source release artifact{color} -- See build output for details. (/) {color:green}+1 client integration test{color} > Normalizer plan execution is not consistent between plan types > -------------------------------------------------------------- > > Key: HBASE-24588 > URL: https://issues.apache.org/jira/browse/HBASE-24588 > Project: HBase > Issue Type: Bug > Components: master, Normalizer > Affects Versions: 2.3.0 > Reporter: Nick Dimiduk > Assignee: Viraj Jasani > Priority: Major > Fix For: 3.0.0-alpha-1, 2.3.0 > > > I left a comment on a merged > [commit|https://github.com/apache/hbase/commit/5d0e0fc5fd09bddb2d766d1e24e28e472961f454#r39987289] > where a little discussion has blossomed. Right now the normalizer produces > two types of plans: "split" or "merge". The master receives the list of plans > and executes them in a simple loop. The way it does the actual execution is > delegated off to the plan implementation. > The bug I noticed is that the two implementations are subtly different. Both > use async APIs to submit procedures, but "split" blocks on completion while > "merge" does not. Furthermore, because "split" blocks, it's able to capture > any exception that's thrown, while "merge" cannot. > These implementations should be made consistent. My thinking at the moment is > this {{execute}} method should instead be named {{submit}}, creating and > returning the {{Future}} that represents whatever work it submitted, and the > calling context should handle the resolution of those futures in a single > place. -- This message was sent by Atlassian Jira (v8.3.4#803005)