[jboss-cvs] JBossCache/docs/PojoCache/en/modules ...
Brian Stansberry
brian.stansberry at jboss.com
Wed Jun 6 15:50:07 EDT 2007
User: bstansberry
Date: 07/06/06 15:50:07
Modified: docs/PojoCache/en/modules configuration.xml appendix.xml
Log:
[JBCACHE-1052] Add JMX chapter to the docs
Revision Changes Path
1.7 +472 -61 JBossCache/docs/PojoCache/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/PojoCache/en/modules/configuration.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -b -r1.6 -r1.7
--- configuration.xml 21 Nov 2006 13:21:42 -0000 1.6
+++ configuration.xml 6 Jun 2007 19:50:07 -0000 1.7
@@ -1,80 +1,90 @@
<chapter id="configuration">
- <title>Configuration</title>
+ <title>Configuration and Deployment</title>
<para>Since PojoCache uses Cache as a delegate for the underlying node replication,
transaction,
locking, and passivation behavior, user of PojoCache will need to configure the xml
for the Cache implementation. In addition, there is another <literal>pojocache-aop.xml</literal>
- for some customized behaviors (if needs to).</para>
+ for some customized behaviors (if needed).</para>
- <sect1>
+ <section>
<title>Cache configuration xml file</title>
- <para>When a user obtains a PojoCache instance from the PojoCacheFactory, it requires user pass in
- a configuration xml file. PojoCache will simply pass this xml to the underlying Cache implementation.
+ <para>When a user obtains a PojoCache instance from the PojoCacheFactory, it is required that the
+ user pass in a <literal>org.jboss.cache.config.Configuration</literal> object, or more typically
+ a String indicating the location on the classpath or filesystem of an xml configuration file.
+ PojoCacheFactory will parse the xml to create a <literal>Configuration</literal>. PojoCache will simply
+ pass this <literal>Configuration</literal> to the underlying Cache implementation.
As a result, any state replication aspects can be configured in this file, along with cache
- passivation. For details on the configuration xml, you can check out the core Cache documentation.</para>
- </sect1>
+ passivation. For details on the configuration xml, please see the "Configuration" chapter in the
+ the JBoss Cache User Guide.</para>
+ </section>
- <sect1>
+ <section>
<title>Passivation configuration</title>
- <para>A user can also configure the underlying Cache to activate the passivation. Passivation is feature
- needed to keep the VM memory compact. In JBoss Cache, it is done via combination of eviction
- policy and cache loader. That is, when a node is evicted from Cache, it will store into the cache
- loader. When the node is requested again, it will be loaded from the store and stored into memory.
- </para><para>There is a restriction, however. Since we use the "flat space" physical POJO mapping, there are
- two places that has POJO information. One is under the regular String ID that the user specifies, and
- the other is located under <code>/__JBossInteranl__</code>. Therefore, to be consistent, when you specify
- the eviction region, you can only specify one global region (i.e., <code>/_default_</code> region).
- This way, when the nodes associated with the POJO is passivated, they will do so across the whole
+ <para>A user can also configure the underlying Cache to enable passivation. Passivation is a feature
+ needed to keep the VM memory compact. In JBoss Cache, it is done via a combination of an eviction
+ policy and a cache loader. That is, when a node is evicted from the Cache's in-memory store, it will
+ be stored in a persistent store by the cache loader. When the node is requested again, it will be loaded
+ from the persistent store and stored into memory.
+ </para>
+ <para>There is a restriction, however. Since we use the "flat space" physical POJO mapping, there are
+ two places that have POJO information. One is under the regular String ID that the user specifies, and
+ the other is located under <code>/__JBossInternal__</code>. Therefore, to maintain consistentency,
+ when you specify the eviction region, you can only specify one global (i.e., <code>/_default_</code>)
+ region. This way, when the nodes associated with a POJO are passivated, they will do so across the whole
region.
+ </para>
+ <para>
Below is a snippet from a cache configuration xml
illustrating how the eviction policy along with cache loader can be configured. Please note that this is
simply an aspect of the underlying Cache. That is, PojoCache layer is agnostic to this behavior.
<programlisting>
-<attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
-<attribute name="EvictionPolicyConfig">
- <config>
- <attribute name="wakeUpIntervalSeconds">5</attribute>
- <!-- Cache wide default -->
- <region name="/_default_">
- <attribute name="maxNodes">5000</attribute>
- <attribute name="timeToLiveSeconds">3</attribute>
- </region>
- </config>
-</attribute>
-
-<attribute name="CacheLoaderConfiguration">
- <config>
- <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
- <passivation>true</passivation>
- <preload>/</preload>
- <shared>false</shared>
-
- <!-- we can now have multiple cache loaders, which get chained -->
- <cacheloader>
- <class>org.jboss.cache.loader.FileCacheLoader</class>
- <!-- whether the cache loader writes are asynchronous -->
- <async>false</async>
- <!-- only one cache loader in the chain may set fetchPersistentState to true.
- An exception is thrown if more than one cache loader sets this to true. -->
- <fetchPersistentState>true</fetchPersistentState>
- <!-- determines whether this cache loader ignores writes - defaults to false. -->
- <ignoreModifications>false</ignoreModifications>
- </cacheloader>
- </config>
-</attribute>
-
+ <![CDATA[
+<attribute name="EvictionPolicyConfig">
+ <config>
+ <attribute name="wakeUpIntervalSeconds">5</attribute>
+ <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
+ <!-- Cache wide default -->
+ <region name="/_default_">
+ <attribute name="maxNodes">5000</attribute>
+ <attribute name="timeToLiveSeconds">3</attribute>
+ </region>
+ </config>
+</attribute>
+
+<attribute name="CacheLoaderConfiguration">
+ <config>
+ <passivation>true</passivation>
+ <preload>/</preload>
+ <shared>false</shared>
+
+ <!-- we can now have multiple cache loaders, which get chained -->
+ <cacheloader>
+ <class>org.jboss.cache.loader.FileCacheLoader</class>
+ <!-- whether the cache loader writes are asynchronous -->
+ <async>false</async>
+ <!-- only one cache loader in the chain may set fetchPersistentState to true.
+ An exception is thrown if more than one cache loader sets this to true. -->
+ <fetchPersistentState>true</fetchPersistentState>
+ <!-- determines whether this cache loader ignores writes - defaults to false. -->
+ <ignoreModifications>false</ignoreModifications>
+ </cacheloader>
+ </config>
+</attribute>
+]]>
</programlisting>
</para>
- <para>Another way to support multiple regions in eviction is to use Marshalling. When the Cache
- use marshalling, it has the side effect of placing all internal data under that specific region.
- As a result, the whole region will be passivated and activated at the same time.</para>
- </sect1>
+ <para>Another way to support multiple regions in eviction is to use region-based marshalling.
+ See the "Architecture" chapter in the JBoss Cache User Guide for more on region-based marshalling.
+ When the Cache uses region-based marshalling, it has the side effect of placing all internal data
+ under the specific region. As a result, if you configure eviction regions whose root Fqns match
+ your marshalling regions, the whole region will be passivated and activated at the same time.</para>
+ </section>
- <sect1>
+ <section>
<title>PojoCache configuration xml</title>
<para>PojoCache supplies a <literal>pojocache-aop.xml</literal> that is required to be set via a
system property: <literal>jboss.aop.path</literal> during compile- or load-time, or placed in
@@ -82,13 +92,414 @@
of interceptor stack specification and annotations for POJO instrumentation. It is listed fully in the
Appendix section. Note that the file should be read mostly. So no need to modify it now unless you
are customizing the interceptor chain, e.g.</para>
- </sect1>
+ </section>
+
+ <section>
+ <title>Deployment Options</title>
+ <para>There are a number of ways to deploy your PojoCache:</para>
+
+ <section>
+ <title>Programatic Deployment</title>
+ <para>Simply instantiate a PojoCacheFactory and invoke one of the
+ overloaded <literal>createCache</literal> methods shown in the
+ <link linkend="api">API Overview</link>.</para>
+ </section>
+
+ <section id="deployment.microkernel">
+ <title>JMX-Based Deployment in JBoss AS (JBoss AS 5.x and 4.x)</title>
+ <para>If PojoCache is run in JBoss AS then your cache can be deployed as an
+ MBean simply by copying a standard cache configuration file to the server's
+ <literal>deploy</literal> directory. The standard format of PojoCache's
+ standard XML configuration file (as shown in the
+ <link linkend="xml">Appendix</link>) is the same
+ as a JBoss AS MBean deployment descriptor, so the AS's SAR Deployer has
+ no trouble handling it. Also, you don't have to place the configuration
+ file directly in <literal>deploy</literal>; you can package it along
+ with other services or JEE components in a SAR or EAR.
+ </para>
+
+ <para>
+ In AS 5, if you're using a server config based on the standard
+ <literal>all</literal> config, then that's all you need to do; all required
+ jars will be on the classpath. Otherwise, you will need to ensure
+ <literal>pojocache.jar</literal>, <literal>jbosscache.jar</literal>
+ and <literal>jgroups-all.jar</literal> are on the classpath. You may
+ need to add other jars if you're using
+ things like <literal>JdbmCacheLoader</literal>. The simplest way to do
+ this is to copy the jars from the PojoCache distribution's
+ <literal>lib</literal> directory to the server config's <literal>lib</literal>
+ directory. You could also package the jars with the configuration file
+ in Service Archive (.sar) file or an EAR.
+ </para>
+
+ <para>
+ It is possible to deploy a PojoCache 2.0 instance in JBoss AS 4.x
+ (at least in 4.2.0.GA; other AS releases are completely untested).
+ However, the significant API changes between the 2.x and 1.x releases
+ mean none of the standard AS 4.x clustering services (e.g.
+ http session replication) that rely on the 1.x API will work with
+ PojoCache 2.x. Also, be aware that usage of PojoCache 2.x in AS 4.x is not
+ something the cache developers are making any significant effort to test,
+ so be sure to test your application well (which of course you're doing anyway.)
+ </para>
+
+ <para>
+ Note in the <link linkend="xml">example</link>
+ the value of the <literal>mbean</literal> element's
+ <literal>code</literal> attribute:
+ <literal>org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper</literal>. This is the
+ class JBoss Cache uses to handle JMX integration; the
+ PojoCache itself does not expose an MBean
+ interface. See the
+ <link linkend="jmx.mbeans">JBoss Cache MBeans section</link>
+ for more on the PojoCacheJmxWrapper.
+ </para>
+
+ <para>
+ Once your cache is deployed, in order to use it with an in-VM client
+ such as a servlet, a JMX proxy can be used to get a reference to
+ the cache:
+ </para>
+
+ <programlisting>
+ <![CDATA[
+ MBeanServer server = MBeanServerLocator.locateJBoss();
+ ObjectName on = new ObjectName("jboss.cache:service=PojoCache");
+ PojoCacheJmxWrapperMBean cacheWrapper =
+ (PojoCacheJmxWrapperMBean) MBeanServerInvocationHandler.newProxyInstance(server, on,
+ PojoCacheJmxWrapperMBean.class, false);
+ PojoCache cache = cacheWrapper.getPojoCache();
+ ]]>
+ </programlisting>
+
+ <para>The MBeanServerLocator class is a helper to find the (only) JBoss
+ MBean server inside the current JVM. The
+ <literal>javax.management.MBeanServerInvocationHandler</literal> class'
+ <literal>newProxyInstance</literal> method creates a
+ dynamic proxy implementing the given interface and uses JMX to
+ dynamically dispatch methods invoked against the generated interface
+ to the MBean. The name used to look up the MBean is the same as defined
+ in the cache's configuration file.
+ </para>
+
+ <para>
+ Once the proxy to the <literal>PojoCacheJmxWrapper</literal> is obtained,
+ the <literal>getPojoCache()</literal> will return a reference to the
+ PojoCache itself.
+ </para>
+ </section>
+
+ <section id="deployment.microcontainer">
+ <title>Via JBoss Microcontainer (JBoss AS 5.x)</title>
+
+ <para>
+ Beginning with AS 5, JBoss AS also supports deployment of POJO services via
+ deployment of a file whose name ends with <literal>-beans.xml</literal>.
+ A POJO service is one whose implementation is via a "Plain Old Java Object",
+ meaning a simple java bean that isn't required to implement any special
+ interfaces or extend any particular superclass. A PojoCache
+ is a POJO service, and all the components in a <literal>Configuration</literal>
+ are also POJOS, so deploying a cache in this way is a natural step.
+ </para>
+ <para>
+ Deployment of the cache is done using the JBoss Microcontainer that forms the
+ core of JBoss AS. JBoss Microcontainer is a sophisticated IOC framework
+ (similar to Spring). A <literal>-beans.xml</literal> file is basically
+ a descriptor that tells the IOC framework how to assemble the various
+ beans that make up a POJO service.
+ </para>
+ <para>
+ The rules for how to deploy the file, how to package it, how to
+ ensure the required jars are on the classpath, etc. are the same
+ as for a <link linkend="deployment.microkernel">JMX-based deployment</link>.
+ </para>
+
+ <para>
+ Following is an abbreviated example <literal>-beans.xml</literal> file.
+ The details of building up the Configuration are omitted; see the
+ "Deploying JBoss Cache" chapter in the JBoss Cache User Guide for
+ a more complete example. If you look in the
+ <literal>server/all/deploy</literal> directory of an AS 5
+ installation, you can find several more examples.
+ </para>
+
+ <programlisting>
+ <![CDATA[
+<?xml version="1.0" encoding="UTF-8"?>
+
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <!-- First we create a Configuration object for the cache -->
+ <bean name="ExampleCacheConfig"
+ class="org.jboss.cache.config.Configuration">
+
+ ... details omitted
+
+ </bean>
+
+ <!-- The cache itself. -->
+ <bean name="ExampleCache" class="org.jboss.cache.pojo.impl.PojoCacheImpl">
+
+ <constructor factoryClass="org.jboss.cache.pojo.PojoCacheFactory
+ factoryMethod="createCache">
+ <parameter><inject bean="ExampleCacheConfig"/></parameter>
+ <parameter>false</false>
+ </constructor>
+
+ </bean>
+
+</deployment>
+]]>
+ </programlisting>
+
+ <para>
+ An interesting thing to note in the above example is the difference
+ between PojoCache and a plain Cache in the use of a factory to
+ create the cache. (See the "Deploying JBoss Cache" chapter in the
+ JBoss Cache User Guide for the comparable plain Cache example.) The
+ PojoCacheFactory exposes static methods for creating a PojoCache;
+ as a result there is no need to add a separate <literal>bean</literal>
+ element for the factory. Plain Cache's
+ <literal>DefaultCacheFactory</literal> creates caches from a singleton
+ instance, requiring a bit more boilerplate in the config file.
+ </para>
+ </section>
+ </section>
+
+ <section id="jmx.mbeans">
+ <title>PojoCache MBeans</title>
+ <para>
+ PojoCache provides an MBean that can be registered with your environment's JMX server to allow access
+ to the cache instance via JMX. This MBean is the <literal>org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper</literal>.
+ It is a StandardMBean, so it's MBean interface is <literal>org.jboss.cache.pojo.jmx.PojoCacheJmxWrapperMBean</literal>.
+ This MBean can be used to:
+ <itemizedlist>
+ <listitem>Get a reference to the underlying PojoCache.</listitem>
+ <listitem>Invoke create/start/stop/destroy lifecycle operations on
+ the underlying PojoCache.</listitem>
+ <listitem>See numerous details about the cache's configuration, and
+ change those configuration items that can be changed when the
+ cache has already been started.</listitem>
+ </itemizedlist>
+ See the <literal>PojoCacheJmxWrapperMBean</literal> javadoc for more details.
+ </para>
+ <para>
+ It is important to note a significant architectural difference between PojoCache 1.x and 2.x. In 1.x,
+ the old <literal>TreeCacheAop</literal> class was itself an MBean, and essentially exposed the cache's entire
+ API via JMX. In 2.x, JMX has been returned to it's fundamental role as a management layer. The
+ PojoCache object itself is completely unaware of JMX; instead JMX functionality is added
+ through a wrapper class designed for that purpose. Furthermore, the interface exposed through JMX
+ has been limited to management functions; the general PojoCache API is no longer exposed
+ through JMX. For example, it is no longer possible to invoke a cache <literal>attach</literal> or
+ <literal>detach</literal> via the JMX interface.
+ </para>
+ <para>
+ If a <literal>PojoCacheJmxWrapper</literal> is registered, the wrapper also registers MBeans
+ for the underlying plain Cache and for each interceptor configured in the cache's interceptor stack.
+ These MBeans are used to capture and expose statistics related to cache operations; see the
+ JBoss Cache User Guide for more. They are hierarchically
+ associated with the <literal>PojoCacheJmxWrapper</literal> MBean and have service names that
+ reflect this relationship. For
+ example, a plain Cache associated with a <literal>jboss.cache:service=PojoCache</literal> will be
+ accessible through an mbean named <literal>jboss.cache:service=PojoCache,cacheType=Cache</literal>.
+ The replication interceptor MBean for that cache will be accessible through the mbean named
+ <literal>jboss.cache:service=PojoCache,cacheType=Cache,cache-interceptor=ReplicationInterceptor</literal>.
+ </para>
+ </section>
+
+ <section id="jmx.registration">
+ <title>Registering the PojoCacheJmxWrapper</title>
+
+ <para>
+ The best way to ensure the <literal>PojoCacheJmxWrapper</literal> is registered
+ in JMX depends on how you are deploying your cache:
+ </para>
+
+ <section id="jmx.registration.programatic">
+ <title>Programatic Registration</title>
+
+ <para>
+ Simplest way to do this is to create your <literal>PojoCache</literal>
+ and pass it to the <literal>PojoCacheJmxWrapper</literal> constructor.
+ </para>
+
+ <programlisting>
+ // Build but don't start the cache
+ // (although it would work OK if we started it)
+ PojoCache cache = PojoCacheFactory.createCache("cache-configuration.xml", false);
+
+ PojoCacheJmxWrapperMBean wrapper = new PojoCacheJmxWrapper(cache);
+ MBeanServer server = getMBeanServer(); // however you do it
+ ObjectName on = new ObjectName("jboss.cache:service=PojoCache");
+ server.registerMBean(wrapper, on);
+
+ // Invoking lifecycle methods on the wrapper results
+ // in a call through to the cache
+ wrapper.create();
+ wrapper.start();
+
+ ... use the cache
+
+ ... on application shutdown
+
+ // Invoking lifecycle methods on the wrapper results
+ // in a call through to the cache
+ wrapper.stop();
+ wrapper.destroy();
+ </programlisting>
+
+ <para>
+ Alternatively, build a <literal>Configuration</literal> object
+ and pass it to the <literal>PojoCacheJmxWrapper</literal>. The wrapper
+ will construct the <literal>PojoCache</literal>:
+ </para>
+
+ <programlisting>
+ Configuration config = buildConfiguration(); // whatever it does
- <sect1>
- <title>PojoCache MBean service</title>
+ PojoCacheJmxWrapperMBean wrapper = new PojoCacheJmxWrapper(config);
+ MBeanServer server = getMBeanServer(); // however you do it
+ ObjectName on = new ObjectName("jboss.cache:service=TreeCache");
+ server.registerMBean(wrapper, on);
- <para>TODO... This section needs to be filled in when the new JMX aspect is introduced.
+ // Call to wrapper.create() will build the Cache if one wasn't injected
+ wrapper.create();
+ wrapper.start();
+
+ // Now that it's built, created and started, get the cache from the wrapper
+ PojoCache cache = wrapper.getPojoCache();
+
+ ... use the cache
+
+ ... on application shutdown
+
+ wrapper.stop();
+ wrapper.destroy();
+
+ </programlisting>
+ </section>
+
+ <section>
+ <title>JMX-Based Deployment in JBoss AS (JBoss AS 4.x and 5.x)</title>
+
+ <para>
+ When you
+ <link linkend="deployment.microkernel">deploy your cache in JBoss AS using a -service.xml file</link>,
+ a <literal>PojoCacheJmxWrapper</literal> is automatically registered. There is no need
+ to do anything further. The <literal>PojoCacheJmxWrapper</literal> is accessible
+ through the service name specified in the cache configuration file's <literal>mbean</literal> element.
+ </para>
+ </section>
+
+ <section>
+ <title>Via JBoss Microcontainer (JBoss AS 5.x)</title>
+
+ <para>
+ <literal>PojoCacheJmxWrapper</literal> is a POJO, so the microcontainer
+ has no problem creating one. The trick is
+ getting it to register your bean in JMX. This can be done by
+ specifying the <literal>org.jboss.aop.microcontainer.aspects.jmx.JMX</literal>
+ annotation on the <literal>PojoCacheJmxWrapper</literal> bean:
</para>
- </sect1>
+ <programlisting>
+ <![CDATA[
+<?xml version="1.0" encoding="UTF-8"?>
+
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <!-- First we create a Configuration object for the cache -->
+ <bean name="ExampleCacheConfig"
+ class="org.jboss.cache.config.Configuration">
+
+ ... build up the Configuration
+
+ </bean>
+
+ <!-- The cache itself. -->
+ <bean name="ExampleCache" class="org.jboss.cache.pojo.impl.PojoCacheImpl">
+
+ <constructor factoryClass="org.jboss.cache.pojo.PojoCacheFactory
+ factoryMethod="createCache">
+ <parameter><inject bean="ExampleCacheConfig"/></parameter>
+ <parameter>false</false>
+ </constructor>
+
+ </bean>
+
+ <!-- JMX Management -->
+ <bean name="ExampleCacheJmxWrapper" class="org.jboss.cache.jmx.CacheJmxWrapper">
+
+ <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(
+ name="jboss.cache:service=ExamplePojoCache",
+ exposedInterface=org.jboss.cache.pojo.jmx.PojoCacheJmxWrapperMBean.class,
+ registerDirectly=true)
+ </annotation>
+
+ <constructor>
+ <parameter><inject bean="ExampleCache"/></parameter>
+ </constructor>
+
+ </bean>
+
+</deployment>
+]]>
+ </programlisting>
+
+ <para>
+ As discussed in the <link linkend="jmx.registration.programatic">Programatic Registration</link>
+ section, <literal>PojoCacheJmxWrapper</literal> can do the work of building,
+ creating and starting the PojoCache if it is provided with a <literal>Configuration</literal>:
+ </para>
+
+ <programlisting>
+ <![CDATA[
+<?xml version="1.0" encoding="UTF-8"?>
+
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <!-- First we create a Configuration object for the cache -->
+ <bean name="ExampleCacheConfig"
+ class="org.jboss.cache.config.Configuration">
+
+ ... build up the Configuration
+
+ </bean>
+
+ <bean name="ExampleCache" class="org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper">
+
+ <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(
+ name="jboss.cache:service=ExamplePojoCache",
+ exposedInterface=org.jboss.cache.pojo.jmx.PojoCacheJmxWrapperMBean.class,
+ registerDirectly=true)
+ </annotation>
+
+ <constructor>
+ <parameter><inject bean="ExampleCacheConfig"/></parameter>
+ </constructor>
+
+ </bean>
+
+</deployment>
+]]>
+ </programlisting>
+ </section>
+
+ </section>
+
+ <section>
+ <title>Runtime Statistics and JMX Notifications</title>
+
+ <para>As mentioned above, the cache exposes a variety of statistical
+ information through its MBeans. It also emits JMX notifications when
+ events occur in the cache. See the JBoss Cache User Guide for more
+ on the statistics and notifications that are available.
+ </para>
+ <para>The only PojoCache addition to the plain JBoss Cache behavior
+ described in the User Guide is that you can register with the
+ PojoCacheJmxWrapper to get the notifications. There is no
+ requirement to figure out the ObjectName of the underlying
+ cache's CacheJmxWrapper and register with that.
+ </para>
+ </section>
</chapter>
\ No newline at end of file
1.9 +79 -83 JBossCache/docs/PojoCache/en/modules/appendix.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: appendix.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/PojoCache/en/modules/appendix.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -b -r1.8 -r1.9
--- appendix.xml 28 Feb 2007 12:30:58 -0000 1.8
+++ appendix.xml 6 Jun 2007 19:50:07 -0000 1.9
@@ -71,90 +71,86 @@
Below is a sample xml configuration for Cache that you can use for PojoCache creation.
</para>
<programlisting>
-<?xml version="1.0" encoding="UTF-8" ?>
+ <![CDATA[
+<?xml version="1.0" encoding="UTF-8" ?>
-<server>
-<mbean code="org.jboss.cache.aop.PojoCache" name="jboss.cache:service=PojoCache">
-<depends>jboss:service=TransactionManager</depends>
+<server>
+ <mbean code="org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper"
+ name="jboss.cache:service=PojoCache">
-<!-- Configure the TransactionManager -->
-<attribute name="TransactionManagerLookupClass">org.jboss.cache.transaction.DummyTransactionManagerLookup</attribute>
+ <depends>jboss:service=TransactionManager</depends>
-<!-- Isolation level : SERIALIZABLE
+ <!-- Configure the TransactionManager -->
+ <attribute name="TransactionManagerLookupClass">
+ org.jboss.cache.transaction.DummyTransactionManagerLookup
+ </attribute>
+
+ <!-- Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
--->
-<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
-
-<!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC -->
-<attribute name="CacheMode">REPL_SYNC</attribute>
+ -->
+ <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
-<!-- Just used for async repl: use a replication queue -->
-<attribute name="UseReplQueue">false</attribute>
+ <!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC -->
+ <attribute name="CacheMode">REPL_SYNC</attribute>
-<!-- Replication interval for replication queue (in ms) -->
-<attribute name="ReplQueueInterval">0</attribute>
-
-<!-- Max number of elements which trigger replication -->
-<attribute name="ReplQueueMaxElements">0</attribute>
-
-<!-- Name of cluster. Needs to be the same for all clusters, in order
- to find each other
--->
-<attribute name="ClusterName">JBossCache-Cluster</attribute>
-
-<!-- JGroups protocol stack properties. Can also be a URL,
- e.g. file:/home/bela/default.xml
- <attribute name="ClusterProperties"></attribute>
--->
-<attribute name="ClusterConfig">
-
-<config>
-<!-- UDP: if you have a multihomed machine,
- set the bind_addr attribute to the appropriate NIC IP address, e.g bind_addr="192.168.0.2"
--->
-<!-- UDP: On Windows machines, because of the media sense feature
+ <!-- Name of cluster. Needs to be the same for all caches,
+ in order for them to find each other
+ -->
+ <attribute name="ClusterName">PojoCacheCluster</attribute>
+
+ <!-- JGroups protocol stack properties. -->
+ <attribute name="ClusterConfig">
+ <config>
+ <!-- UDP: if you have a multihomed machine, set the bind_addr
+ attribute to the appropriate NIC IP address -->
+ <!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
- set the loopback attribute to true
--->
-<UDP mcast_addr="228.1.2.3" mcast_port="48866" ip_ttl="64" ip_mcast="true" mcast_send_buf_size="150000" mcast_recv_buf_size="80000" ucast_send_buf_size="150000" ucast_recv_buf_size="80000" loopback="false" />
-<PING timeout="2000" num_initial_members="3" up_thread="false" down_thread="false" />
-<MERGE2 min_interval="10000" max_interval="20000" />
-<FD_SOCK />
-<VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false" />
-<pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800" max_xmit_size="8192" up_thread="false" down_thread="false" />
-<UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" down_thread="false" />
-<pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false" />
-<FRAG frag_size="8192" down_thread="false" up_thread="false" />
-<pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true" />
-<pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />
-</config>
-</attribute>
+ set the loopback attribute to true -->
+ <UDP mcast_addr="228.1.2.3" mcast_port="48866"
+ ip_ttl="64" ip_mcast="true"
+ mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
+ ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
+ loopback="false"/>
+ <PING timeout="2000" num_initial_members="3"/>
+ <MERGE2 min_interval="10000" max_interval="20000"/>
+ <FD shun="true"/>
+ <FD_SOCK/>
+ <VERIFY_SUSPECT timeout="1500"/>
+ <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
+ max_xmit_size="8192"/>
+ <UNICAST timeout="600,1200,2400",4800/>
+ <pbcast.STABLE desired_avg_gossip="400000"/>
+ <FC max_credits="2000000" min_threshold="0.10"/>
+ <FRAG2 frag_size="8192"/>
+ <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
+ shun="true" print_local_addr="true"/>
+ <pbcast.STATE_TRANSFER/>
+ </config>
+ </attribute>
-<!-- Whether or not to fetch state on joining a cluster -->
-<attribute name="FetchStateOnStartup">true</attribute>
+ <!-- Whether or not to fetch state on joining a cluster -->
+ <attribute name="FetchInMemoryState">true</attribute>
-<!-- The max amount of time (in milliseconds) we wait until the
+ <!-- The max amount of time (in milliseconds) we wait until the
initial state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
+ -->
+ <attribute name="InitialStateRetrievalTimeout">15000</attribute>
--->
-<attribute name="InitialStateRetrievalTimeout">5000</attribute>
-
-<!-- Number of milliseconds to wait until all responses for a
+ <!-- Number of milliseconds to wait until all responses for a
synchronous call have been received.
--->
-<attribute name="SyncReplTimeout">15000</attribute>
+ -->
+ <attribute name="SyncReplTimeout">15000</attribute>
-<!-- Max number of milliseconds to wait for a lock acquisition -->
-<attribute name="LockAcquisitionTimeout">10000</attribute>
+ <!-- Max number of milliseconds to wait for a lock acquisition -->
+ <attribute name="LockAcquisitionTimeout">10000</attribute>
-<!-- Name of the eviction policy class. -->
-<attribute name="EvictionPolicyClass" />
-</mbean>
-</server>
+ </mbean>
+</server>
+]]>
</programlisting>
</sect1>
More information about the jboss-cvs-commits
mailing list