[
https://issues.apache.org/jira/browse/HADOOP-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14015884#comment-14015884
]
Chris Li commented on HADOOP-10376:
-----------------------------------
Hi Arapit, thanks for the suggestions.
Optional identifier sounds good.
RefreshResponse:
One use case of multiple handlers is for refreshing something on two servers
running on two ports. We would ideally like to return a repeated custom message
type which includes returnCode, userMessage, and senderName (which becomes
important when you have multiple handlers). And then that opens another issue
with how to have a user-readable senderName.
Perhaps supporting multiple handlers isn't worth the hassle?
RefreshRegistry:
Changes sound good if we need to support multiple handlers.
DFSAdmin:
Args are sent as an array of strings, no post-processing done.
Not sure if it needs to be there, but other refresh calls are able to infer the
host:port based on the protocol used (and the refresh protocols they use are
specific to NN or DN) whereas a generic protocol would not.
-------
It seems like a handful of these changes depend on whether or not it supports
one identifier to many handler mappings. In the process the code gets more
complex since we're now dealing with collections of responses.
Let me know if the feature sounds useful, otherwise I can remove it to maintain
simplicity.
> 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)
