Return-Path: Delivered-To: apmail-hbase-user-archive@www.apache.org Received: (qmail 64996 invoked from network); 23 Mar 2011 21:25:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 Mar 2011 21:25:29 -0000 Received: (qmail 2579 invoked by uid 500); 23 Mar 2011 21:25:28 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 2549 invoked by uid 500); 23 Mar 2011 21:25:28 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 2541 invoked by uid 99); 23 Mar 2011 21:25:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Mar 2011 21:25:28 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dlieu.7@gmail.com designates 209.85.212.41 as permitted sender) Received: from [209.85.212.41] (HELO mail-vw0-f41.google.com) (209.85.212.41) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Mar 2011 21:25:20 +0000 Received: by vws4 with SMTP id 4so8121321vws.14 for ; Wed, 23 Mar 2011 14:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=PjRWDb2Ab7quSx8qfZ2PIC83FlLc4ZRhkLBX0Q2syP0=; b=vCuID/iJ4SGUdCWJfn0dnTqhnWZw268RZ0/qapnnG8QFjFBaNk8SZdOQRLUgotG56u 7EtH2td4t2TzZJF5VBm6d/iVbwaQkK7MiOpvFf1xHAmhYsPskbAJ00+raYrwkxJ2Cg0g YmwhI4RhWSu+PFB99uCjk+v5WYn+fuobvgv7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wib6xTIKLnyxu/4DQg+ebVrWFsjuPtZGWRsg3BMvGvhwxCUBQJtLS5sv5I5C/wGWL8 +su8M1f63M7sUsU2JcwigHPNC3kJweIfmY0iuIR+09vurZrCDXdY6TM80NYvKMy2V9rn PDRiODhjsTv/V2dkfq1bWtZgLMJDpZ9KSyfnk= MIME-Version: 1.0 Received: by 10.52.176.199 with SMTP id ck7mr596484vdc.139.1300915499502; Wed, 23 Mar 2011 14:24:59 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Wed, 23 Mar 2011 14:24:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Mar 2011 14:24:59 -0700 Message-ID: Subject: Re: zk connection leak with TableInput/OutputFormat (CDH3b4, 0.90.1) From: Dmitriy Lyubimov To: user@hbase.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org yes i am passing destroyProxy=true. But according to the code, it doesn't affect closing zookeeper connection (it should be closed anyway) but i have +1 zk connection each time i run the MR job still. -d On Wed, Mar 23, 2011 at 2:22 PM, Ted Yu wrote: > I assume you passed true as second parameter to deleteConnection(). > > On Wed, Mar 23, 2011 at 1:54 PM, Dmitriy Lyubimov wrote: > >> Hi, >> >> I am experiencing severe connection leak in my MR client that uses >> Hbase as input/output . Every job that uses TableInputFormat leaks 1 >> zookeeper connection per run as evidenced by netstat. >> >> I understand that the way HTable manages connections now is it creates >> a new HBase (and also Zookeeper) connection per each instance of >> Configuration it is initialized with. By looking at the code of the >> TableInputFormat class, i see that it creates HTable in the front end >> during configuration (of course, it probably needs to use it to >> determine region splits). >> >> Since i have to configure each job individually, i must create a new >> instance of Configuration. Thus, i am not able to use shared HBase >> connections (which i would prefer to, but there seems to be no way now >> to do that). >> >> So... after i run an instance of MR job, the hbase connection seems to >> be leaked. It also leaks zk connection , which is a problem since >> zookeeper instances have limits on how many connections can be made >> from the same IP and eventually the client is not able to create any >> new HTables anymore since it can't establish any new zookeeper >> connections. >> >> I tried to do explicit cleanup by calling >> HConnectionManager.deleteConnection (Configuration) passing in the >> configuration that i used to create MR job. Doesn't seem to work. >> >> So.. Is there a way to run MR job with TableInputFormat without >> leaking a connection? I am pretty sure i am not creating any HTables >> in the client side. Or is it a bug? I spent several days now >> investigation an issue but i am still not able to come up with a >> workaround against zookeeper connection leaks in HBase MR jobs. >> >> thank you very much. >> -Dmitriy >> >