Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9B1599C5C for ; Fri, 11 May 2012 08:32:21 +0000 (UTC) Received: (qmail 55777 invoked by uid 500); 11 May 2012 08:32:21 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 55623 invoked by uid 500); 11 May 2012 08:32:20 -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 55500 invoked by uid 99); 11 May 2012 08:32:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 08:32:18 +0000 X-ASF-Spam-Status: No, hits=-1.0 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of anchela@adobe.com designates 64.18.1.189 as permitted sender) Received: from [64.18.1.189] (HELO exprod6og105.obsmtp.com) (64.18.1.189) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 08:32:11 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKT6zOdonK5jgvOknx6beSsTxVRWMMCL2x@postini.com; Fri, 11 May 2012 01:31:51 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q4B8VmIf025083 for ; Fri, 11 May 2012 01:31:49 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q4B8Vmvm003156 for ; Fri, 11 May 2012 01:31:48 -0700 (PDT) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 11 May 2012 01:31:48 -0700 Received: from angela.corp.adobe.com (10.132.1.18) by eurhub01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.192.1; Fri, 11 May 2012 09:31:45 +0100 Message-ID: <4FACCE71.5090808@adobe.com> Date: Fri, 11 May 2012 10:31:45 +0200 From: Angela Schreiber User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Subject: Re: spi2davex.RepositoryServiceImpl -> idUriCache raises until heap overflow References: <1336723249600-4625776.post@n4.nabble.com> In-Reply-To: <1336723249600-4625776.post@n4.nabble.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org hi daniel there is currently no possibility to limit the size by configuration. may i ask you to file an issue in JIRA for this? that's the easiest way to have this addressed. even better if you had a patch at hand. :) thanks in advance angela On 5/11/12 10:00 AM, danield wrote: > Hello @all, > > i'm using a JCR with an underlying DB. > > While querying the JCR, it seems that the queryPath of each result property > of each node is cached within the idUriCache. I thought, that setting the > maxIdleTime="10" will reinstanciate the RepositoryServiceImpl and the cache > will be resetted, but unfortunately it doesn't. > > Looking at the heapdump shows me lot of entries like the following: > > org.apache.jackrabbit.spi2davex.RepositoryServiceImpl @ 0x7b39aaee8 > -org.apache.jackrabbit.spi2dav.URIResolverImpl @ 0x7b399f4e8 > --java.util.HashMap @ 0x7b3c3e168 > ---java.util.HashMap$Entry[16] @ 0x7b39ad4d8 > ----java.util.HashMap$Entry @ 0x7b3c6a3d8 > -----org.apache.jackrabbit.spi2dav.IdURICache @ 0x7b33992a8 > ------java.util.HashMap @ 0x7b3c3e0d8 > -------java.util.HashMap$Entry[32768] @ 0x7b54de1e0 > --------java.util.HashMap$Entry @ 0x7b5696b10 > > value: > http://localhost:8090/jackrabbit-webapp-2.2.2/server/workspace/jcr%3aroot/level1/level2/level3/nodeName/docdatetime > > Is there a possiblity to configure the cache or to access the > RepositoryServiceImpl via the JCRSession or Repository instance? I thought > of setting a maxsize to the cache or clearing the cache after a specific > time. > > I hope you can help me. > Best regards, Daniel > > -- > View this message in context: http://jackrabbit.510166.n4.nabble.com/spi2davex-RepositoryServiceImpl-idUriCache-raises-until-heap-overflow-tp4625776.html > Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.