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 EB2FFF77E for ; Fri, 3 May 2013 21:32:16 +0000 (UTC) Received: (qmail 92418 invoked by uid 500); 3 May 2013 21:32:16 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 92372 invoked by uid 500); 3 May 2013 21:32:16 -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 92362 invoked by uid 99); 3 May 2013 21:32:16 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 May 2013 21:32:16 +0000 Date: Fri, 3 May 2013 21:32:15 +0000 (UTC) From: "Cody Burleson (JIRA)" To: dev@jackrabbit.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (JCR-3589) Server startup time unacceptable when one node is catching up with revisions. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Cody Burleson created JCR-3589: ---------------------------------- Summary: Server startup time unacceptable when one node is catching up with revisions. Key: JCR-3589 URL: https://issues.apache.org/jira/browse/JCR-3589 Project: Jackrabbit Content Repository Issue Type: Bug Components: clustering Affects Versions: 2.4.3 Environment: CentOS 6.4 running IBM WebSphere Application Server 7.0.0.19. Database is DB2. Our app is a Java EE web app using Jackrabbit libs, deployed to 2 servers in a cluster configuration. Reporter: Cody Burleson We have a 2 node (2 server, that is) cluster. We are running test scripts that continuously read and write to simulate user load. This is recording new entries and updates in the Jackrabbit JCR. So, we can shut down one of the servers in the cluster and leave it down for a day. During this day, the simulated load continues to run on a single node. When we start the other server back up, it takes an unacceptably long time to startup (upwards of 12 hours). Is there a quicker way to start the server and have the revision catch-up or whatever the heck is going on - happen in the background? Or is there a way to get around the need to catch up with the revisions? Basically, just any amount of assistance is helpful here. Obviously 12 hour server startup will never fly for a PROD environment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira