Return-Path: Delivered-To: apmail-hadoop-hbase-dev-archive@minotaur.apache.org Received: (qmail 74026 invoked from network); 17 Jan 2010 20:45:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Jan 2010 20:45:15 -0000 Received: (qmail 30837 invoked by uid 500); 17 Jan 2010 20:45:15 -0000 Delivered-To: apmail-hadoop-hbase-dev-archive@hadoop.apache.org Received: (qmail 30788 invoked by uid 500); 17 Jan 2010 20:45:15 -0000 Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hbase-dev@hadoop.apache.org Delivered-To: mailing list hbase-dev@hadoop.apache.org Received: (qmail 30773 invoked by uid 99); 17 Jan 2010 20:45:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Jan 2010 20:45:15 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Jan 2010 20:45:14 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 5F572234C498 for ; Sun, 17 Jan 2010 12:44:54 -0800 (PST) Message-ID: <595998301.302321263761094389.JavaMail.jira@brutus.apache.org> Date: Sun, 17 Jan 2010 20:44:54 +0000 (UTC) From: "stack (JIRA)" To: hbase-dev@hadoop.apache.org Subject: [jira] Commented: (HBASE-2141) Flexible thread pool for RPC server In-Reply-To: <83335765.302261263760434377.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801498#action_12801498 ] stack commented on HBASE-2141: ------------------------------ For me, I'm not that mad about doing dev on hadoop rpc, or our subclass of it. I think we should start over. Start with an nio2-based rpc. Growing the children as per apache1 or bounding the threads allowed in as per apache2 can be a feature of the new rpc. > Flexible thread pool for RPC server > ----------------------------------- > > Key: HBASE-2141 > URL: https://issues.apache.org/jira/browse/HBASE-2141 > Project: Hadoop HBase > Issue Type: Improvement > Reporter: Andrew Purtell > Fix For: 0.21.0 > > > Having a bounded thread pool is important, so availability can degrade gracefully (more or less), as opposed to the whole regionserver becoming livelocked. But, we don't need for the pool to be preallocated as is done currently. How about changing the RPC server thread pool such that the user can specify a minimum and maximum number of handler threads? The pool would start with the minimum, allocate more up to the max to handle additional concurrency, then terminate unused threads after some time back down to the minimum. Then we can do things like set a maximum of 100 handlers or such without taking on the overhead of 100 threads until it is needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.