Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Tue, 28 Jan 2014 21:19:32 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12691135.1390601342496.102.1390943972106@arcas>
In-Reply-To: <JIRA.12691135.1390601342496@arcas>
References: <JIRA.12691135.1390601342496@arcas>
Subject: [jira] [Commented] (HADOOP-10278) Refactor to make CallQueue
 pluggable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Daryn Sharp commented on HADOOP-10278:
--------------------------------------

Upon quick glance it looks much cleaner.  Questions:
# What advantage will the custom fifo call queue offer over a standard java queue?
# Instead of the new base class providing a concrete queue implementation (locking and all), is it possible for the custom queues to using a containing relationship with a standard java queue?

> 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: subtask1.2.patch, subtask1.3.patch, subtask1.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)