hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Li (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10376) Refactor refresh*Protocols into a single generic refreshConfigProtocol
Date Fri, 06 Jun 2014 01:02:22 GMT

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

Chris Li commented on HADOOP-10376:
-----------------------------------

Hi Arapit,

If we make this feature namenode only, it would remove the requirement to specify the target,
but it would leave certain situations ambiguous, such as what should happen in the case of
HA. I suppose it's a matter of philosophy, but I wanted to make this intentionally agnostic,
so it would work regardless of what service is targeted, whether HA is enabled for RMs or
NNs or other things are developed in the future.

Perhaps it can offer both? It would ask the user to provide the service to refresh as host:port,
or Namenode/ResourceManager which would refresh on all the machines in HA or any future configurations
such as a quorum. Maybe that's also another patch.

I'll also switch it back to 1-to-1 mappings, since the added complexity turns out to be too
much after I tried it.

> Refactor refresh*Protocols into a single generic refreshConfigProtocol
> ----------------------------------------------------------------------
>
>                 Key: HADOOP-10376
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10376
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Chris Li
>            Assignee: Chris Li
>            Priority: Minor
>         Attachments: HADOOP-10376.patch, HADOOP-10376.patch, RefreshFrameworkProposal.pdf
>
>
> See https://issues.apache.org/jira/browse/HADOOP-10285
> There are starting to be too many refresh*Protocols We can refactor them to use a single
protocol with a variable payload to choose what to do.
> Thereafter, we can return an indication of success or failure.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message