[jboss-cvs] JBossAS SVN: r59847 - in branches/Branch_4_2/tomcat/docs: html and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri Jan 19 12:05:21 EST 2007
Author: dimitris at jboss.org
Date: 2007-01-19 12:05:21 -0500 (Fri, 19 Jan 2007)
New Revision: 59847
Modified:
branches/Branch_4_2/tomcat/docs/html/tc5-clustering.html
branches/Branch_4_2/tomcat/docs/tc5-clustering.xml
Log:
tomcat -> JBossWeb
Modified: branches/Branch_4_2/tomcat/docs/html/tc5-clustering.html
===================================================================
--- branches/Branch_4_2/tomcat/docs/html/tc5-clustering.html 2007-01-19 17:02:15 UTC (rev 59846)
+++ branches/Branch_4_2/tomcat/docs/html/tc5-clustering.html 2007-01-19 17:05:21 UTC (rev 59847)
@@ -1,6 +1,6 @@
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
- <title>Tomcat 5 Clustering In JBoss Release 3.2.6</title><link rel="stylesheet" href="html.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.62.0"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="d0e1"></a>Tomcat 5 Clustering In JBoss Release 3.2.6</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Ben</span> <span class="surname">Wang</span></h3></div></div><div><p class="pubdate">August, 2004</p></div></div><div></div><hr></div><div class="toc"><dl><dt><span class="section"><a href="#d0e14">1. Introduction</a></span></dt><dt><span class="section"><a href="#d0e23">2. Software Design</a></span></dt><dd><dl><dt><span class="section"><a href="#d0e28">2.1. Class Responsibility</a></span></dt><dt><span class="section"><a href="#d0e105">2.2. Deployment Process</a></span></dt></dl></dd><dt><s!
pan class="section"><a href="#d0e128">3. Features</a></span></dt><dd><dl><dt><span class="section"><a href="#d0e133">3.1. Tomcat level aspect</a></span></dt><dt><span class="section"><a href="#d0e225">3.2. JBossCache level aspect</a></span></dt><dt><span class="section"><a href="#d0e255">3.3. Deprecated</a></span></dt></dl></dd><dt><span class="section"><a href="#d0e284">4. What's New?</a></span></dt><dt><span class="section"><a href="#d0e305">5. Test Case</a></span></dt><dt><span class="section"><a href="#d0e313">6. Sample Usage</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e14"></a>1. Introduction</h2></div></div><div></div></div><p>Nowadays http web clustering (or failover) typically employs either a hardware or software front-end load balancer to distribute the load (with capability of session affinity). And the session state replication is then delegated to the web contain!
er. Naturally, JBoss also has a session replication layer for Tomcat s
ince release 3.x.</p><p>In JBoss release 3.2.6, we have re-factored the Tomcat 5 http session replication framework using JBossCache (http://www.jboss.org/products/jbosscache) as the underlying in-memory replication store. JBossCache is an open-source replicated, transactional, and fine-grained cache system. Using JBossCache as the framework for session replication offers separation of replication layer concerns (e.g., replication mode, lock behavior, partitioning, persistence, and transaction) from the Tomcat session handling logics (e.g., sticky session, replication granularity, and trigger). The end result is a reduced development effort in Tomcat application layer and more robust behavior in the overall system.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e23"></a>2. Software Design</h2></div></div><div></div></div><p>This section describes briefly the high level design and the web applicat!
ion deployment process pertaining to the session replication.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e28"></a>2.1. Class Responsibility</h3></div></div><div></div></div><p>The following is a class diagram focusing on the http session replication using JBossCache as the distributed store service under Tomcat5. </p><div class="figure"><a name="d0e33"></a><p class="title"><b>Figure 1. Tomcat5 http session replication class diagram</b></p><div class="mediaobject"><img src="resources/HttpSessionRepl.gif" alt="Tomcat5 http session replication class diagram"></div></div><p>In addition to the JBossCacheService class that provides replication service, there are three main interfaces: </p><div class="itemizedlist"><ul type="disc"><li><p><tt class="literal">org.jboss.web.tomcat.tc5.session.SnapshotManger.</tt> Interface that defines the API to check for necessary session replication. Note that it has a reference t!
o JBossManager to perform session replication. Two concrete implementa
tion classes are: </p><div class="itemizedlist"><ul type="circle"><li><tt class="literal">org.jboss.web.tomcat.tc5.session.InstantSnapshotManager</tt> . Use of this snapshot manager will check for dirty session after every single http request (through <tt class="literal">org.jboss.web.tomcat.tc5.session.ClusteredSessionValve</tt> ). If a session is dirty, it will then be replicated. </li><li><tt class="literal">org.jboss.web.tomcat.tc5.session.IntervalSnapshotManager</tt> . Use of this snapshot manager will check for dirty session(s) only periodically (with a configurable timer interval). The dirty session(s) will be replicated when the timer kicks in. </li></ul></div></li><li><p><tt class="literal">org.apache.catalina.Manager.</tt> This is a Tomcat catalina interface that handles the session management. The JBossCacheManager is the implemented class that also manages both in-memory session and the sessions located in the distributed store.</p><p>The reason that we need to u!
se the in-memory session instance is because of the web class loader can be different from the system one. As a result, we will need to keep a "serialized" version of the session data in the distributed store (done via <tt class="literal">org.jboss.invocation.MarshalledValue</tt>) so that the class loading scope will be correct. Otherwise, it will be simply too expensive to retrieve and de-serialize every time from the underneath store.</p><p>This manager is also called periodically by catalina to process expired session(s) (or session timeout). When a session is timed-out, it will be deleted from the store. However, the operation is local only. That is, the delete operation will not replicate to other cluster nodes since the other nodes will have similar expiring process in place already. Therefore, the session will be expired simultaneously from the whole cluster view.</p></li><li><p><tt class="literal">org.apache.catalina.Session.</tt> This is a catalina interface that m!
anages the session attributes and track the session life time itself.
We have two different concrete implementation classes in this release: </p><div class="itemizedlist"><ul type="circle"><li><tt class="literal">org.jboss.web.tomcat.tc5.session.SessionBasedClusteredSession.</tt> This corresponds to the setting in <tt class="literal">jboss-web.xml</tt> of <tt class="literal">replication-granulairty</tt> set to <tt class="literal">session.</tt> That is, whenever a session attribute is changed, it will replicate the whole session, regardless. </li><li><tt class="literal">org.jboss.web.tomcat.tc5.session.AttributeBasedClusteredSession.</tt> This corresponds to the setting in <tt class="literal">jboss-web.xml</tt> of <tt class="literal">replication-granulairty</tt> set to <tt class="literal">attribute.</tt> That is, whenever a session attribute is changed, it will replicate only the modified attribute. Note that this option which is finer grain in nature has the potential for session replication performance boost, especially when the session is ca!
rrying a large amount of data. </li></ul></div></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e105"></a>2.2. Deployment Process</h3></div></div><div></div></div><p>When a user deploys (or hot-deploys) a web application, the JBoss <tt class="literal">org.jboss.web.tomcat.tc5.TomcatDeployer</tt> will first determine if the web application is declared <tt class="literal">distributable.</tt> If it is, JBoss will instantiate <tt class="literal">JBossCacheManager</tt>, create <tt class="literal">SnapshotManager</tt> and then add a <tt class="literal">ClusteredSessionValve</tt> to the Tomcat interceptor chain. As a result, every single http request will be intercepted by this valve to process the necessary session replication (through <tt class="literal">SnapshotManager</tt>).</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e128">!
</a>3. Features</h2></div></div><div></div></div><p>Here are the
features provided with this release. For clarity, we will divide them into Tomcat and JBossCache level aspects, meaning the configuration will be done either from JBossCache or the TC5 layer.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e133"></a>3.1. Tomcat level aspect</h3></div></div><div></div></div><p>In <tt class="literal">jbossweb-tomcat5.0/META-INF/jboss-service.xml</tt> , you can configure the followings: </p><div class="itemizedlist"><ul type="disc"><li><tt class="literal">SnapshotMode</tt><div class="itemizedlist"><ul type="circle"><li><tt class="literal">instant</tt> Session replication is performed during each HTTP request. But whether it is instantaneously or not also depends on the replication mode (synchronous or asynchronous) in JBossCache setting. </li><li><tt class="literal">Interval</tt> Replicated during a specified time interval. There is an accompanying flag, <tt class="literal">SnapshotInterval</!
tt>, that indicates the snapshot interval in milliseconds. The <tt class="literal">IntervalSnapshotManager</tt> will perform session dirty check every <tt class="literal">SnapshotInterval.</tt> This manager keeps track of the dirty session(s) internally.</li></ul></div></li><li><p><tt class="literal">UseJK</tt> A flag indicating whether to use the Apache mod_jk(2) for the front end software load balancing with sticky session combined with JvmRoute. If set to true, it will insert a JvmRouteFilter to intercept every request during deployment and replace the JvmRoute if it detects a failover in runtime. In addition, you will need to set the JvmRoute inside Tomcat, e.g., <tt class="literal"><Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost"></tt> in <tt class="literal">jbossweb-tomcat4.0/server.xml</tt>.</p></li></ul></div><p>Note that the above configuration parameters are applied to per Tomcat instance. Change of the parameter will cause Tomcat to re-depl!
oy.</p><p>In each web application, you can also specify in <tt class="
literal">jboss-web.xml</tt> to customize the clustering behavior. Specifically, there is an element called <tt class="literal">replication-config</tt> that contains two sub-elements so far: </p><div class="itemizedlist"><ul type="disc"><li><tt class="literal">replication-trigger</tt> It determines what triggers a session replication (or when is a session is considered dirty). It has 4 options: <div class="itemizedlist"><ul type="circle"><li><p><tt class="literal">ACCESS</tt> Indicating if accessing the session is considered dirty. If set, it is considered dirty with pure access and thus will cause replication. Note that a session is "accessed" during each http request regardless. It will update the access time stamp in the session instance as well. Since the time stamp may not be updated in other clustering nodes (because of no replication), this may cause session in other nodes to expire before the active node if http request does not retrieve or modify any session attribut!
es. </p><p>When this option is set, the session timestamps will be synchronized throughout the cluster nodes. Note that use of this option can have a significant performance impact so you will need to use with caution.</p></li><li><tt class="literal">SET_AND_GET</tt> Every session get and set attributes are considered dirty. This option also can have significant performance impact as well.</li><li><tt class="literal">SET_AND_NON_PRIMITIVE_GET</tt> Session get and non-primitive get are considered dirty. For example, the http session request may retrieve a non-primitive object instance from the attribute and then modify the instance. If we don't specify that non-primitive get is considered dirty, then the modification will not be replication properly. This is the default value. </li><li><tt class="literal">SET</tt> Only set attribute operation is considered dirty. If you are certain that only set attribute operation is necessary for replication, this option will be most optim!
ized in term of performance.</li></ul></div></li><li><tt class="litera
l">replication-granularity</tt><div class="itemizedlist"><ul type="circle"><li><tt class="literal">session</tt> Replication is per session instance. As long as it is considered modified when the snapshot manager is called, the whole session object will be serialized. </li><li><tt class="literal">attribute</tt> Replication is only for the dirty attributes plus some session data, like, lastAccessTime. For session that carries large amount of data, this option can increase replication performance. </li><li><tt class="literal">field</tt> Will need aop (aspect-oriented programming) and be available in 4.0.4. User can have control of even finer grain replication through its own object graph. For example, if one stores another map object into the session as an attribute, we can track the dirty field down to the value object inside the map. </li></ul></div></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e225"></a>3.2!
. JBossCache level aspect</h3></div></div><div></div></div><p>The main configuration file is <tt class="literal">tc5-cluster-service.xml</tt> of which is basically a minimum version of JBossCache configuration xml file (more details later). </p><div class="itemizedlist"><ul type="disc"><li><tt class="literal">CacheMode</tt><div class="itemizedlist"><ul type="circle"><li><tt class="literal">REPL_SYNC</tt> Replication is synchronous and call is blocking until replication succeeds or fails. That is, replication will be completed before the http request returns. </li><li><tt class="literal">REPLY_ASYNC</tt> Replication is asynchronous and call is non-blocking. Does not wait for results for the http request to return. When session state replication is allowed to have some latency, this is useful and will have a much better performance throughput. </li></ul></div></li></ul></div><p>In the future release, we will also add the following features from JBossCache. </p><div class!
="itemizedlist"><ul type="disc"><li> (sub)-Partitioning. This feature
will partition the cluster into different sub-partitions such that replication only happens in the sub-partition nodes. With this feature, the session replication cluster can then be easily scaled. </li><li> Persistence. Persist the session data to the backed store. Currently, clustered session does not support any persistency. </li><li> Eviction policy and cache data overflow memory size or time-based eviction policy with overflow to back end persistent store. This is useful for users who have long running sessions that needs to support passivation. </li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e255"></a>3.3. Deprecated</h3></div></div><div></div></div><p>The following features have been deprecated in the new release: </p><div class="itemizedlist"><ul type="disc"><li><p><tt class="literal">replication-type</tt> in <tt class="literal">jboss-web.xml.</tt> User should directly configure the replication t!
ype from <tt class="literal">tc5-cluster-service.xml</tt> with the element <tt class="literal"><tt class="literal">CacheMode</tt></tt>.</p></li><li><p><tt class="literal">UseLocalCache</tt> in <tt class="literal">jbossweb-tomcat5.0/META-INF/jboss-service.xml.</tt> Local in-vm session is used by default now.</p></li></ul></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e284"></a>4. What's New?</h2></div></div><div></div></div><p>JBossCache can be configured through a xml configuration and deployed under JBoss3.2.6 as a MBean service. Since JBossCache is used not only for clustering but also for <tt class="literal">SSO</tt> (single sign on) replication as well, we have introduced a JBossCache tc5 clustering MBean service for everyone to share (such as <tt class="literal">SSO</tt> replication). The xml configuration file will be called <tt class="literal">tc5-cluster-service.xml</tt>. Once t!
he file is deployed, a MBean called <tt class="literal">TomcatClusteri
ngCache</tt> will be created.</p><p>In the file, there are JBossCache configuration parameters but customized for the tc5 clustering. Here is a snippet of the xml:</p><pre class="programlisting"><server>
+ <title>Tomcat 5 Clustering In JBoss Release 3.2.6</title><link rel="stylesheet" href="html.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.62.0"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="d0e1"></a>Tomcat 5 Clustering In JBoss Release 3.2.6</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Ben</span> <span class="surname">Wang</span></h3></div></div><div><p class="pubdate">August, 2004</p></div></div><div></div><hr></div><div class="toc"><dl><dt><span class="section"><a href="#d0e14">1. Introduction</a></span></dt><dt><span class="section"><a href="#d0e23">2. Software Design</a></span></dt><dd><dl><dt><span class="section"><a href="#d0e28">2.1. Class Responsibility</a></span></dt><dt><span class="section"><a href="#d0e105">2.2. Deployment Process</a></span></dt></dl></dd><dt><s!
pan class="section"><a href="#d0e128">3. Features</a></span></dt><dd><dl><dt><span class="section"><a href="#d0e133">3.1. Tomcat level aspect</a></span></dt><dt><span class="section"><a href="#d0e225">3.2. JBossCache level aspect</a></span></dt><dt><span class="section"><a href="#d0e255">3.3. Deprecated</a></span></dt></dl></dd><dt><span class="section"><a href="#d0e284">4. What's New?</a></span></dt><dt><span class="section"><a href="#d0e305">5. Test Case</a></span></dt><dt><span class="section"><a href="#d0e313">6. Sample Usage</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e14"></a>1. Introduction</h2></div></div><div></div></div><p>Nowadays http web clustering (or failover) typically employs either a hardware or software front-end load balancer to distribute the load (with capability of session affinity). And the session state replication is then delegated to the web contain!
er. Naturally, JBoss also has a session replication layer for Tomcat s
ince release 3.x.</p><p>In JBoss release 3.2.6, we have re-factored the Tomcat 5 http session replication framework using JBossCache (http://www.jboss.org/products/jbosscache) as the underlying in-memory replication store. JBossCache is an open-source replicated, transactional, and fine-grained cache system. Using JBossCache as the framework for session replication offers separation of replication layer concerns (e.g., replication mode, lock behavior, partitioning, persistence, and transaction) from the Tomcat session handling logics (e.g., sticky session, replication granularity, and trigger). The end result is a reduced development effort in Tomcat application layer and more robust behavior in the overall system.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e23"></a>2. Software Design</h2></div></div><div></div></div><p>This section describes briefly the high level design and the web applicat!
ion deployment process pertaining to the session replication.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e28"></a>2.1. Class Responsibility</h3></div></div><div></div></div><p>The following is a class diagram focusing on the http session replication using JBossCache as the distributed store service under Tomcat5. </p><div class="figure"><a name="d0e33"></a><p class="title"><b>Figure 1. Tomcat5 http session replication class diagram</b></p><div class="mediaobject"><img src="resources/HttpSessionRepl.gif" alt="Tomcat5 http session replication class diagram"></div></div><p>In addition to the JBossCacheService class that provides replication service, there are three main interfaces: </p><div class="itemizedlist"><ul type="disc"><li><p><tt class="literal">org.jboss.web.tomcat.service.session.SnapshotManger.</tt> Interface that defines the API to check for necessary session replication. Note that it has a referen!
ce to JBossManager to perform session replication. Two concrete implem
entation classes are: </p><div class="itemizedlist"><ul type="circle"><li><tt class="literal">org.jboss.web.tomcat.service.session.InstantSnapshotManager</tt> . Use of this snapshot manager will check for dirty session after every single http request (through <tt class="literal">org.jboss.web.tomcat.service.session.ClusteredSessionValve</tt> ). If a session is dirty, it will then be replicated. </li><li><tt class="literal">org.jboss.web.tomcat.service.session.IntervalSnapshotManager</tt> . Use of this snapshot manager will check for dirty session(s) only periodically (with a configurable timer interval). The dirty session(s) will be replicated when the timer kicks in. </li></ul></div></li><li><p><tt class="literal">org.apache.catalina.Manager.</tt> This is a Tomcat catalina interface that handles the session management. The JBossCacheManager is the implemented class that also manages both in-memory session and the sessions located in the distributed store.</p><p>The reason t!
hat we need to use the in-memory session instance is because of the web class loader can be different from the system one. As a result, we will need to keep a "serialized" version of the session data in the distributed store (done via <tt class="literal">org.jboss.invocation.MarshalledValue</tt>) so that the class loading scope will be correct. Otherwise, it will be simply too expensive to retrieve and de-serialize every time from the underneath store.</p><p>This manager is also called periodically by catalina to process expired session(s) (or session timeout). When a session is timed-out, it will be deleted from the store. However, the operation is local only. That is, the delete operation will not replicate to other cluster nodes since the other nodes will have similar expiring process in place already. Therefore, the session will be expired simultaneously from the whole cluster view.</p></li><li><p><tt class="literal">org.apache.catalina.Session.</tt> This is a catalina !
interface that manages the session attributes and track the session li
fe time itself. We have two different concrete implementation classes in this release: </p><div class="itemizedlist"><ul type="circle"><li><tt class="literal">org.jboss.web.tomcat.service.session.SessionBasedClusteredSession.</tt> This corresponds to the setting in <tt class="literal">jboss-web.xml</tt> of <tt class="literal">replication-granulairty</tt> set to <tt class="literal">session.</tt> That is, whenever a session attribute is changed, it will replicate the whole session, regardless. </li><li><tt class="literal">org.jboss.web.tomcat.service.session.AttributeBasedClusteredSession.</tt> This corresponds to the setting in <tt class="literal">jboss-web.xml</tt> of <tt class="literal">replication-granulairty</tt> set to <tt class="literal">attribute.</tt> That is, whenever a session attribute is changed, it will replicate only the modified attribute. Note that this option which is finer grain in nature has the potential for session replication performance boost, especiall!
y when the session is carrying a large amount of data. </li></ul></div></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e105"></a>2.2. Deployment Process</h3></div></div><div></div></div><p>When a user deploys (or hot-deploys) a web application, the JBoss <tt class="literal">org.jboss.web.tomcat.service.TomcatDeployer</tt> will first determine if the web application is declared <tt class="literal">distributable.</tt> If it is, JBoss will instantiate <tt class="literal">JBossCacheManager</tt>, create <tt class="literal">SnapshotManager</tt> and then add a <tt class="literal">ClusteredSessionValve</tt> to the Tomcat interceptor chain. As a result, every single http request will be intercepted by this valve to process the necessary session replication (through <tt class="literal">SnapshotManager</tt>).</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="cl!
ear: both"><a name="d0e128"></a>3. Features</h2></div></div><div>
</div></div><p>Here are the features provided with this release. For clarity, we will divide them into Tomcat and JBossCache level aspects, meaning the configuration will be done either from JBossCache or the TC5 layer.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e133"></a>3.1. Tomcat level aspect</h3></div></div><div></div></div><p>In <tt class="literal">jbossweb-tomcat5.0/META-INF/jboss-service.xml</tt> , you can configure the followings: </p><div class="itemizedlist"><ul type="disc"><li><tt class="literal">SnapshotMode</tt><div class="itemizedlist"><ul type="circle"><li><tt class="literal">instant</tt> Session replication is performed during each HTTP request. But whether it is instantaneously or not also depends on the replication mode (synchronous or asynchronous) in JBossCache setting. </li><li><tt class="literal">Interval</tt> Replicated during a specified time interval. There is an accompanying flag, <tt class=!
"literal">SnapshotInterval</tt>, that indicates the snapshot interval in milliseconds. The <tt class="literal">IntervalSnapshotManager</tt> will perform session dirty check every <tt class="literal">SnapshotInterval.</tt> This manager keeps track of the dirty session(s) internally.</li></ul></div></li><li><p><tt class="literal">UseJK</tt> A flag indicating whether to use the Apache mod_jk(2) for the front end software load balancing with sticky session combined with JvmRoute. If set to true, it will insert a JvmRouteFilter to intercept every request during deployment and replace the JvmRoute if it detects a failover in runtime. In addition, you will need to set the JvmRoute inside Tomcat, e.g., <tt class="literal"><Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost"></tt> in <tt class="literal">jbossweb-tomcat4.0/server.xml</tt>.</p></li></ul></div><p>Note that the above configuration parameters are applied to per Tomcat instance. Change of the parameter !
will cause Tomcat to re-deploy.</p><p>In each web application, you can
also specify in <tt class="literal">jboss-web.xml</tt> to customize the clustering behavior. Specifically, there is an element called <tt class="literal">replication-config</tt> that contains two sub-elements so far: </p><div class="itemizedlist"><ul type="disc"><li><tt class="literal">replication-trigger</tt> It determines what triggers a session replication (or when is a session is considered dirty). It has 4 options: <div class="itemizedlist"><ul type="circle"><li><p><tt class="literal">ACCESS</tt> Indicating if accessing the session is considered dirty. If set, it is considered dirty with pure access and thus will cause replication. Note that a session is "accessed" during each http request regardless. It will update the access time stamp in the session instance as well. Since the time stamp may not be updated in other clustering nodes (because of no replication), this may cause session in other nodes to expire before the active node if http request does not retrieve or!
modify any session attributes. </p><p>When this option is set, the session timestamps will be synchronized throughout the cluster nodes. Note that use of this option can have a significant performance impact so you will need to use with caution.</p></li><li><tt class="literal">SET_AND_GET</tt> Every session get and set attributes are considered dirty. This option also can have significant performance impact as well.</li><li><tt class="literal">SET_AND_NON_PRIMITIVE_GET</tt> Session get and non-primitive get are considered dirty. For example, the http session request may retrieve a non-primitive object instance from the attribute and then modify the instance. If we don't specify that non-primitive get is considered dirty, then the modification will not be replication properly. This is the default value. </li><li><tt class="literal">SET</tt> Only set attribute operation is considered dirty. If you are certain that only set attribute operation is necessary for replication, th!
is option will be most optimized in term of performance.</li></ul></di
v></li><li><tt class="literal">replication-granularity</tt><div class="itemizedlist"><ul type="circle"><li><tt class="literal">session</tt> Replication is per session instance. As long as it is considered modified when the snapshot manager is called, the whole session object will be serialized. </li><li><tt class="literal">attribute</tt> Replication is only for the dirty attributes plus some session data, like, lastAccessTime. For session that carries large amount of data, this option can increase replication performance. </li><li><tt class="literal">field</tt> Will need aop (aspect-oriented programming) and be available in 4.0.4. User can have control of even finer grain replication through its own object graph. For example, if one stores another map object into the session as an attribute, we can track the dirty field down to the value object inside the map. </li></ul></div></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="tit!
le"><a name="d0e225"></a>3.2. JBossCache level aspect</h3></div></div><div></div></div><p>The main configuration file is <tt class="literal">tc5-cluster-service.xml</tt> of which is basically a minimum version of JBossCache configuration xml file (more details later). </p><div class="itemizedlist"><ul type="disc"><li><tt class="literal">CacheMode</tt><div class="itemizedlist"><ul type="circle"><li><tt class="literal">REPL_SYNC</tt> Replication is synchronous and call is blocking until replication succeeds or fails. That is, replication will be completed before the http request returns. </li><li><tt class="literal">REPLY_ASYNC</tt> Replication is asynchronous and call is non-blocking. Does not wait for results for the http request to return. When session state replication is allowed to have some latency, this is useful and will have a much better performance throughput. </li></ul></div></li></ul></div><p>In the future release, we will also add the following features fro!
m JBossCache. </p><div class="itemizedlist"><ul type="disc"><li> (sub)
-Partitioning. This feature will partition the cluster into different sub-partitions such that replication only happens in the sub-partition nodes. With this feature, the session replication cluster can then be easily scaled. </li><li> Persistence. Persist the session data to the backed store. Currently, clustered session does not support any persistency. </li><li> Eviction policy and cache data overflow memory size or time-based eviction policy with overflow to back end persistent store. This is useful for users who have long running sessions that needs to support passivation. </li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e255"></a>3.3. Deprecated</h3></div></div><div></div></div><p>The following features have been deprecated in the new release: </p><div class="itemizedlist"><ul type="disc"><li><p><tt class="literal">replication-type</tt> in <tt class="literal">jboss-web.xml.</tt> User should directly!
configure the replication type from <tt class="literal">tc5-cluster-service.xml</tt> with the element <tt class="literal"><tt class="literal">CacheMode</tt></tt>.</p></li><li><p><tt class="literal">UseLocalCache</tt> in <tt class="literal">jbossweb-tomcat5.0/META-INF/jboss-service.xml.</tt> Local in-vm session is used by default now.</p></li></ul></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e284"></a>4. What's New?</h2></div></div><div></div></div><p>JBossCache can be configured through a xml configuration and deployed under JBoss3.2.6 as a MBean service. Since JBossCache is used not only for clustering but also for <tt class="literal">SSO</tt> (single sign on) replication as well, we have introduced a JBossCache tc5 clustering MBean service for everyone to share (such as <tt class="literal">SSO</tt> replication). The xml configuration file will be called <tt class="literal">tc5-clus!
ter-service.xml</tt>. Once the file is deployed, a MBean called <tt cl
ass="literal">TomcatClusteringCache</tt> will be created.</p><p>In the file, there are JBossCache configuration parameters but customized for the tc5 clustering. Here is a snippet of the xml:</p><pre class="programlisting"><server>
<mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TomcatClusteringCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
Modified: branches/Branch_4_2/tomcat/docs/tc5-clustering.xml
===================================================================
--- branches/Branch_4_2/tomcat/docs/tc5-clustering.xml 2007-01-19 17:02:15 UTC (rev 59846)
+++ branches/Branch_4_2/tomcat/docs/tc5-clustering.xml 2007-01-19 17:05:21 UTC (rev 59847)
@@ -63,7 +63,7 @@
<para>In addition to the JBossCacheService class that provides
replication service, there are three main interfaces: <itemizedlist>
<listitem>
- <para><literal>org.jboss.web.tomcat.tc5.session.SnapshotManger.</literal>
+ <para><literal>org.jboss.web.tomcat.service.session.SnapshotManger.</literal>
Interface that defines the API to check for necessary session
replication. Note that it has a reference to JBossManager to
perform session replication. Two concrete implementation classes
@@ -71,11 +71,11 @@
<listitem>
- <literal>org.jboss.web.tomcat.tc5.session.InstantSnapshotManager</literal>
+ <literal>org.jboss.web.tomcat.service.session.InstantSnapshotManager</literal>
. Use of this snapshot manager will check for dirty session after every single http request (through
- <literal>org.jboss.web.tomcat.tc5.session.ClusteredSessionValve</literal>
+ <literal>org.jboss.web.tomcat.service.session.ClusteredSessionValve</literal>
). If a session is dirty, it will then be replicated.
</listitem>
@@ -83,7 +83,7 @@
<listitem>
- <literal>org.jboss.web.tomcat.tc5.session.IntervalSnapshotManager</literal>
+ <literal>org.jboss.web.tomcat.service.session.IntervalSnapshotManager</literal>
. Use of this snapshot manager will check for dirty session(s) only periodically (with a configurable timer interval). The dirty session(s) will be replicated when the timer kicks in.
</listitem>
@@ -123,7 +123,7 @@
<listitem>
- <literal>org.jboss.web.tomcat.tc5.session.SessionBasedClusteredSession.</literal>
+ <literal>org.jboss.web.tomcat.service.session.SessionBasedClusteredSession.</literal>
This corresponds to the setting in
@@ -143,7 +143,7 @@
<listitem>
- <literal>org.jboss.web.tomcat.tc5.session.AttributeBasedClusteredSession.</literal>
+ <literal>org.jboss.web.tomcat.service.session.AttributeBasedClusteredSession.</literal>
This corresponds to the setting in
@@ -168,7 +168,7 @@
<title>Deployment Process</title>
<para>When a user deploys (or hot-deploys) a web application, the JBoss
- <literal>org.jboss.web.tomcat.tc5.TomcatDeployer</literal> will first
+ <literal>org.jboss.web.tomcat.service.TomcatDeployer</literal> will first
determine if the web application is declared
<literal>distributable.</literal> If it is, JBoss will instantiate
<literal>JBossCacheManager</literal>, create
More information about the jboss-cvs-commits
mailing list