trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mlib...@apache.org
Subject git commit: Another attempt to fix formating of thundering herd section.
Date Fri, 04 Oct 2013 23:19:54 GMT
Updated Branches:
  refs/heads/master fffb60ed3 -> ae7b3f942


Another attempt to fix formating of thundering herd section.


Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/ae7b3f94
Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/ae7b3f94
Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/ae7b3f94

Branch: refs/heads/master
Commit: ae7b3f94258ac708e7828c47b6832272ee68db96
Parents: fffb60e
Author: Miles Libbey <mlibbey@apache.org>
Authored: Fri Oct 4 16:19:49 2013 -0700
Committer: Miles Libbey <mlibbey@apache.org>
Committed: Fri Oct 4 16:19:49 2013 -0700

----------------------------------------------------------------------
 doc/admin/http-proxy-caching.en.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ae7b3f94/doc/admin/http-proxy-caching.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/http-proxy-caching.en.rst b/doc/admin/http-proxy-caching.en.rst
index b43720f..27f1369 100644
--- a/doc/admin/http-proxy-caching.en.rst
+++ b/doc/admin/http-proxy-caching.en.rst
@@ -784,7 +784,7 @@ Read While Writer
 -----------------
 When Traffic Server goes to fetch something from origin, and upon receiving the response,
any number of clients can be allowed to start serving the partially filled cache object once
background_fill_completed_threshold % of the object has been received. The difference is that
Squid allows this as soon as it goes to origin, whereas ATS can not do it until we get the
complete response header. The reason for this is that we make no distinction between cache
refresh, and cold cache, so we have no way to know if a response is going to be cacheable,
and therefore allow read-while-writer functionality.
 
-The configurations necessary to enable this in ATS are:
+The configurations necessary to enable this in ATS are::
 
    CONFIG :ts:cv:`proxy.config.cache.enable_read_while_writer` ``INT 1``
    CONFIG :ts:cv:`proxy.config.http.background_fill_active_timeout` ``INT 0``
@@ -801,7 +801,7 @@ Once all this enabled, you have something that is very close, but not
quite the
 
 Fuzzy Revalidation
 ------------------
-Traffic Server can be set to attempt to revalidate an object before it becomes stale in cache.
:file:`records.config` contains the settings:
+Traffic Server can be set to attempt to revalidate an object before it becomes stale in cache.
:file:`records.config` contains the settings::
 
    CONFIG :ts:cv:`proxy.config.http.cache.fuzz.time` ``INT 240``
    CONFIG :ts:cv:`proxy.config.http.cache.fuzz.min_time` ``INT 0``
@@ -829,7 +829,7 @@ Similarly, this setting should be used in conjunction with Read While
Writer for
 
 Since ATS now supports setting these settings per-request or remap rule, you can configure
this to be suitable for your setup much more easily.
 
-The configurations are (with defaults):
+The configurations are (with defaults)::
 
    CONFIG :ts:cv:`proxy.config.http.cache.max_open_read_retries` ``INT -1``
    CONFIG :ts:cv:`proxy.config.http.cache.open_read_retry_time` ``INT 10``


Mime
View raw message