[
https://issues.apache.org/jira/browse/HBASE-24588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146720#comment-17146720
]
Hudson commented on HBASE-24588:
--------------------------------
Results for branch master
[build #1769 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/1769/]: (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/1769/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/1769/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/1769/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.1, 2.4.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)
