Return-Path: X-Original-To: apmail-curator-user-archive@minotaur.apache.org Delivered-To: apmail-curator-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B8C9110EBC for ; Mon, 31 Mar 2014 20:54:23 +0000 (UTC) Received: (qmail 2662 invoked by uid 500); 31 Mar 2014 20:53:49 -0000 Delivered-To: apmail-curator-user-archive@curator.apache.org Received: (qmail 2475 invoked by uid 500); 31 Mar 2014 20:53:32 -0000 Mailing-List: contact user-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@curator.apache.org Delivered-To: mailing list user@curator.apache.org Received: (qmail 2435 invoked by uid 99); 31 Mar 2014 20:53:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Mar 2014 20:53:30 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dsg123456789@gmail.com designates 209.85.128.169 as permitted sender) Received: from [209.85.128.169] (HELO mail-ve0-f169.google.com) (209.85.128.169) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Mar 2014 20:53:24 +0000 Received: by mail-ve0-f169.google.com with SMTP id pa12so8715478veb.14 for ; Mon, 31 Mar 2014 13:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=X3zSmZgVXnZBFOdmsSwPpaM945JEhtsiEOQuQP6TLQU=; b=afdJ1TSd3KPmV4Uhkd3wbeGYUIIooN4jfskDIwsWKOApSYY4fsq4HL5+ePc61mWNzc pJ15rI+yXoVuXXlx5KVmIZIbsaTBD+IsAge1lUAUaEdev+paiSW+B54RsM9ByGN+Fjet TeVkLTdkRlMIXMMATPw8M4I7Cvau7HNes+ISu7zvKyspCancCkYDmPoldFAMuls2QIt1 glQxJ5nWOqDQxQBGw9/hRfBdGqDHl6Frcut8p58S7F/2eHUEd0EJR3UK5r3GNR890Yxu Dw5N6UQ25PCdGP9cFj5pm7j2FIFi6lQwZitos3AOeOd/gBYvnIr9RyomFJHSUxJvrI7x 1+yA== MIME-Version: 1.0 X-Received: by 10.220.170.202 with SMTP id e10mr3746879vcz.20.1396299182729; Mon, 31 Mar 2014 13:53:02 -0700 (PDT) Received: by 10.220.86.9 with HTTP; Mon, 31 Mar 2014 13:53:02 -0700 (PDT) Date: Mon, 31 Mar 2014 16:53:02 -0400 Message-ID: Subject: Noticing a curator memory/thread leak From: David Greenberg To: user@curator.apache.org Content-Type: multipart/alternative; boundary=001a11c21904c96d6e04f5ed3cbe X-Virus-Checked: Checked by ClamAV on apache.org --001a11c21904c96d6e04f5ed3cbe Content-Type: text/plain; charset=ISO-8859-1 I have been noticing that my application seems to be leaking curator threads and CuratorFrameworkImpls. These leak at around 10-200 per day. I create 2 curators in my application--one is from Datomic, and the other is used for a LeaderLatch. I can see that the LeaderLatch and Datomic instance each retain a single curator reference; however, I see hundreds of curators that are kept around along with their Executors, which ends up draining a lot of resources. I'm using an older version of Curator--was this or is this a problem before? Is it a Curator bug, or a bug in my code that uses it? Thank you, David --001a11c21904c96d6e04f5ed3cbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I have been noticing that my application seems to be leaki= ng curator threads and CuratorFrameworkImpls.

These leak= at around 10-200 per day.

I create 2 curators in = my application--one is from Datomic, and the other is used for a LeaderLatc= h. I can see that the LeaderLatch and Datomic instance each retain a single= curator reference; however, I see hundreds of curators that are kept aroun= d along with their Executors, which ends up draining a lot of resources.

I'm using an older version of Curator--was this or = is this a problem before? Is it a Curator bug, or a bug in my code that use= s it?

Thank you,

David

--001a11c21904c96d6e04f5ed3cbe--