[
https://issues.apache.org/jira/browse/HBASE-24588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17140320#comment-17140320
]
Viraj Jasani edited comment on HBASE-24588 at 6/19/20, 2:46 PM:
----------------------------------------------------------------
{quote}the calling context should handle the resolution of those futures in a
single place.
{quote}
HMaster should call future.get() for all tables after plans are submitted for
all tables. That might be better right? And if polling throws any Exception, we
log it only at one place: HMaster(caller) and we maintain a count say
normalizationPlanFailureCount and if it is helpful, maybe expose it in metric?
Thought?
was (Author: vjasani):
{quote}the calling context should handle the resolution of those futures in a
single place.
{quote}
HMaster should call future.get() for all tables after plans are submitted for
all tables? That might be better right? And if polling throws any Exception, we
log it only at one place: HMaster and we maintain a count say
splitPlanFailedCount, mergePlanFailedCount and if it is helpful, maybe expose
them as metrics? Thought?
> 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)
