Page tree
Skip to end of metadata
Go to start of metadata


Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 123 rates


We want the two public instances to share the comments which are stored in the forum workspace. But otherwise we want to keep the content independent.

see: Clustering in Magnolia documentation


  1. add a new repository configuration in .../WEB-INF/config/default/repositories.xml

        <!-- magnolia non-default repository -->
        <Repository name="magnoliacluster" provider="info.magnolia.jackrabbit.ProviderImpl" loadOnStartup="true">
            <param name="configFile" value="${magnolia.repositories.jackrabbit.cluster.config}" />
            <param name="repositoryHome" value="${magnolia.repositories.home}/magnoliacluster" />
            <!-- the default node types are loaded automatically
                <param name="customNodeTypes" value="WEB-INF/config/repo-conf/nodetypes/magnolia_nodetypes.xml" />
            <param name="contextFactoryClass" value="org.apache.jackrabbit.core.jndi.provider.DummyInitialContextFactory" />
            <param name="providerURL" value="localhost" />
            <param name="bindName" value="cluster-${magnolia.webapp}" />
            <workspace name="forum" />
  2. add a mapping to the clustered repository for the workspace to tell the system that this workspace lives in a different repository (the clustered one)

            <Map name="website" repositoryName="magnolia" workspaceName="website" />
            <Map name="forum" repositoryName="magnoliacluster" workspaceName="forum" />
  3. set magnolia.repositories.jackrabbit.cluster.config in the to whatever you will use for the configuration file below (e.g. "WEB-INF/config/repo-conf/clustered-jackrabbit-bundle-mysql-search.xml")

jackrabbit configuration file


  1. make a copy of the non-clustering configuration file
  2. make sure that both the instances use the same underlaying database
  3. add the cluster configuration to the configuration file

      <Cluster syncDelay="2000">
        <Journal class="org.apache.jackrabbit.core.journal.DatabaseJournal">
          <param name="revision" value="${rep.home}/revision"/> 
          <param name="driver" value="com.mysql.jdbc.Driver"/> 
          <param name="url" value="jdbc:mysql://localhost:3306/magnolia"/> 
          <param name="user" value="magnolia"/> 
          <param name="password" value="magnolia"/> 
          <param name="databaseType" value="mysql"/> 
          <param name="schemaObjectPrefix" value="JOURNAL_"/> 

Set the cluster id

The cluster id identifies the instance and is used to write changes to the journal as well as to load changes from the journal. Make sure this is a unique value and is not shared with the other nodes in the cluster.

Cluster id can be defined either in the properties file (most convenient way) or in the persistence manager in the cluster configuration (both ways are used in the attached files):

  <Cluster id="mclu1" syncDelay="2000">

Setting the cluster id in the properties file, will save you from having two different persistence manager files with just this little change.

  1. set magnolia.clusterid property in the file


Make sure that the content is not activated to both the clustered instances.

  • only one subscriber should have a subscription to the clustered workspace(s) in /server/activation/subscribers/xxx/subscriptions

Warning: loading of workspace configuration

Once a workspace has been created a copy of jackrabbit configuration is saved to the workspace folder (workspace.xml)

  • changing the original jackrabbit configuration file won't have any effect
  • changes have to be made in the workspace.xml


  1. With this scenario, there is a "ItemExistsException" on installation.

    • You start public1, it installs everything in its own repo and few thing in the shared forum repo.
    • You start public2, it triggers also its installation, everything is installed in its own repo, but then when the commenting  module start its installation, an ItemExistsException occurs. Commenting want to bootstrap something in the shared forum repo but already here because installed by public1.

    To proceed with the installation of public2, the solution I found is, once public 1 is up and running, I delete everything from the forum workspace and start the installation of public 2. Then the commenting module coming with public 2 will re-bootstrap the deleted items and there is no issue.

    Maybe there is a better way to handle this issue. If someone has a better idea, thanks to share !!


    But anyway i think it's a conceptual issue (not of commenting, but) of Clustering Magnolia. When many instances share a repo, it's important to handle carefully the concurrent write behavior.



  2. After configuring the cluster, starting the public instance after the author instance will throw some exceptions:

    ERROR org.apache.jackrabbit.core.query.lucene.SearchIndex: Unable to read revision '7'.

    It looks like this behavior is expected since the two instances are not "synchronized". Next startups should be fine.

    Also, don't forget to configure the public instance in order to NOT bootstrap the samples managed by the shared repository.

    1. Finally someone reply (tongue)

    2. Is this issue still exists in 5.5.x Core version. I was trying it and i still see the error even after i set cluster.master as true for instance 1 and cluster.master as false for instace 2 of my public facing magnolia.

  3. Scenario: 1 Author instance , 2 public instances

    In case of "ItemExistsException" as Samuel Schmitt's comment we can also pass through this issue by the following.

    Step 1: Start author instance (example: trainingTemplatingAuthor) after starting is completed we will open FORUM app and delete  "pagecomment" forum (path: http://localhost:8080/trainingTemplatingAuthor/.magnolia/admincentral#app:forum:browser;/pagecomments:null:)

    Step 2: Stop Tomcat server and deploy the public instance (example: trainingTemplatingPublic1) after the server completed starting we do the same as Step 1 above.

    Step 3: Stop Tomcat server again and deploy the public instance (example: trainingTemplatingPublic2)




  4. I would really like so see an example of setting up a cluster with derby for local development to change a workspace between author and public for e.g. questions, users, etc..

    1. As far as I know, if you use Derby as an embedded database, you will not be able to use its workspaces in a cluster. "Apache Derby doesn't support concurrent access in the embedded mode." see

      However, H2 is probably another embedded db you should look into, but I have never tested it personally.

        1. Tried it with different setups, but never got clustering working with H2 and file-system only db's (so no mysql storage).