hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Li (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10278) Refactor to make CallQueue pluggable
Date Tue, 18 Feb 2014 19:54:22 GMT

    [ 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)

Mime
View raw message