jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cody Burleson (JIRA)" <j...@apache.org>
Subject [jira] [Created] (JCR-3589) Server startup time unacceptable when one node is catching up with revisions.
Date Fri, 03 May 2013 21:32:15 GMT
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

Mime
View raw message