Uploaded image for project: 'Jackrabbit Content Repository'
  1. Jackrabbit Content Repository
  2. JCR-3589

Server startup time unacceptable when one node is catching up with revisions.

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.4.3
    • Fix Version/s: None
    • Component/s: clustering
    • Labels:
      None
    • 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.

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              cody.burleson Cody Burleson
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: