[
https://issues.apache.org/jira/browse/HADOOP-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915132#comment-13915132
]
Chris Li commented on HADOOP-10285:
-----------------------------------
Sure thing.
bq. refreshCallQueue calls will be accepted by both the datanode and the client
RPC services. Is the former necessary? It looks like DFSAdmin will only target
the client RPC service.
I don't think it's necessary on the datanode at this point. It doesn't hurt to
restart the datanode.
bq. For the refresh call to work the configuration must have been modified on
the server. Is the administrator required to do so manually before calling
refresh?
Yup. This is how the other refresh* calls work too I believe.
Do we need separate protocols for each Refresh... call? Perhaps we can't remove
existing protocols for backwards compatibility, but going forward can we have a
single protocol? What do you think?
Interesting idea, I also think it would be nice to have a return status on the
Refresh* calls too, because right now they're just void. Is that something we'd
want done in this patch, or a separate issue to refactor RefreshCallQueueProto
into something more generic?
> Admin interface to swap callqueue at runtime
> --------------------------------------------
>
> Key: HADOOP-10285
> URL: https://issues.apache.org/jira/browse/HADOOP-10285
> Project: Hadoop Common
> Issue Type: Sub-task
> Reporter: Chris Li
> Attachments: HADOOP-10285.patch, HADOOP-10285.patch,
> HADOOP-10285.patch, bisection-test.patch, bisection-test.patch,
> bisection-test.patch, bisection-test.patch, bisection-test.patch
>
>
> We wish to swap the active call queue during runtime in order to do
> performance tuning without restarting the namenode.
> This patch adds the ability to refresh the call queue on the namenode,
> through dfsadmin -refreshCallQueue
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
