[jboss-cvs] JBossAS SVN: r94126 - projects/docs/community/5/Clustering_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Sep 29 18:03:28 EDT 2009
Author: bstansberry at jboss.com
Date: 2009-09-29 18:03:28 -0400 (Tue, 29 Sep 2009)
New Revision: 94126
Modified:
projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Deployment.xml
Log:
Make stuff fit on PDF
Modified: projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Deployment.xml
===================================================================
--- projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Deployment.xml 2009-09-29 21:55:31 UTC (rev 94125)
+++ projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Deployment.xml 2009-09-29 22:03:28 UTC (rev 94126)
@@ -121,8 +121,7 @@
called when it should stop providing service:
</para>
- <programlisting><![CDATA[
-public interface HASingletonExampleMBean
+ <programlisting><![CDATA[public interface HASingletonExampleMBean
{
boolean isMasterNode();
}
@@ -145,8 +144,7 @@
{
isMasterNode = false;
}
-}
-]]></programlisting>
+}]]></programlisting>
<para>
We used <literal>startSingleton</literal> and <literal>stopSingleton</literal>
@@ -157,22 +155,20 @@
to control it, most likely packaged in a .sar file, with the
following <literal>META-INF/jboss-beans.xml</literal>:
</para>
- <programlisting><![CDATA[
-<deployment xmlns="urn:jboss:bean-deployer:2.0">
+ <programlisting><![CDATA[<deployment xmlns="urn:jboss:bean-deployer:2.0">
<!-- This bean is an example of a clustered singleton -->
<bean name="HASingletonExample" class="org.jboss.ha.examples.HASingletonExample">
- <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=HASingletonExample", exposedInterface=org.jboss.ha.examples.HASingletonExampleMBean.class)</annotation>
+ <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(...)</annotation>
</bean>
<bean name="ExampleHASingletonController" class="org.jboss.ha.singleton.HASingletonController">
- <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=ExampleHASingletonController", exposedInterface=org.jboss.ha.singleton.HASingletonControllerMBean.class, registerDirectly=true)</annotation>
+ <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(...)</annotation>
<property name="HAPartition"><inject bean="HAPartition"/></property>
<property name="target"><inject bean="HASingletonExample"/></property>
<property name="targetStartMethod">startSingleton</property>
<property name="targetStopMethod">stopSingleton</property>
</bean>
-</deployment>
-]]></programlisting>
+</deployment>]]></programlisting>
<para>Voila! A clustered singleton service.</para>
<para>
@@ -208,9 +204,7 @@
current node becomes the master), need only specify a dependency
on the Barrier service:
</para>
- <programlisting><![CDATA[
-<depends>HASingletonDeployerBarrierController</depends>
-]]></programlisting>
+ <programlisting><![CDATA[<depends>HASingletonDeployerBarrierController</depends>]]></programlisting>
<para>
The way it works is that a BarrierController is deployed along with the
@@ -287,12 +281,10 @@
<para>
The <literal>HASingletonElectionPolicy</literal> object is responsible for electing a master node from a list of available nodes, on behalf of an HA singleton, following a change in cluster topology.
</para>
- <programlisting><![CDATA[
-public interface HASingletonElectionPolicy
+ <programlisting><![CDATA[public interface HASingletonElectionPolicy
{
ClusterNode elect(List<ClusterNode> nodes);
-}
-]]></programlisting>
+}]]></programlisting>
<para>
JBoss ships with 2 election policies:
</para>
@@ -307,11 +299,9 @@
<literal>position</literal> can also be negative to indicate youngness; imagine the list of available nodes as a circular linked list.
<literal>position = -1</literal>, refers to the youngest node; <literal>position = -2</literal>, refers to the 2nd youngest node; etc.
</para>
- <programlisting><![CDATA[
-<bean class="org.jboss.ha.singleton.HASingletonElectionPolicySimple">
+ <programlisting><![CDATA[<bean class="org.jboss.ha.singleton.HASingletonElectionPolicySimple">
<property name="position">-1</property>
-</bean>
-]]></programlisting>
+</bean>]]></programlisting>
</listitem>
</varlistentry>
<varlistentry>
@@ -322,11 +312,9 @@
The <literal>preferredMaster</literal> property, specified as <emphasis>host:port</emphasis> or <emphasis>address:port</emphasis>, identifies a specific node that should become master, if available.
If the preferred node is not available, the election policy will behave as described above.
</para>
- <programlisting><![CDATA[
-<bean class="org.jboss.ha.singleton.PreferredMasterElectionPolicy">
+ <programlisting><![CDATA[<bean class="org.jboss.ha.singleton.PreferredMasterElectionPolicy">
<property name="preferredMaster">server1:12345</property>
-</bean>
-]]></programlisting>
+</bean>]]></programlisting>
</listitem>
</varlistentry>
</variablelist>
@@ -355,8 +343,7 @@
<para>
While there is little need to customize the farming service, it can be customized via the <literal>FarmProfileRepositoryClusteringHandler</literal> bean, whose properties and default values are listed below:
</para>
- <programlisting><![CDATA[
-<bean name="FarmProfileRepositoryClusteringHandler"
+ <programlisting><![CDATA[<bean name="FarmProfileRepositoryClusteringHandler"
class="org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler">
<property name="partition"><inject bean="HAPartition"/></property>
@@ -366,9 +353,10 @@
<property name="immutable">false</property>
<property name="lockTimeout">60000</property><!-- 1 minute -->
<property name="methodCallTimeout">60000</property><!-- 1 minute -->
- <property name="synchronizationPolicy"><inject bean="FarmProfileSynchronizationPolicy"/></property>
-</bean>
-]]></programlisting>
+ <property name="synchronizationPolicy">
+ <inject bean="FarmProfileSynchronizationPolicy"/>
+ </property>
+</bean>]]></programlisting>
<itemizedlist>
<listitem>
<para>
@@ -383,7 +371,8 @@
<listitem>
<para>
<emphasis role="bold">immutable</emphasis> indicates whether or not this handler allows a node to push content changes to the cluster.
- A value of <literal>true</literal> is equivalent to setting <literal>synchronizationPolicy</literal> to <literal>org.jboss.system.server.profileservice.repository.clustered.sync.ImmutableSynchronizationPolicy</literal>.
+ A value of <literal>true</literal> is equivalent to setting <literal>synchronizationPolicy</literal> to the <literal>org.jboss.system.server.profileservice.repository.clustered.sync</literal> package's
+ <literal>ImmutableSynchronizationPolicy</literal>.
</para>
</listitem>
<listitem>
@@ -403,8 +392,7 @@
<emphasis>Reincarnation</emphasis> refers to the phenomenon where a newly started node may contain an application in its <literal>farm</literal> directory that was previously removed by the farming service but might still exist on the starting node if it was not running when the removal took place.
The default synchronization policy is defined as follows:
</para>
- <programlisting><![CDATA[
-<bean name="FarmProfileSynchronizationPolicy"
+ <programlisting><![CDATA[<bean name="FarmProfileSynchronizationPolicy"
class="org.jboss.profileservice.cluster.repository.DefaultSynchronizationPolicy">
<property name="allowJoinAdditions"><null/></property>
<property name="allowJoinReincarnations"><null/></property>
@@ -416,9 +404,10 @@
<property name="allowMergeRemovals"><null/></property>
<property name="developerMode">false</property>
<property name="removalTrackingTime">2592000000</property><!-- 30 days -->
- <property name="timestampService"><inject bean="TimestampDiscrepancyService"/></property>
-</bean>
-]]></programlisting>
+ <property name="timestampService">
+ <inject bean="TimestampDiscrepancyService"/>
+ </property>
+</bean>]]></programlisting>
<itemizedlist>
<listitem>
<para><emphasis role="bold">allow[Join|Merge][Additions|Reincarnations|Updates|Removals]</emphasis> define fixed responses to requests to allow additions, reincarnations, updates, or removals from joined or merged nodes.</para>
@@ -440,31 +429,5 @@
</listitem>
</itemizedlist>
</section>
-
- <!--
- <section id="clustering-intro-state">
- <title>Distributed state replication services</title>
- <para>In a clustered server environment, distributed state management is a key service the cluster must
- provide. For instance, in a stateful session bean application, the session state must be
- synchronized among all bean instances across all nodes, so that the client application reaches the
- same session state no matter which node serves the request. In an entity bean application, the bean
- object sometimes needs to be cached across the cluster to reduce the database load. Currently, the state replication and distributed cache services in JBoss AS are provided via three ways: the <literal>HASessionState</literal> Mbean, the <literal>DistributedState</literal> MBean and the JBoss Cache framework.</para>
- <itemizedlist>
- <listitem>
- <para>The <literal>HASessionState</literal> MBean is a legacy service that provides session replication and distributed cache services for EJB 2.x stateful session beans. The MBean is defined in the <literal>all/deploy/cluster-service.xml</literal> file. We will show its configuration options in the EJB 2.x stateful session bean section later.</para>
- </listitem>
- <listitem>
- <para>
- The <literal>DistributedState</literal> Mbean is a legacy service built on the HAPartition service. It is supported for backwards compatibility reasons, but new applications should not use it; they should use the much more sophisticated JBoss Cache instead.
- </para>
- </listitem>
-
- <listitem>
- <para>
- As mentioned above JBoss Cache is used to provide cache services for HTTP sessions, EJB 3.0 session beans and EJB 3.0 entity beans. It is the primary distributed state management tool in JBoss AS, and is an excellent choice for any custom caching requirements your applications may have. We will cover JBoss Cache in more detail when we discuss specific services in the next several sections..</para>
- </listitem>
- </itemizedlist>
-
- </section>
- -->
+
</chapter>
\ No newline at end of file
More information about the jboss-cvs-commits
mailing list