Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 90808 invoked from network); 27 Jul 2007 06:24:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Jul 2007 06:24:26 -0000 Received: (qmail 64868 invoked by uid 500); 27 Jul 2007 06:24:26 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 64739 invoked by uid 500); 27 Jul 2007 06:24:25 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 64730 invoked by uid 99); 27 Jul 2007 06:24:25 -0000 Received: from Unknown (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jul 2007 23:24:25 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jul 2007 06:24:24 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 2D7377141F7 for ; Thu, 26 Jul 2007 23:24:04 -0700 (PDT) Message-ID: <12172542.1185517444182.JavaMail.jira@brutus> Date: Thu, 26 Jul 2007 23:24:04 -0700 (PDT) From: "Jukka Zitting (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Commented: (JCR-1037) Memory leak causing performance problems In-Reply-To: <26822905.1185482823894.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/JCR-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515967 ] Jukka Zitting commented on JCR-1037: ------------------------------------ Just checking for the obvious case, I assume you did call Session.save() after adding documents. It would be great if you could share a test case that illustrates the problem. > Memory leak causing performance problems > ---------------------------------------- > > Key: JCR-1037 > URL: https://issues.apache.org/jira/browse/JCR-1037 > Project: Jackrabbit > Issue Type: Bug > Components: Jackrabbit API > Affects Versions: 1.2.1, 1.2.2, 1.2.3, 1.3 > Environment: Tomcat 6.0, XP Pro w/1Gb > Reporter: Antonio Carballo > > Folks, > We have been running tests on JCR v1.3 and v1.2.1 for the past two weeks. The system keeps running out of memory after X number of documents are added. Our initial test consisted of about 50 documents and gradually increased to about 150 documents. The size of the documents ranged from 1K to 9MB. We later changed the test to consist of files with less than 1K in length with the same result. Increasing the heap size delays the error but the outcome is always the same (Servlet runs out of heap memory.) > Using JProbe we found a high number of references created by the caching sub-system (SessionItemStateManager.java, SharedItemStateManager.java, LocalItemStateManager.java). We changed the caching parameters using CacheManager (min 64K - max 16MB). This change only delayed the error. Servlet eventually runs out of heap memory. > We are more than happy to share our findings (even source code and test data) with the Jackrabbit team. Please let us know how you wish to proceed. > Sincerely, > Antonio Carballo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.