Difference: ClientRetryStrategy (28 vs. 29)

Revision 292018-01-19 - DaveDykstra

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Frontier client retry strategy

Line: 21 to 21
  The frontier client error retry strategy distinguishes between five types of non-fatal errors:
  1. A cache max-age exceeded condition -- the server specified a maximum cache age in its response, and the received "Age" http header (inserted by the squid proxy) is greater than that. The server sets this maximum age near the end of its response when it is too late to put it in the http header, which happens when a condition to limit the max age is found after the http header has already been sent by the server. The http header is sent either when a buffer full of data is ready or when a "keepalive" has to be sent because the server has been waiting for more than 5 seconds for that client's request to the database. A condition that the server might notice at that point is either some kind of database error or an empty result. If the server doesn't set the maximum cache age but it is a protocol error (see below), then the client uses a default maximum cache age of 5 minutes (this is to support servlet versions older than 3.33).
Changed:
<
<
  1. A server error -- a proxy or server responded but there was either an http error code from the server where it knew it had a problem, or the proxy immediately determined a server problem and returned an error code indicating so. In other words, there was an http error code of either 404 or in the 500 series. The result will not be cached.
>
>
  1. A server error -- a proxy or server responded but there was either an http error code from the server where it knew it had a problem, or the proxy immediately determined a server problem and returned an error code indicating so. In other words, there was an http error code of either 404 or in the 500 series. The result will not be cached. Server errors can also be caused by a variety of problems with downloading the host certificate when the signing security feature is enabled, and that result may be cached.
 
  1. A connect error - the socket couldn't be connected, meaning that a proxy or direct-connect server is down. This can be connection timeout, connection refused, or network unreachable.
Changed:
<
<
  1. A protocol error - either the response http code was not 200 OK, the code was not 404 or in the 500 server-error series, the response couldn't be completely parsed as expected, or the server signaled at the end of its response that it encountered a late error and should not be cached for a long time (even though the http headers said it was OK and could be cached).
>
>
  1. A protocol error - either the response http code was not 200 OK (and the code was not 404 or in the 500 server-error series, covered above), the response couldn't be completely parsed as expected, or the server signaled at the end of its response that it encountered a late error and should not be cached for a long time (even though the http headers said it was OK and could be cached).
 
  1. All other types of errors, for example networking problems, read timeouts because of overloading or non-response from a server, etc.

These are the retry strategies:

Line: 45 to 45
 Frontier clients prior to version 2.8.2 (June 2011) are not documented on this page.

For frontier clients 2.8.9 (January 2014) through 2.8.14, these are the differences compared to 2.8.15 (February 2016) above:

Changed:
<
<
  • Different IP families in the same DNS name were not considered separate groups (in fact IPv6 was not supported at all before 2.8.14).
  • 404 was considered a protocol error, not a server error.
  • Connection refused and network unreachable were not considered connect errors, only connection timeout was.
  • There was a bug present since 2.8.6 that considered a whole proxy group as failed when the last one failed, even if previous ones hadn't failed. That could happen after load balancing within a proxy group.
  • There was a bug present since 2.8.9 where if a server did not send an Age header (because it was a fresh query) and the previous query on the same connection had an old enough Age, a max-age exceeded condition could be erroneously triggered; the Age from the previous query was applied to the one without an Age.

For frontier clients version 2.8.6 (April 2013) through 2.8.8, there are these differences compared to the 2.8.9 strategies above:

  • There was no concept of a max-age exceeded condition.
  • For a protocol error, the request would be immediately retried first with a soft retry (Cache-control: max-age=0) before the hard retry.
>
>
  1. Different IP families in the same DNS name were not considered separate groups (in fact IPv6 was not supported at all before 2.8.14).
  2. 404 was considered a protocol error, not a server error.
  3. Connection refused and network unreachable were not considered connect errors, only connection timeout was.
  4. There was a bug present since 2.8.6 that considered a whole proxy group as failed when the last one failed, even if previous ones hadn't failed. That could happen after load balancing within a proxy group.
  5. There was a bug present since 2.8.9 where if a server did not send an Age header (because it was a fresh query) and the previous query on the same connection had an old enough Age, a max-age exceeded condition could be erroneously triggered; the Age from the previous query was applied to the one without an Age.

For frontier clients version 2.8.7 (June 2013) and 2.8.8, there are these differences compared to the 2.8.9 strategies above:

  1. There was no concept of a max-age exceeded condition.
  2. For a protocol error, the request would be immediately retried first with a soft retry (Cache-control: max-age=0) before the hard retry.

For frontier client version 2.8.6 (April 2013) compared to the 2.8.7 strategies above:

  • There was no digital signature support so there were no server errors with downloading host certificates.
  For frontier client versions 2.8.2 through 2.8.5, these are the additional differences:
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback