[
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:
{code}
Call call;
do {
call = callQueue.get().poll(100L, TimeUnit.MILLISECONDS));
} while (call == null);
{code}
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
(v6.1.5#6160)
