[
https://issues.apache.org/jira/browse/HADOOP-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904494#comment-13904494
]
Chris Li commented on HADOOP-10278:
-----------------------------------
bq. plus we should be using CAS to swap the queue ref to prevent races
Just for clarity: currently CallQueueManager.swapQueue isn't threadsafe, since
the Server's calling method is synchronized. Are we trying to make swapQueue
threadsafe, or are we trying to be even safer to make sure puts don't get left
behind? If it's the later only, we can continue to use set() instead of CAS.
Making swapQueue concurrent sounds like more hassle than it's worth.
> 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-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)
