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 6C15410921 for ; Wed, 12 Mar 2014 04:56:50 +0000 (UTC) Received: (qmail 57218 invoked by uid 500); 12 Mar 2014 04:56:47 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 56775 invoked by uid 500); 12 Mar 2014 04:56:45 -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 56754 invoked by uid 99); 12 Mar 2014 04:56:43 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Mar 2014 04:56:43 +0000 Date: Wed, 12 Mar 2014 04:56:43 +0000 (UTC) From: "Shashank Gupta (JIRA)" To: dev@jackrabbit.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (JCR-3734) Slow local cache built-up time MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/JCR-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashank Gupta updated JCR-3734: -------------------------------- Affects Version/s: 2.7.4 Status: Patch Available (was: Open) Patch submitted to JCR-3729. > Slow local cache built-up time > ------------------------------ > > Key: JCR-3734 > URL: https://issues.apache.org/jira/browse/JCR-3734 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-core > Affects Versions: 2.7.4 > Reporter: Shashank Gupta > Fix For: 2.7.5 > > > urrently with the S3 connector, it appears that the startup will attempt to scan the local datastore on local disk and slow down the startup process. Attached are the thread dumps, profiling results and logs for further investigation. It will be great if the startup can avoid such a scan or this can be optimised further. > Customer's business impact - > " It's going to be a scalability issue as the cache grows. Currently we only have 64GB or less, which takes 8+ minutes, if we double or quadruple the cache, application startup is going to be far too slow for us. We might be able to take advantage of SSD attached disk rather than HDD attached disk, but we need to evaluate this option further and we want a better fix than simply throwing faster storage at it. > Ideally we want repository to come online as fast as possible and complete any cache size counting activities in the background, or have repository retain a memory of it's cache status from when it was last running so that at startup it picks up it's state and doesn't need to scan the whole cache." -- This message was sent by Atlassian JIRA (v6.2#6252)