[
https://issues.apache.org/jira/browse/HADOOP-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905983#comment-13905983
]
Chris Li commented on HADOOP-10278:
-----------------------------------
Thanks for checking out the patch, Arapit
Actually, the admin can only refresh the callQueue on the namenode today. This
is the only case I've targeted, since the namenode can't be easily restarted.
Thinking of what daemons might benefit:
* Namenode is what swapping was made for, since the NN can't be restarted to
refresh the queue so easily
* Datanodes, nodemanagers can be restarted at will, so it's not as useful
* Resourcemanager maybe, but I'm not sure whether QoS on the RM solves a
problem yet
Also, we allow swaps between the same queue, since the user may adjust features
of the queue (today that might be queue size, later on it would be qos
parameters) at runtime.
> Refactor to make CallQueue pluggable
> ------------------------------------
>
> Key: HADOOP-10278
> URL: https://issues.apache.org/jira/browse/HADOOP-10278
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: ipc
> Reporter: Chris Li
> Assignee: Chris Li
> Attachments: HADOOP-10278-atomicref-adapter.patch,
> HADOOP-10278-atomicref-adapter.patch, HADOOP-10278-atomicref-adapter.patch,
> HADOOP-10278-atomicref-adapter.patch, HADOOP-10278-atomicref-rwlock.patch,
> HADOOP-10278-atomicref.patch, HADOOP-10278-atomicref.patch,
> HADOOP-10278-atomicref.patch, HADOOP-10278-atomicref.patch,
> HADOOP-10278.patch, HADOOP-10278.patch
>
>
> * Refactor CallQueue into an interface, base, and default implementation that
> matches today's behavior
> * Make the call queue impl configurable, keyed on port so that we minimize
> coupling
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
