From dev-return-10624-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Fri Feb 02 15:21:10 2007 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 58043 invoked from network); 2 Feb 2007 15:21:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Feb 2007 15:21:09 -0000 Received: (qmail 24380 invoked by uid 500); 2 Feb 2007 15:21:14 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 24351 invoked by uid 500); 2 Feb 2007 15:21:14 -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 24342 invoked by uid 99); 2 Feb 2007 15:21:14 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Feb 2007 07:21:14 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= 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, 02 Feb 2007 07:06:25 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C5CA77141F2 for ; Fri, 2 Feb 2007 07:06:05 -0800 (PST) Message-ID: <11446272.1170428765806.JavaMail.jira@brutus> Date: Fri, 2 Feb 2007 07:06:05 -0800 (PST) From: "Stefan Guggisberg (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Commented: (JCR-731) Can the caching mechanism be improved? In-Reply-To: <5561703.1170427325812.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-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469776 ] Stefan Guggisberg commented on JCR-731: --------------------------------------- martijn, please provide a diff rather than the full source. that way it would be easier to review. thanks stefan > Can the caching mechanism be improved? > -------------------------------------- > > Key: JCR-731 > URL: https://issues.apache.org/jira/browse/JCR-731 > Project: Jackrabbit > Issue Type: Improvement > Components: core > Reporter: Martijn Hendriks > Attachments: CacheManager.java, MLRUItemStateCache.java, SharedItemStateManager.java > > > Hi all, > We've identified the method "getNonVirtualItemState" in the SharedItemStateManager as a hot spot in our application. To avoid the contention in "getNonVirtualItemState", we have pulled the isCached call out of the synchronized block and re-implemented the MLRUItemStateCache. It uses a HashMap that contains the ItemId-ItemState mapping and a ReadWriteLock to replace all synchronized blocks in the code. The implementation of "shrinkIfRequired" unfortunatly got much more expensive as the entryset of the HashMap must be sorted by accesscount. This method then clearly is a bottleneck. We solved this by changing the CacheManager a bit: the "resizeAll" method avoids the eviction of items out of caches as long as possible. > These changes work out really well for our application. I have attached the changed files; comments/feedback are very welcome! > Regards, > Martijn Hendriks > creative online development B.V. > > t: 024 - 3888 261 > f: 024 - 3888 621 > e: martijnh@gx.nl > > Wijchenseweg 111 > 6538 SW Nijmegen > http://www.gx.nl/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.