You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2012/07/12 00:51:36 UTC
svn commit: r1360461 - in /tomcat/tc7.0.x/trunk: ./
webapps/docs/changelog.xml webapps/docs/cluster-howto.xml
Author: markt
Date: Wed Jul 11 22:51:35 2012
New Revision: 1360461
URL: http://svn.apache.org/viewvc?rev=1360461&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53524
Fix typo and spelling
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml
Propchange: tomcat/tc7.0.x/trunk/
------------------------------------------------------------------------------
Merged /tomcat/trunk:r1360455,1360460
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1360461&r1=1360460&r2=1360461&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Jul 11 22:51:35 2012
@@ -107,6 +107,11 @@
Update JSTL version information in the JNDI section of the documentation
web application. (markt)
</fix>
+ <fix>
+ <bug>53524</bug>: Correct a typo in the cluster how-to section of the
+ documentation web application. Also fix a handful of spelling errors.
+ (markt)
+ </fix>
</changelog>
</subsection>
</section>
Modified: tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml?rev=1360461&r1=1360460&r2=1360461&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml Wed Jul 11 22:51:35 2012
@@ -47,7 +47,7 @@
<p>
Using the above configuration will enable all-to-all session replication
using the <code>DeltaManager</code> to replicate session deltas. By all-to-all we mean that the session gets replicated to all the other
- nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of tomcat nodes).
+ nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of Tomcat nodes).
Also when using the delta manager it will replicate to all nodes, even nodes that don't have the application deployed.<br/>
To get around this problem, you'll want to use the BackupManager. This manager only replicates the session data to one backup
node, and only to nodes that have the application deployed. Downside of the BackupManager: not quite as battle tested as the delta manager.
@@ -147,7 +147,7 @@ should be completed:</p>
The all-to-all replication is an algorithm that is only efficient when the clusters are small. For larger clusters, to use
a primary-secondary session replication where the session will only be stored at one backup server simply setup the BackupManager. <br/>
Currently you can use the domain worker attribute (mod_jk > 1.2.8) to build cluster partitions
- with the potential of having a more scaleable cluster solution with the DeltaManager(you'll need to configure the domain interceptor for this).
+ with the potential of having a more scalable cluster solution with the DeltaManager(you'll need to configure the domain interceptor for this).
In order to keep the network traffic down in an all-to-all environment, you can split your cluster
into smaller groups. This can be easily achieved by using different multicast addresses for the different groups.
A very simple setup would look like this:
@@ -209,7 +209,7 @@ should be completed:</p>
The JvmRouteBinderValve rewrites the session id to ensure that the next request will remain sticky
(and not fall back to go to random nodes since the worker is no longer available) after a fail over.
The valve rewrites the JSESSIONID value in the cookie with the same name.
- Not having this valve in place, will make it harder to ensure stickyness in case of a failure for the mod_jk module.
+ Not having this valve in place, will make it harder to ensure stickiness in case of a failure for the mod_jk module.
</p>
<p>
By default, if no valves are configured, the JvmRouteBinderValve is added on.
@@ -337,8 +337,8 @@ should be completed:</p>
<code>StaticMembershipInterceptor</code> if you want to extend your membership to points beyond multicasting.
The address attribute is the multicast address used and the port is the multicast port. These two together
create the cluster separation. If you want a QA cluster and a production cluster, the easiest config is to
- have the QA cluster be on a separate multicast address/port combination the the production cluster.<br/>
- The membership component broadcasts TCP adress/port of itselt to the other nodes so that communication between
+ have the QA cluster be on a separate multicast address/port combination than the production cluster.<br/>
+ The membership component broadcasts TCP address/port of itself to the other nodes so that communication between
nodes can be done over TCP. Please note that the address being broadcasted is the one of the
<code>Receiver.address</code> attribute.
<br/>For more info, Please visit the <a href="config/cluster-membership.html">reference documentation</a>
@@ -382,7 +382,7 @@ should be completed:</p>
<p>
Tribes uses a stack to send messages through. Each element in the stack is called an interceptor, and works much like the valves do
in the Tomcat servlet container.
- Using interceptors, logic can be broken into more managable pieces of code. The interceptors configured above are:<br/>
+ Using interceptors, logic can be broken into more manageable pieces of code. The interceptors configured above are:<br/>
TcpFailureDetector - verifies crashed members through TCP, if multicast packets get dropped, this interceptor protects against false positives,
ie the node marked as crashed even though it still is alive and running.<br/>
MessageDispatch15Interceptor - dispatches messages to a thread (thread pool) to send message asynchrously.<br/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org