You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@trafficserver.apache.org by ml...@apache.org on 2015/06/09 00:46:14 UTC
[6/6] trafficserver git commit: Fix formatting to remove (failed)
bold and italics
Fix formatting to remove (failed) bold and italics
Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/afdfb419
Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/afdfb419
Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/afdfb419
Branch: refs/heads/master
Commit: afdfb4195a6e1acd4e2766af06966f15c1b8743b
Parents: 2198745
Author: Miles Libbey <ml...@apache.org>
Authored: Tue Apr 7 10:07:01 2015 -0700
Committer: Miles Libbey <ml...@apache.org>
Committed: Mon Jun 8 15:44:47 2015 -0700
----------------------------------------------------------------------
doc/admin/faqs.en.rst | 2 +-
doc/arch/cache/cache-arch.en.rst | 2 +-
.../configuration/congestion.config.en.rst | 36 ++---
doc/reference/configuration/icp.config.en.rst | 16 +--
.../getting-started/naming-conventions.en.rst | 4 +-
doc/sdk/new-protocol-plugins.en.rst | 138 +++++++++----------
6 files changed, 99 insertions(+), 99 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/admin/faqs.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/faqs.en.rst b/doc/admin/faqs.en.rst
index d6dd259..a3a5aaa 100644
--- a/doc/admin/faqs.en.rst
+++ b/doc/admin/faqs.en.rst
@@ -377,7 +377,7 @@ Traffic Line commands do not execute under the following conditions:
.. XXX: this is wrong
You should always start and stop Traffic Server with the
- :program:`trafficserver start`` and :program:`trafficserver stop` commands to ensure
+ :program:`trafficserver start` and :program:`trafficserver stop` commands to ensure
that all the processes start and stop correctly. For more information,
refer to :ref:`getting-started`.
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/arch/cache/cache-arch.en.rst
----------------------------------------------------------------------
diff --git a/doc/arch/cache/cache-arch.en.rst b/doc/arch/cache/cache-arch.en.rst
index fecd0fb..b870a88 100644
--- a/doc/arch/cache/cache-arch.en.rst
+++ b/doc/arch/cache/cache-arch.en.rst
@@ -535,7 +535,7 @@ extraneous bytes.
The computation of the approximate size of the fragment is defined as::
- ( *size* + 1 ) * 2 ^ ( ``CACHE_BLOCK_SHIFT`` + 3 * *big* )
+ ( *size* + 1 ) * 2 ^ ( CACHE_BLOCK_SHIFT + 3 * *big* )
Where ``CACHE_BLOCK_SHIFT`` is the bit width of the size of a basic cache
block (9, corresponding to a sector size of 512). Therefore the value with
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/reference/configuration/congestion.config.en.rst
----------------------------------------------------------------------
diff --git a/doc/reference/configuration/congestion.config.en.rst b/doc/reference/configuration/congestion.config.en.rst
index 26b3d88..143c46f 100644
--- a/doc/reference/configuration/congestion.config.en.rst
+++ b/doc/reference/configuration/congestion.config.en.rst
@@ -55,16 +55,16 @@ file. Traffic Server recognizes three space-delimited tags::
The following list shows possible primary destinations with allowed
values.
-*``dest_domain``* {#dest_domain}
+``dest_domain``
A requested domain name.
-*``dest_host``* {#dest_host}
+``dest_host``
A requested hostname.
-*``dest_ip``* {#dest_ip}
+``dest_ip``
A requested IP address.
-*``url_regex``* {#url_regex}
+``url_regex``
A regular expression (regex) to be found in a URL.
The secondary specifiers are optional in the congestion.config file. The
@@ -72,72 +72,72 @@ following list shows possible secondary specifiers with allowed values.
You can use more than one secondary specifier in a rule; however, you
cannot repeat a secondary specifier.
-*``port``* {#port}
+``port``
A requested URL port or range of ports.
-*``prefix``* {#prefix}
+``prefix``
A prefix in the path part of a URL.
The following list shows the possible tags and their allowed values.
-*``max_connection_failures``* {#max_connection_failures}
+``max_connection_failures``
Default: ``5``
The maximum number of connection failures allowed within the fail
window described below before Traffic Server marks the origin server
as congested.
-*``fail_window``* {#fail_window}
+``fail_window``
Default: ``120`` seconds.
The time period during which the maximum number of connection
failures can occur before Traffic Server marks the origin server as
congested.
-*``proxy_retry_interval``* {#proxy_retry_interval}
+``proxy_retry_interval``
Default: ``10`` seconds.
The number of seconds that Traffic Server waits before contacting a
congested origin server again.
-*``client_wait_interval``* {#client_wait_interval}
+``client_wait_interval``
Default: ``300`` seconds.
The number of seconds that the client is advised to wait before
retrying the congested origin server.
-*``wait_interval_alpha``* {#wait_interval_alpha}
+``wait_interval_alpha``
Default: ``30`` seconds
The upper limit for a random number that is added to the wait
interval.
-*``live_os_conn_timeout``* {#live_os_conn_timeout}
+``live_os_conn_timeout``
Default: ``60`` seconds.
The connection timeout to the live (uncongested) origin server. If a
client stops a request before the timeout occurs, then Traffic
Server does not record a connection failure.
-*``live_os_conn_retries``* {#live_os_conn_retries}
+``live_os_conn_retries``
Default: ``2``
The maximum number of retries allowed to the live (uncongested)
origin server.
-*``dead_os_conn_timeout``* {#dead_os_conn_timeout}
+``dead_os_conn_timeout``
Default: ``15`` seconds.
The connection timeout to the congested origin server.
-*``dead_os_conn_retries``* {#dead_os_conn_retries}
+``dead_os_conn_retries``
Default: ``1``
The maximum number of retries allowed to the congested origin
server.
-*``max_connection``* {#max_connection}
+``max_connection``
Default: ``-1``
The maximum number of connections allowed from Traffic Server to the
origin server.
-*``error_page``* {#error_page}
+``error_page``
Default: ``"congestion#retryAfter"``
The error page sent to the client when a server is congested. You
must enclose the value in quotes;
-*:file:`congestion.config`* {#congestion_scheme}
+``congestion_scheme``
Default: ``"per_ip"``
Specifies if Traffic Server applies the rule on a per-host
(``"per_host"``) or per-IP basis (``"per_ip"``). You must enclose
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/reference/configuration/icp.config.en.rst
----------------------------------------------------------------------
diff --git a/doc/reference/configuration/icp.config.en.rst b/doc/reference/configuration/icp.config.en.rst
index 94133ba..4757f37 100644
--- a/doc/reference/configuration/icp.config.en.rst
+++ b/doc/reference/configuration/icp.config.en.rst
@@ -41,42 +41,42 @@ information for a single ICP peer in the following format::
Each field is described in the following list.
-*``host``* {#host}
+``host``
The hostname of the ICP peer.
This field is optional; if you do not specify the hostname of the
ICP peer, you must specify the IP address.
-*``host_IP``* {#host_IP}
+``host_IP``
The IP address of the ICP peer.
This field is optional; if you do not specify the IP address of the
ICP peer, you must specify the hostname.
-*``ctype``* {#ctype}
+``ctype``
Use the following options:
- 1 to indicate an ICP parent cache
- 2 to indicate an ICP sibling cache
-*``proxy_port``* {#proxy_port}
+``proxy_port``
The port number of the TCP port used by the ICP peer for proxy
communication.
-*``icp_port``* {#icp_port}
+``icp_port``
The port number of the UDP port used by the ICP peer for ICP
communication.
-*``MC_on``* {#mc_on}
+``MC_on``
Enable or disable MultiCast:
- 0 if multicast is disabled
- 1 if multicast is enabled
-*``MC_ip``* {#mc_ip}
+``MC_ip``
The MultiCast IP address.
-*``MC_ttl``* {#mc_ttl}
+``MC_ttl``
The multicast time to live. Use the following options:
- 1 if IP multicast datagrams will not be forwarded beyond a single
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/sdk/getting-started/naming-conventions.en.rst
----------------------------------------------------------------------
diff --git a/doc/sdk/getting-started/naming-conventions.en.rst b/doc/sdk/getting-started/naming-conventions.en.rst
index 45794a2..04a3aa6 100644
--- a/doc/sdk/getting-started/naming-conventions.en.rst
+++ b/doc/sdk/getting-started/naming-conventions.en.rst
@@ -25,14 +25,14 @@ The Traffic Server API adheres to the following naming conventions:
``TS_EVENT_NONE``,\ ``TSMutex``, and ``TSContCreate``
- Enumerated values are always written in all uppercase letters.
- **Examples**: *``TS_EVENT_NONE``* and *``TS_VC_CLOSE_ABORT``*
+ **Examples**: ``TS_EVENT_NONE`` and ``TS_VC_CLOSE_ABORT``
- Constant values are all uppercase; enumerated values can be seen as a
subset of constants. **Examples**: ``TS_URL_SCHEME_FILE`` and
``TS_MIME_FIELD_ACCEPT``
- The names of defined types are mixed-case. **Examples**:
- *``TSHttpSsn``* and *``TSHttpTxn``*
+ ``TSHttpSsn`` and ``TSHttpTxn``
- Function names are mixed-case. **Examples**: ``TSUrlCreate`` and
``TSContDestroy``
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/sdk/new-protocol-plugins.en.rst
----------------------------------------------------------------------
diff --git a/doc/sdk/new-protocol-plugins.en.rst b/doc/sdk/new-protocol-plugins.en.rst
index c0f7fc5..f7e281b 100644
--- a/doc/sdk/new-protocol-plugins.en.rst
+++ b/doc/sdk/new-protocol-plugins.en.rst
@@ -226,29 +226,29 @@ The steps below describe the flow of execution illustrated in :ref:`"How
Transaction State Machines are Implemented in the Protocol
Plugin" <ImplementTransStMachine>`.
-1. The handler for the TSM, (called **``main_handler``** in the Protocol
+1. The handler for the TSM, (called ``main_handler`` in the Protocol
plugin) receives events from the TSM.
-2. **``main_handler``** examines the state of the transaction-in
+2. ``main_handler`` examines the state of the transaction-in
particular, it examines the current handler.
-3. **``main_handler``** calls the **``current_handler``** (which is one
+3. ``main_handler`` calls the ``current_handler`` (which is one
of the state handler functions), and then passes the current event to
- **``current_handler``**. In :ref:`the image
+ ``current_handler``. In :ref:`the image
below <ImplementTransStMachine>` below, the current handler is
- called **``state2_handler``**.
+ called ``state2_handler``.
-4. The **``current_handler``** handles the event and updates the data.
+4. The ``current_handler`` handles the event and updates the data.
In :ref:`the image below <ImplementTransStMachine>` below, the state is
- changed from **``state2``** to **``state3``** (and the current
- handler is changed from **``state2_handler``** to
- **``state3_handler``**). The next time **``main_handler``** receives
- an event, it will be processed by **``state3_handler``**.
+ changed from ``state2`` to ``state3`` (and the current
+ handler is changed from ``state2_handler`` to
+ ``state3_handler``). The next time ``main_handler`` receives
+ an event, it will be processed by ``state3_handler``.
-5. **``state2_handler``** arranges the next callback of the TSM.
+5. ``state2_handler`` arranges the next callback of the TSM.
Typically, it gives Traffic Server additional work to do (such as
writing a file to cache) so that it can progress to the next state.
- The TSM (**``main_handler``**) then waits for the next event to
+ The TSM (``main_handler``) then waits for the next event to
arrive from Traffic Server.
**How Transaction State Machines are Implemented in the Protocol
@@ -280,93 +280,93 @@ typical transaction.
two: a client accept port and a server port) and runs an
initialization routine, ``init``.
-2. The **``init``** function (in ``Protocol.c``) creates the plugin's
- log file using **``TSTextLogObjectCreate``**.
+2. The ``init`` function (in ``Protocol.c``) creates the plugin's
+ log file using ``TSTextLogObjectCreate``.
-3. The **``init``** function creates the accept state machine using
- **``AcceptCreate``**. The code for **``AcceptCreate``** is in the
+3. The ``init`` function creates the accept state machine using
+ ``AcceptCreate``. The code for ``AcceptCreate`` is in the
``Accept.c`` file.
4. The accept state machine, like the transaction state machine, keeps
track of its state with a data structure. This data structure,
- **``Accept``**, is defined in the ``Accept.h`` file. State data in
- **``AcceptCreate``** is associated with the new accept state machine
- via **``TSContDataSet``**.
+ ``Accept``, is defined in the ``Accept.h`` file. State data in
+ ``AcceptCreate`` is associated with the new accept state machine
+ via ``TSContDataSet``.
-5. The **``init``** function arranges the callback of the accept state
+5. The ``init`` function arranges the callback of the accept state
machine when there is a network connection by using
- **``TSNetAccept``**.
+ ``TSNetAccept``.
-6. The handler for the accept state machine is **``accept_event``** in
+6. The handler for the accept state machine is ``accept_event`` in
the ``Accept.c`` file. When Traffic Server's Net Processor sends
- **``TS_EVENT_NET_ACCEPT``** to the accept state machine,
- **``accept_event``** creates a transaction state machine
- (**``txn_sm``**) by calling **``TxnSMCreate``**. Notice that
- **``accept_event``** creates a mutex for the transaction state
+ ``TS_EVENT_NET_ACCEPT`` to the accept state machine,
+ ``accept_event`` creates a transaction state machine
+ (``txn_sm``) by calling ``TxnSMCreate``. Notice that
+ ``accept_event`` creates a mutex for the transaction state
machine, since each transaction state machine has its own mutex.
-7. The **``TxnSMCreate``** function is in the ``TxnSM.c`` file. The
+7. The ``TxnSMCreate`` function is in the ``TxnSM.c`` file. The
first thing it does is initialize the transaction's data, which is
of type ``TxnSM`` (as defined in ``TxnSM.h``). Notice that the
- current handler (**``q_current_handler``**) is set to
- **``state_start``**.
+ current handler (``q_current_handler``) is set to
+ ``state_start``.
-8. **``TxnSMCreate``** then creates a transaction state machine using
- **``TSContCreate``**. The handler for the transaction state machine
- is **``main_handler``**, which is in the ``TxnSM.c`` file.
+8. ``TxnSMCreate`` then creates a transaction state machine using
+ ``TSContCreate``. The handler for the transaction state machine
+ is ``main_handler``, which is in the ``TxnSM.c`` file.
-9. When **``accept_event``** receives **``TS_EVENT_NET_ACCEPT``**, it
+9. When ``accept_event`` receives ``TS_EVENT_NET_ACCEPT``, it
calls the transaction state machine (
- **``TSContCall (txn_sm, 0, NULL);``** ). The event passed to
- **``main_handler``** is ``0`` (**``TS_EVENT_NONE``**).
+ ``TSContCall (txn_sm, 0, NULL);`` ). The event passed to
+ ``main_handler`` is ``0`` (``TS_EVENT_NONE``).
-10. The first thing **``main_handler``** does is examine the current
- **``txn_sm``** state by calling **``TSContDataGet``**. The state is
- **``state_start``**.
+10. The first thing ``main_handler`` does is examine the current
+ ``txn_sm`` state by calling ``TSContDataGet``. The state is
+ ``state_start``.
-11. **``main_handler``** then invokes the handler for
- **``state_start``** by using the function pointer
- **``TxnSMHandler``** (as defined in ``TxnSM.h``).
+11. ``main_handler`` then invokes the handler for
+ ``state_start`` by using the function pointer
+ ``TxnSMHandler`` (as defined in ``TxnSM.h``).
-12. The **``state_start``** handler function (in the ``TxnSM.c`` file)
+12. The ``state_start`` handler function (in the ``TxnSM.c`` file)
is handed an event (at this stage, the event is
- **``TS_EVENT_NET_ACCEPT``**) and a client vconnection.
- **``state_start``** checks to see if this client vconnection is
- closed; if it is not, then **``state_start``** attempts to read data
- from the client vconnection into an **``TSIOBuffer``**
- (**``state_start``** is handling the event it receives).
-
-13. **``state_start``** changes the current handler to
- **``state_interface_with_client``** (that is, it updates the state
+ ``TS_EVENT_NET_ACCEPT``) and a client vconnection.
+ ``state_start`` checks to see if this client vconnection is
+ closed; if it is not, then ``state_start`` attempts to read data
+ from the client vconnection into an ``TSIOBuffer``
+ (``state_start`` is handling the event it receives).
+
+13. ``state_start`` changes the current handler to
+ ``state_interface_with_client`` (that is, it updates the state
of the transaction to the next state).
-14. **``state_start``** initiates a read of the client vconnection
+14. ``state_start`` initiates a read of the client vconnection
(arranges for Traffic Server to send
- **``TS_EVENT_VCONN_READ_READY``** events to the TSM) by calling
- **``TSVConnRead``**.
+ ``TS_EVENT_VCONN_READ_READY`` events to the TSM) by calling
+ ``TSVConnRead``.
-15. **``state_interface_with_client``** is activated by the next event
+15. ``state_interface_with_client`` is activated by the next event
from Traffic Server. It checks for errors and examines the read VIO
- for the read operation initiated by **``TSVConnRead``**.
+ for the read operation initiated by ``TSVConnRead``.
-16. If the read VIO is the **``client_read_VIO``** (which we are
+16. If the read VIO is the ``client_read_VIO`` (which we are
expecting at this stage in the transaction), then
- **``state_interface_with_client``** updates the state to
- **``state_read_request_from_client``** .
+ ``state_interface_with_client`` updates the state to
+ ``state_read_request_from_client`` .
-17. **``state_read_request_from_client``** handles actual
- **``TS_EVENT_READ_READY``** events and reads the client request.
+17. ``state_read_request_from_client`` handles actual
+ ``TS_EVENT_READ_READY`` events and reads the client request.
-18. **``state_read_request_from_client``** parses the client request.
+18. ``state_read_request_from_client`` parses the client request.
-19. **``state_read_request_from_client``** updates the current state to
- the next state, **``state_handle_cache_lookup``** .
+19. ``state_read_request_from_client`` updates the current state to
+ the next state, ``state_handle_cache_lookup`` .
-20. **``state_read_request_from_client``** arranges for Traffic Server
+20. ``state_read_request_from_client`` arranges for Traffic Server
to call back the TSM with the next set of events (initiating the
- cache lookup) by calling **``TSCacheRead``**.
+ cache lookup) by calling ``TSCacheRead``.
-21. When the **``TSCacheRead``** sends the TSM either
- **``TS_EVENT_OPEN_READ``** (a cache hit) or
- **``TS_EVENT_OPEN_READ_FAILED``** (a cache miss),
- **``main_handler``** calls **``state_handle_cache_lookup``**.
+21. When the ``TSCacheRead`` sends the TSM either
+ ``TS_EVENT_OPEN_READ`` (a cache hit) or
+ ``TS_EVENT_OPEN_READ_FAILED`` (a cache miss),
+ ``main_handler`` calls ``state_handle_cache_lookup``.