[
https://issues.apache.org/jira/browse/HADOOP-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Li updated HADOOP-10278:
------------------------------
Attachment: HADOOP-10278-atomicref.patch
Sure thing, patch updated with atomicref version
Potential issue?
>From the [BlockingQueue
>documentation|http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/BlockingQueue.html#poll(long,
> java.util.concurrent.TimeUnit)]: "drainTo: ...the behavior of this operation
>is undefined if the specified collection is modified while the operation is in
>progress."
On Performance:
* The time can be increased since queue swaps should be rare, maybe even pegged
to ipc.client.connect.timeout or made configurable
* The performance hit will probably increase with more handler threads too
* Even though the server CPU time increased, the throughput wasn't really
affected, so it's definitely not the bottleneck (at least not on my machine)
> 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
> Attachments: HADOOP-10278-atomicref.patch, HADOOP-10278.patch,
> subtask1.3.patch, subtask1.4.patch, subtask1.5.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)
