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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
