hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10278) Refactor to make CallQueue pluggable
Date Mon, 03 Feb 2014 19:06:10 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13889757#comment-13889757

Daryn Sharp commented on HADOOP-10278:

(Just noticed I didn't resubmit this comment after jira was having issues last week)

I see.  I'm a bit uneasy about the maintenance and reduced flexibility from a custom concrete
queue impl.   I haven't thought this through, but would it be feasible to do a swapout by
using an atomic ref for the callq and using offer and poll with timeouts?  Ex. a handler would
replace {{call = callQueue.take()}} with:
Call call;
do {
  call = callQueue.get().poll(100L, TimeUnit.MILLISECONDS));
} while (call == null);

Refreshing the queue would create a new queue, swap it into the atomic ref, then drain calls
in the prior queue and add to the new queue.  Handlers would consume at most 1 call during
the swap, and if they block on an empty queue the above code will cause them to switch over.
 Just a thought.

> 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.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

View raw message