trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mlib...@apache.org
Subject [6/6] trafficserver git commit: Fix formatting to remove (failed) bold and italics
Date Mon, 08 Jun 2015 22:46:14 GMT
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 <mlibbey@apache.org>
Authored: Tue Apr 7 10:07:01 2015 -0700
Committer: Miles Libbey <mlibbey@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``.


Mime
View raw message