Return-Path: Delivered-To: apmail-hadoop-common-dev-archive@www.apache.org Received: (qmail 25211 invoked from network); 30 Mar 2011 00:04:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Mar 2011 00:04:45 -0000 Received: (qmail 85358 invoked by uid 500); 30 Mar 2011 00:04:43 -0000 Delivered-To: apmail-hadoop-common-dev-archive@hadoop.apache.org Received: (qmail 85199 invoked by uid 500); 30 Mar 2011 00:04:43 -0000 Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-dev@hadoop.apache.org Delivered-To: mailing list common-dev@hadoop.apache.org Received: (qmail 84991 invoked by uid 99); 30 Mar 2011 00:04:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Mar 2011 00:04:43 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Mar 2011 00:04:42 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id CD3B68674A for ; Wed, 30 Mar 2011 00:04:05 +0000 (UTC) Date: Wed, 30 Mar 2011 00:04:05 +0000 (UTC) From: "Hairong Kuang (JIRA)" To: common-dev@hadoop.apache.org Message-ID: <1572680975.20251.1301443445837.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Created] (HADOOP-7212) Reuse connection MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Reuse connection ---------------- Key: HADOOP-7212 URL: https://issues.apache.org/jira/browse/HADOOP-7212 Project: Hadoop Common Issue Type: Bug Components: ipc Reporter: Hairong Kuang Assignee: Hairong Kuang One of my recent RPC change introduced a regression. It makes the first RPC to server, getProtocolSignature, and following RPCs not sharing the same connection. If all clients are short lived, this regression would double the number of connections in the cluster. The cause of the regression is that getProtocolSingature uses VersionProtocol to create a Connection object, and the following RPCs uses its own protocol name like ClientProtocol. Since protocol name is part of Connection object hashcode, this forces the RPC client to create a new Connection object, therefore forcing to create a new TCP/IP connection. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira