jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "Clustering" by ThomasMueller
Date Thu, 10 Dec 2009 11:12:56 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "Clustering" page has been changed by ThomasMueller.


+ == Clustering ==
+ <<TableOfContents>>
+ == Overview ==
  Clustering in Jackrabbit works as follows: content is shared between all cluster nodes.
That means all Jackrabbit cluster nodes need access to the SAME persistent storage (persistence
manager and data store).
  The persistence manager must be clusterable (eg. central database that allows for concurrent
access, see [[PersistenceManagerFAQ]]); any DataStore (file or DB) is clusterable by its very
nature, as they store content by unique hash ids. However, each cluster node needs its own
(private) FileSystem and [[Search]] index.
  Every change made by one cluster node is reported in a journal, which can be either file
based or written to some database.
+ == Limitations ==
+ Session scoped locks currently have no effect on other cluster nodes - see http://issues.apache.org/jira/browse/JCR-1173
  == Requirements ==
@@ -16, +26 @@

   * The persistence managers must store their data in the same, globally accessible location
(see [[PersistenceManagerFAQ]])
   * A DataStore must always be shared between nodes, if used
- === Unique Cluster Node ID ===
+ == Unique Cluster Node ID ==
  Every cluster node needs a unique ID. This ID can be either specified in the cluster configuration
as '''id''' attribute or as value of the system property '''org.apache.jackrabbit.core.cluster.node_id'''.
When copying repository configurations, do not forget to adapt the cluster node IDs if they
are hardcoded. See below for some sample cluster configurations. A cluster id can be freely
defined, the only requirement is that it has to be different on each cluster node.
- === Sync Delay ===
+ == Sync Delay ==
  By default, cluster nodes read the journal and update their state every 5 seconds (5000
milliseconds). To use a different value, set the attribute ''syncDelay'' in the cluster configuration.
- === Removing Old Revisions ===
+ == Removing Old Revisions ==
  The journal in which cluster nodes write their changes can potentially become very large.
  By default, old revisions are not removed. This enables one to add a cluster node
@@ -48, +58 @@

  Related issue: http://issues.apache.org/jira/browse/JCR-1087
- === Journal Type ===
+ == Journal Type ==
  The cluster nodes store information identifying items they modified in a journal. This journal
must again be globally available to all nodes in the cluster. This can be either a folder
in the file system or a database running standalone.

View raw message