[tomcat] branch 8.5.x updated (37b19e3 -> 2338d6d)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[tomcat] branch 8.5.x updated (37b19e3 -> 2338d6d)

markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


    from 37b19e3  Polish. Add spaces
     new ac1121e  spelling and formatting corrections for cluster-howto
     new 2338d6d  Changelog entry for previous commit.

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 webapps/docs/changelog.xml     |  4 ++++
 webapps/docs/cluster-howto.xml | 51 +++++++++++++++++++++---------------------
 2 files changed, 29 insertions(+), 26 deletions(-)


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[tomcat] 01/02: spelling and formatting corrections for cluster-howto

markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit ac1121e4b5cac1111e1de3976accfa0f472584ec
Author: Bill Mitchell <[hidden email]>
AuthorDate: Tue Sep 10 16:59:18 2019 -0400

    spelling and formatting corrections for cluster-howto
---
 webapps/docs/cluster-howto.xml | 51 +++++++++++++++++++++---------------------
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml
index d05f708..736b290 100644
--- a/webapps/docs/cluster-howto.xml
+++ b/webapps/docs/cluster-howto.xml
@@ -481,13 +481,13 @@ should be completed:</p>
 
 </section>
 <section name="How it Works">
-<p>To make it easy to understand how clustering works, We are gonna take you through a series of scenarios.
-   In the scenario we only plan to use two tomcat instances <code>TomcatA</code> and <code>TomcatB</code>.
+<p>To make it easy to understand how clustering works, we are gonna to take you through a series of scenarios.
+   In this scenario we only plan to use two tomcat instances <code>TomcatA</code> and <code>TomcatB</code>.
    We will cover the following sequence of events:</p>
 
 <ol>
 <li><code>TomcatA</code> starts up</li>
-<li><code>TomcatB</code> starts up (Wait that TomcatA start is complete)</li>
+<li><code>TomcatB</code> starts up (Wait the TomcatA start is complete)</li>
 <li><code>TomcatA</code> receives a request, a session <code>S1</code> is created.</li>
 <li><code>TomcatA</code> crashes</li>
 <li><code>TomcatB</code> receives a request for session <code>S1</code></li>
@@ -503,7 +503,7 @@ should be completed:</p>
 <li><b><code>TomcatA</code> starts up</b>
     <p>
         Tomcat starts up using the standard start up sequence. When the Host object is created, a cluster object is associated with it.
-        When the contexts are parsed, if the distributable element is in place in web.xml
+        When the contexts are parsed, if the distributable element is in place in the web.xml file,
         Tomcat asks the Cluster class (in this case <code>SimpleTcpCluster</code>) to create a manager
         for the replicated context. So with clustering enabled, distributable set in web.xml
         Tomcat will create a <code>DeltaManager</code> for that context instead of a <code>StandardManager</code>.
@@ -514,38 +514,37 @@ should be completed:</p>
 <li><b><code>TomcatB</code> starts up</b>
     <p>
         When TomcatB starts up, it follows the same sequence as TomcatA did with one exception.
-        The cluster is started and will establish a membership (TomcatA,TomcatB).
+        The cluster is started and will establish a membership (TomcatA, TomcatB).
         TomcatB will now request the session state from a server that already exists in the cluster,
         in this case TomcatA. TomcatA responds to the request, and before TomcatB starts listening
         for HTTP requests, the state has been transferred from TomcatA to TomcatB.
-        In case TomcatA doesn't respond, TomcatB will time out after 60 seconds, and issue a log
-        entry. The session state gets transferred for each web application that has distributable in
-        its web.xml. Note: To use session replication efficiently, all your tomcat instances should be
-        configured the same.
+        In case TomcatA doesn't respond, TomcatB will time out after 60 seconds, issue a log
+        entry, and continue starting. The session state gets transferred for each web
+        application that has distributable in its web.xml. (Note: To use session replication
+        efficiently, all your tomcat instances should be configured the same.)
     </p>
 </li>
 <li><B><code>TomcatA</code> receives a request, a session <code>S1</code> is created.</B>
     <p>
