Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Wed, 30 Mar 2011 06:51:05 +0000 (UTC)
From: "Hairong Kuang (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: 
 <2002000154.20818.1301467865819.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1235336773.20249.1301443445782.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (HADOOP-7212) Reuse connection
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HADOOP-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hairong Kuang resolved HADOOP-7212.
-----------------------------------

    Resolution: Invalid

Just found out that the regression was introduced to only our internal branch not to the Apache trunk. Good!

> 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