[jboss-cvs] JBossCache/docs/TreeCache/en/modules ...
Brian Stansberry
brian.stansberry at jboss.com
Thu Dec 7 17:35:39 EST 2006
User: bstansberry
Date: 06/12/07 17:35:39
Modified: docs/TreeCache/en/modules Tag: Branch_JBossCache_1_4_0
configuration.xml
Log:
Add mux config docs
General cleanup, alphabetize
Revision Changes Path
No revision
No revision
1.10.2.3 +113 -76 JBossCache/docs/TreeCache/en/modules/configuration.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: configuration.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/TreeCache/en/modules/configuration.xml,v
retrieving revision 1.10.2.2
retrieving revision 1.10.2.3
diff -u -b -r1.10.2.2 -r1.10.2.3
--- configuration.xml 29 Nov 2006 04:01:12 -0000 1.10.2.2
+++ configuration.xml 7 Dec 2006 22:35:39 -0000 1.10.2.3
@@ -56,10 +56,21 @@
registered to capture and display its statistics. -->
<attribute name="UseInterceptorMbeans">true</attribute>
- <!-- Name of cluster. Needs to be the same for all clusters, in order
- to find each other -->
+ <!-- Name of cluster. Needs to be the same for all TreeCache nodes in a
+ cluster, in order to find each other -->
<attribute name="ClusterName">JBoss-Cache-Cluster</attribute>
+ <!-- Uncomment next three statements to enable JGroups multiplexer.
+ This configuration is dependent on the JGroups multiplexer being
+ registered in an MBean server such as JBossAS. -->
+ <!--
+ <depends>jgroups.mux:name=Multiplexer</depends>
+ <attribute name="MultiplexerService">jgroups.mux:name=Multiplexer</attribute>
+ <attribute name="MultiplexerStack">udp</attribute>
+ -->
+
+ <!-- JGroups protocol stack properties. ClusterConfig isn't used if the
+ multiplexer is enabled and successfully initialized. -->
<attribute name="ClusterConfig">
<config>
<!-- UDP: if you have a multihomed machine,
@@ -245,23 +256,29 @@
<row>
<entry>
- <para>ClusterName</para>
+ <para>ClusterConfig</para>
</entry>
<entry>
- <para>Name of cluster. Needs to be the same for all nodes in a
- cluster in order to find each other.</para>
+ <para>The configuration of the underlying JGroups stack.
+ Ignored if <literal>MultiplexerService</literal> and
+ <literal>MultiplexerStack</literal> are used.
+ See the various *-service.xml files in the source distribution
+ <literal>etc/META-INF</literal> folder for examples.
+ See the <ulink url="http://www.jgroups.org">JGroups documentation</ulink>
+ or the <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups">JGroups wiki page</ulink>
+ for more information.</para>
</entry>
</row>
<row>
<entry>
- <para>ClusterConfig</para>
+ <para>ClusterName</para>
</entry>
<entry>
- <para>The configuration of the underlying JGroups stack. See
- cluster-service.xml for an example.</para>
+ <para>Name of cluster. Needs to be the same for all nodes in a
+ cluster in order for them to communicate with each other.</para>
</entry>
</row>
@@ -271,8 +288,9 @@
</entry>
<entry>
- <para>The name of a class implementing EvictionPolicy. If empty,
- no eviction policy is enabled.</para>
+ <para>The name of a class implementing EvictionPolicy. Deprecated;
+ it is preferable to configure the eviction policy class as
+ part of the <literal>EvictionPolicyConfig</literal>.</para>
</entry>
</row>
@@ -295,7 +313,7 @@
<entry>
<para>Whether or not to acquire the initial in-memory state from
- existing members. Allows for warm/hot caches (true/false). Also
+ existing members. Allows for hot/cold caches (true/false). Also
see the fetchPersistentState element in
CacheLoaderConfiguration.</para>
</entry>
@@ -303,6 +321,22 @@
<row>
<entry>
+ <para>InactiveOnStartup</para>
+ </entry>
+
+ <entry>
+ <para>Whether or not the entire tree is inactive upon startup,
+ only responding to replication messages after
+ <literal>activateRegion()</literal> is called to activate one or
+ more parts of the tree. If true, property
+ <literal>FetchInMemoryState</literal> is ignored. This property
+ should only be set to true if <literal>UseRegionBasedMarshalling</literal>
+ is also <literal>true</literal>.</para>
+ </entry>
+ </row>
+
+ <row>
+ <entry>
<para>InitialStateRetrievalTimeout</para>
</entry>
@@ -317,56 +351,74 @@
<row>
<entry>
- <para>InactiveOnStartup</para>
+ <para>IsolationLevel</para>
</entry>
<entry>
- <para>Whether or not the entire tree is inactive upon startup,
- only responding to replication messages after
- <literal>activateRegion()</literal> is called to activate one or
- more parts of the tree. If true, property
- <literal>FetchInMemoryState</literal> is ignored. This property
- should only be set to true if <literal>UseRegionBasedMarshalling</literal>
- is also <literal>true</literal>.</para>
+ <para>Node locking isolation level : SERIALIZABLE, REPEATABLE_READ
+ (default), READ_COMMITTED, READ_UNCOMMITTED, and NONE. Note that this is ignored if
+ NodeLockingScheme is OPTIMISTIC. Case doesn't matter. See documentation on Transactions and
+ Concurrency for more details.
+ </para>
</entry>
</row>
<row>
<entry>
- <para>NodeLockingScheme</para>
+ <para>LockAcquisitionTimeout</para>
</entry>
<entry>
- <para>May be PESSIMISTIC (default) or OPTIMISTIC. See documentation on Transactions and Concurrency for more details.</para>
+ <para>Time in milliseconds to wait for a lock to be acquired. If
+ a lock cannot be acquired an exception will be thrown.</para>
</entry>
</row>
+ <row>
+ <entry>
+ <para>MultiplexerService</para>
+ </entry>
+
+ <entry>
+ <para>The JMX object name of the service that defines the JGroups multiplexer.
+ In JBoss AS 5 this service is normally defined in the jgroups-multiplexer.sar.
+ If this attribute is defined, the cache will look up the multiplexer service
+ in JMX and will use it to obtain a multiplexed JGroups channel. The configuration
+ of the channel will be that associated with <literal>MultiplexerStack</literal>.
+ The <literal>ClusterConfig</literal> attribute will be ignored.
+ </para>
+ </entry>
+ </row>
<row>
<entry>
- <para>IsolationLevel</para>
+ <para>MultiplexerStack</para>
</entry>
<entry>
- <para>Node locking isolation level : SERIALIZABLE, REPEATABLE_READ
- (default), READ_COMMITTED, READ_UNCOMMITTED, and NONE. Note that this is ignored if NodeLockingScheme is OPTIMISTIC. Case doesn't matter. See documentation on Transactions and Concurrency for more details.</para>
+ <para>The name of the JGroups stack to be used with the TreeCache cluster.
+ Stacks are defined in the configuration of the external <literal>MultiplexerService</literal>
+ discussed above. In JBoss AS 5 this is normally done in the
+ jgroups-multiplexer.sar\META-INF\multiplexer-stacks.xml file.
+ The default stack is <literal>udp</literal>. This attribute is used in conjunction with
+ <literal>MultiplexerService</literal>.
+ </para>
</entry>
</row>
<row>
<entry>
- <para>LockAcquisitionTimeout</para>
+ <para>NodeLockingScheme</para>
</entry>
<entry>
- <para>Time in milliseconds to wait for a lock to be acquired. If
- a lock cannot be acquired an exception will be thrown.</para>
+ <para>May be PESSIMISTIC (default) or OPTIMISTIC. See documentation on Transactions and Concurrency for more details.</para>
</entry>
</row>
<row>
<entry><para>ReplicationVersion</para></entry>
- <entry><para>Tells the cache to serialize replication traffic
+ <entry><para>Tells the cache to serialize cluster traffic
in a format consistent with that used by the given release
of JBoss Cache. Different JBoss Cache versions use different
wire formats; setting this attribute tells a cache from a later
@@ -392,39 +444,54 @@
<row>
<entry>
- <para>SyncReplTimeout</para>
+ <para>ReplQueueMaxElements</para>
</entry>
<entry>
- <para>For synchronous replication: time in milliseconds to wait
- until replication acks have been received from all nodes in the
- cluster.</para>
+ <para>Max number of elements in the replication queue until
+ replication kicks in.</para>
</entry>
</row>
<row>
<entry>
- <para>ReplQueueMaxElements</para>
+ <para>SyncCommitPhase</para>
</entry>
<entry>
- <para>Max number of elements in the replication queue until
- replication kicks in.</para>
+ <para>This option is used to control the behaviour of the commit part of a 2-phase commit protocol, when
+ using REPL_SYNC (does not apply to other cache modes). By default this is set to
+ <literal>false</literal>. There is a performance penalty to enabling this, especially when running
+ in a large cluster, but the upsides are greater cluster-wide data integrity. See the chapter on
+ Clustered Caches for more information on this.
+ </para>
</entry>
</row>
<row>
<entry>
- <para>StateTransferVersion</para>
+ <para>SyncReplTimeout</para>
</entry>
<entry>
- <para>The binary format to use for state transfer data.
- Different releases of JBossCache use different formats; if this
- attribute is set a later release will use an earlier release's
- format, allowing interoperability. Valid values are "124" for
- JBossCache 1.2.4, "130" for release 1.3.0, etc. Earliest valid
- version is 124.</para>
+ <para>For synchronous replication: time in milliseconds to wait
+ until replication acks have been received from all nodes in the
+ cluster.</para>
+ </entry>
+ </row>
+
+ <row>
+ <entry>
+ <para>SyncRollbackPhase</para>
+ </entry>
+
+ <entry>
+ <para>This option is used to control the behaviour of the rollback part of a 2-phase commit protocol, when
+ using REPL_SYNC (does not apply to other cache modes). By default this is set to
+ <literal>false</literal>. There is a performance penalty to enabling this, especially when running
+ in a large cluster, but the upsides are greater cluster-wide data integrity. See the chapter on
+ Clustered Caches for more information on this.
+ </para>
</entry>
</row>
@@ -448,8 +515,8 @@
<entry>
<para> Specifies whether each interceptor should have an associated
- mbean registered. Interceptor mbeans are used to capture and display
- statistics. This setting enables or disables all such interceptor
+ mbean registered. Interceptor mbeans are used to capture statistics
+ and display them in JMX. This setting enables or disables all such interceptor
mbeans. Default value is <emphasis>true</emphasis>.</para>
</entry>
</row>
@@ -476,36 +543,6 @@
</entry>
</row>
- <row>
- <entry>
- <para>SyncCommitPhase</para>
- </entry>
-
- <entry>
- <para>This option is used to control the behaviour of the commit part of a 2-phase commit protocol, when
- using REPL_SYNC (does not apply to other cache modes). By default this is set to
- <literal>false</literal>. There is a performance penalty to enabling this, especially when running
- in a large cluster, but the upsides are greater cluster-wide data integrity. See the chapter on
- Clustered Caches for more information on this.
- </para>
- </entry>
- </row>
-
- <row>
- <entry>
- <para>SyncRollbackPhase</para>
- </entry>
-
- <entry>
- <para>This option is used to control the behaviour of the rollback part of a 2-phase commit protocol, when
- using REPL_SYNC (does not apply to other cache modes). By default this is set to
- <literal>false</literal>. There is a performance penalty to enabling this, especially when running
- in a large cluster, but the upsides are greater cluster-wide data integrity. See the chapter on
- Clustered Caches for more information on this.
- </para>
- </entry>
- </row>
-
</tbody>
</tgroup>
</informaltable>
More information about the jboss-cvs-commits
mailing list