From users-return-11108-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Apr 07 08:37:25 2009 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 76469 invoked from network); 7 Apr 2009 08:37:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 7 Apr 2009 08:37:25 -0000 Received: (qmail 83808 invoked by uid 500); 7 Apr 2009 08:37:24 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 83755 invoked by uid 500); 7 Apr 2009 08:37:24 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 83744 invoked by uid 99); 7 Apr 2009 08:37:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Apr 2009 08:37:24 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tmueller@day.com designates 207.126.148.181 as permitted sender) Received: from [207.126.148.181] (HELO eu3sys201aog001.obsmtp.com) (207.126.148.181) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 07 Apr 2009 08:37:15 +0000 Received: from source ([209.85.220.169]) by eu3sys201aob001.postini.com ([207.126.154.11]) with SMTP ID DSNKSdsQpt6wDzx+BnUd0l0dHg70JTgQBQEX@postini.com; Tue, 07 Apr 2009 08:36:54 UTC Received: by fxm17 with SMTP id 17so1990584fxm.34 for ; Tue, 07 Apr 2009 01:36:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.102.14 with SMTP id e14mr2497921bko.183.1239093413649; Tue, 07 Apr 2009 01:36:53 -0700 (PDT) In-Reply-To: <49DB0EE8.5050307@l7010.de> References: <49DB0EE8.5050307@l7010.de> Date: Tue, 7 Apr 2009 10:36:53 +0200 Message-ID: <91f3b2650904070136x6a637a2exb45b2561bc491cab@mail.gmail.com> Subject: Re: ConnectionRecoveryManager collecting all PreparedStatements From: =?ISO-8859-1?Q?Thomas_M=FCller?= To: users@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hi, As far as I know, the number of distinct prepared statements is fixed and quite small. So I believe it should not be a problem (as far as Jackrabbit is concerned). Regards, Thomas On Tue, Apr 7, 2009 at 10:29 AM, Christian Schr=F6der wrote= : > Hello, > i'am wondering if it is intended that ConnectionRecoveryManager collects > all PreparedStatements ever done and never removes them at all. > > I suspect this could lead to memory leak problems in the long run. > > It seams the preparedStatements Map inside > org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryMana= ger > is used as a cache. If so it really should have an eviction strategy and > a maximum size. Otherwise it should leak sometime in my understanding. > > Just stumbled over it because of > https://sourceforge.net/tracker/?func=3Ddetail&aid=3D2728324&group_id=3D1= 11957&atid=3D660861 > where this behaviour means serious trouble together with the filed bug > in ha-jdbc :) > > Maybe i have overlooked something, thats why i didn't file a bug report. > > regards > Christian > > >