[trafficserver] branch 9.0.x updated: Fixes misc. spelling and whitespace (#6160)

[zw...@apache.org]

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

zwoop pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/trafficserver.git


The following commit(s) were added to refs/heads/9.0.x by this push:
     new 9e5a07a  Fixes misc. spelling and whitespace (#6160)
9e5a07a is described below

commit 9e5a07ae87297487a4d9aa7482729ac043944099
Author: Randall Meyer <rr...@apache.org>
AuthorDate: Thu Nov 14 16:44:37 2019 +0800

    Fixes misc. spelling and whitespace (#6160)
    
    (cherry picked from commit 6ef4db40f24f707bbd05d5ef05cb2e4b5d35f91b)
    
    Conflicts:
    	doc/admin-guide/files/records.config.en.rst
    	doc/release-notes/upgrading.en.rst
    	doc/release-notes/whats-new.en.rst
---
 doc/admin-guide/files/records.config.en.rst      |  2 +-
 doc/developer-guide/api/functions/TSRemap.en.rst |  2 +-
 doc/developer-guide/plugins/remap-plugins.en.rst | 12 ++++++------
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/admin-guide/files/records.config.en.rst b/doc/admin-guide/files/records.config.en.rst
index c11ce44..d9999df 100644
--- a/doc/admin-guide/files/records.config.en.rst
+++ b/doc/admin-guide/files/records.config.en.rst
@@ -319,7 +319,7 @@ Thread Variables
 
 .. ts:cv:: CONFIG proxy.config.exec_thread.listen INT 0
 
-   If enabled (``1``) all the exex_threads listen for incoming connections. `proxy.config.accept_threads`
+   If enabled (``1``) all the exec_threads listen for incoming connections. `proxy.config.accept_threads`
    should be disabled to enable this variable.
 
 .. ts:cv:: CONFIG proxy.config.accept_threads INT 1
diff --git a/doc/developer-guide/api/functions/TSRemap.en.rst b/doc/developer-guide/api/functions/TSRemap.en.rst
index 89df430..c541f20 100644
--- a/doc/developer-guide/api/functions/TSRemap.en.rst
+++ b/doc/developer-guide/api/functions/TSRemap.en.rst
@@ -74,7 +74,7 @@ invoked by current and all previous still used configurations. This is an option
 
 :func:`TSRemapPostConfigReload` is called to indicate the end of the the new remap configuration
 load. It is called on the newly and previously loaded plugins, invoked by the new, current and
-previous still used configurations. It also indicates wheather the configuration reload was successful
+previous still used configurations. It also indicates whether the configuration reload was successful
 by passing :macro:`TSREMAP_CONFIG_RELOAD_FAILURE` in case of failure and to notify the plugins if they
 are going to be part of the new configuration by passing :macro:`TSREMAP_CONFIG_RELOAD_SUCCESS_PLUGIN_USED`
 or :macro:`TSREMAP_CONFIG_RELOAD_SUCCESS_PLUGIN_UNUSED`. This is an optional entry point.
diff --git a/doc/developer-guide/plugins/remap-plugins.en.rst b/doc/developer-guide/plugins/remap-plugins.en.rst
index 9884834..b70a8ee 100644
--- a/doc/developer-guide/plugins/remap-plugins.en.rst
+++ b/doc/developer-guide/plugins/remap-plugins.en.rst
@@ -53,7 +53,7 @@ should be placed in :arg:`errbuff`, taking note of the maximum size of the buffe
 :macro:`TS_SUCCESS`.
 
 If :func:`TSRemapInit` returns :macro:`TS_ERROR` then the remap configuration loading
-is aborted immediatelly.
+is aborted immediately.
 
 This function should perform any plugin global initialization, such as setting up static data
 tables. It only be called immediately after the dynamic library is loaded from disk.
@@ -94,7 +94,7 @@ If there is an error then the callback should return :macro:`TS_ERROR` and fill
 :macro:`TS_SUCCESS`.
 
 If :func:`TSRemapNewInstance` returns :macro:`TS_ERROR` then the remap configuration loading
-is aborted immediatelly.
+is aborted immediately.
 
 
 Configuration reload notifications
@@ -102,12 +102,12 @@ Configuration reload notifications
 
 Most of the plugins is assumed to use per-plugin-instance data-structures when reloading their
 configs and only a few of them that wish to optimize performance or deal with the complexities
-of using a per-plugin DSO "global" data-structures would use pluging configuration reload
+of using a per-plugin DSO "global" data-structures would use plugin configuration reload
 notifications like :func:`TSRemapPreConfigReload` and :func:`TSRemapPostConfigReload`.
 
 Instead of trying to foresee the needs or the expectations of each use-case, a more "open-ended"
 and straight-forward design was chosen for the configuration reload notifications.
-The notifications are broadcasted to all loaded plugins at the moments before and after 
+The notifications are broadcast to all loaded plugins at the moments before and after 
 the reload attempt, regardless of whether a plugin is part of the new configuration or not.
 
 :func:`TSRemapPreConfigReload` is called *before* the parsing of a new remap configuration starts
@@ -116,13 +116,13 @@ invoked by current and all previous still used configurations. This is an option
 
 :func:`TSRemapPostConfigReload` is called to indicate the end of the the new remap configuration
 load. It is called on the newly and previously loaded plugins, invoked by the new, current and
-previous still used configurations. It also indicates wheather the configuration reload was successful
+previous still used configurations. It also indicates whether the configuration reload was successful
 by passing :macro:`TSREMAP_CONFIG_RELOAD_FAILURE` in case of failure and to notify the plugins if they
 are going to be part of the new configuration by passing :macro:`TSREMAP_CONFIG_RELOAD_SUCCESS_PLUGIN_USED`
 or :macro:`TSREMAP_CONFIG_RELOAD_SUCCESS_PLUGIN_UNUSED`. This is an optional entry point.
 
 These calls are called per *plugin*, not per invocation of the plugin in :file:`remap.config`
-and only will be called if the plugin was instantianted by at least one configuration loaded
+and only will be called if the plugin was instantiated by at least one configuration loaded
 after the traffic server started and at least one configuration using it is still loaded.
 
 :func:`TSRemapPreConfigReload` will be called serially for all loaded plugins