-        The request coming in to TomcatA is treated exactly the same way as without session replication.
-        The action happens when the request is completed, the <code>ReplicationValve</code> will intercept
-        the request before the response is returned to the user.
-        At this point it finds that the session has been modified, and it uses TCP to replicate the
-        session to TomcatB. Once the serialized data has been handed off to the operating systems TCP logic,
-        the request returns to the user, back through the valve pipeline.
-        For each request the entire session is replicated, this allows code that modifies attributes
-        in the session without calling setAttribute or removeAttribute to be replicated.
-        a useDirtyFlag configuration parameter can be used to optimize the number of times
-        a session is replicated.
+        The request coming in to TomcatA is handled exactly the same way as without session
+        replication, until the request is completed, at which time the
+        <code>ReplicationValve</code> will intercept the request before the response is
+        returned to the user.  At this point it finds that the session has been modified,
+        and it uses TCP to replicate the session to TomcatB. Once the serialized data has
+        been handed off to the operating system's TCP logic, the request returns to the user,
+        back through the valve pipeline.  For each request the entire session is replicated,
+        this allows code that modifies attributes in the session without calling setAttribute
+        or removeAttribute to be replicated.  A useDirtyFlag configuration parameter can
+        be used to optimize the number of times a session is replicated.
     </p>
 
 </li>
 <li><b><code>TomcatA</code> crashes</b>
     <p>
         When TomcatA crashes, TomcatB receives a notification that TomcatA has dropped out
-        of the cluster. TomcatB removes TomcatA from its membership list, and TomcatA will no longer
-        be notified of any changes that occurs in TomcatB.
-        The load balancer will redirect the requests from TomcatA to TomcatB and all the sessions
-        are current.
+        of the cluster. TomcatB removes TomcatA from its membership list, and TomcatA will
+        no longer be notified of any changes that occurs in TomcatB.  The load balancer
+        will redirect the requests from TomcatA to TomcatB and all the sessions are current.
     </p>
 </li>
 <li><b><code>TomcatB</code> receives a request for session <code>S1</code></b>
@@ -574,7 +573,7 @@ should be completed:</p>
 
 </li>
 <li><code>TomcatA</code> The session <code>S2</code> expires due to inactivity.
-    <p>The invalidate call is intercepted the same was as when a session is invalidated by the user,
+    <p>The invalidate call is intercepted the same way as when a session is invalidated by the user,
        and the session is queued with invalidated sessions.
        At this point, the invalidated session will not be replicated across until
        another request comes through the system and checks the invalid queue.
@@ -587,7 +586,7 @@ should be completed:</p>
 <p><b>Membership</b>
     Clustering membership is established using very simple multicast pings.
     Each Tomcat instance will periodically send out a multicast ping,
-    in the ping message the instance will broad cast its IP and TCP listen port
+    in the ping message the instance will broadcast its IP and TCP listen port
     for replication.
     If an instance has not received such a ping within a given timeframe, the
     member is considered dead. Very simple, and very effective!
@@ -598,7 +597,7 @@ should be completed:</p>
     Once a multicast ping has been received, the member is added to the cluster
     Upon the next replication request, the sending instance will use the host and
     port info and establish a TCP socket. Using this socket it sends over the serialized data.
-    The reason I choose TCP sockets is because it has built in flow control and guaranteed delivery.
+    The reason I chose TCP sockets is because it has built in flow control and guaranteed delivery.
     So I know, when I send some data, it will make it there :)
 </p>
 


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[tomcat] 02/02: Changelog entry for previous commit.

markt
In reply to this post by markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 2338d6d293a48a6a59211a23d771297360753ce0
Author: Mark Thomas <[hidden email]>
AuthorDate: Wed Sep 11 18:36:34 2019 +0100

    Changelog entry for previous commit.
---
 webapps/docs/changelog.xml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 46de0ac..4ac22f9 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -104,6 +104,10 @@
         Fix a large number of Javadoc and documentation typos. Patch provided by
         KangZhiDong. (markt)
       </fix>
+      <fix>
+        Spelling and formatting corrections for the cluster how-to. Pull request
+        provided by Bill Mitchell. (markt)
+      </fix>
     </changelog>
   </subsection>
   <subsection name="Other">


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]