Return-Path: X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 011CD100F3 for ; Fri, 3 Jan 2014 01:41:50 +0000 (UTC) Received: (qmail 54783 invoked by uid 500); 3 Jan 2014 01:41:50 -0000 Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org Received: (qmail 54748 invoked by uid 500); 3 Jan 2014 01:41:50 -0000 Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@apache.org Delivered-To: mailing list notifications@accumulo.apache.org Received: (qmail 54740 invoked by uid 99); 3 Jan 2014 01:41:50 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Jan 2014 01:41:50 +0000 Date: Fri, 3 Jan 2014 01:41:50 +0000 (UTC) From: "Dave Marion (JIRA)" To: notifications@accumulo.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (ACCUMULO-2069) ThriftTransportPool too aggressive in closing connections 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/ACCUMULO-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13861082#comment-13861082 ] Dave Marion edited comment on ACCUMULO-2069 at 1/3/14 1:41 AM: --------------------------------------------------------------- Looking in 1.7.0 as to how/where to fix this. I thought initially about using some exponential backoff function instead of the 3 seconds, but instead realized that the I/O layer likely handles this for us (keepalive). Found a Thrift implementation[1] that uses this and sets the recv and send buffer sizes. Looks like we can just add those options in org.apache.accumulo.core.util.TTimeoutTransport. Is that the only place in the client where thrift connections are created? What about server side? Looks like this class goes back to 1.5.0. [1] https://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/thrift/TCustomServerSocket.java was (Author: dlmarion): Looking in 1.7.0 as to how/where to fix this. I thought initially about using some exponential backoff function instead of the 3 seconds, but instead realized that the I/O layer likely handles this for us (keepalive). Found a Thrift implementation[1] that uses this and sets the recv and send buffer sizes. Looks like we can just add those options in org.apache.accumulo.core.util.TTimeoutTransport. Is that the only place in the client where thrift connections are created? What about server side? [1] https://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/thrift/TCustomServerSocket.java > ThriftTransportPool too aggressive in closing connections > --------------------------------------------------------- > > Key: ACCUMULO-2069 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2069 > Project: Accumulo > Issue Type: Bug > Components: client > Affects Versions: 1.4.4 > Reporter: Dave Marion > Fix For: 1.7.0 > > > org.apache.accumulo.core.client.impl.ThriftTransportPool closes unused thrift connections after 3 seconds of inactivty. This can impact performance by causing tablet server connections to be constantly torn down and set up. Think of the case where you have a MTBW writer with a small number of threads and a moderate amount of tservers. Make the timeout configurable. -- This message was sent by Atlassian JIRA (v6.1.5#6160)