[tomcat] 01/02: spelling and formatting corrections for cluster-howto
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 7.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 45958d01215f359638a2a3d6c4d133bafc126bb9 Author: Bill Mitchell 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 456ea58..02cd9c2 100644 --- a/webapps/docs/cluster-howto.xml +++ b/webapps/docs/cluster-howto.xml @@ -478,13 +478,13 @@ should be completed: -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 TomcatA and TomcatB. +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 TomcatA and TomcatB. We will cover the following sequence of events: TomcatA starts up -TomcatB starts up (Wait that TomcatA start is complete) +TomcatB starts up (Wait the TomcatA start is complete) TomcatA receives a request, a session S1 is created. TomcatA crashes TomcatB receives a request for session S1 @@ -500,7 +500,7 @@ should be completed: TomcatA starts up 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 SimpleTcpCluster) to create a manager for the replicated context. So with clustering enabled, distributable set in web.xml Tomcat will create a DeltaManager for that context instead of a StandardManager. @@ -511,38 +511,37 @@ should be completed: TomcatB starts up 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.) TomcatA receives a request, a session S1 is created. -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 ReplicationValve 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 +ReplicationValve 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
[tomcat] 01/02: spelling and formatting corrections for cluster-howto
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 ac1121e4b5cace1de3976accfa0f472584ec Author: Bill Mitchell 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: -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 TomcatA and TomcatB. +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 TomcatA and TomcatB. We will cover the following sequence of events: TomcatA starts up -TomcatB starts up (Wait that TomcatA start is complete) +TomcatB starts up (Wait the TomcatA start is complete) TomcatA receives a request, a session S1 is created. TomcatA crashes TomcatB receives a request for session S1 @@ -503,7 +503,7 @@ should be completed: TomcatA starts up 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 SimpleTcpCluster) to create a manager for the replicated context. So with clustering enabled, distributable set in web.xml Tomcat will create a DeltaManager for that context instead of a StandardManager. @@ -514,38 +514,37 @@ should be completed: TomcatB starts up 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.) TomcatA receives a request, a session S1 is created. -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 ReplicationValve 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 +ReplicationValve 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
