Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Tue, 19 Feb 2013 23:09:13 +0000 (UTC)
From: "Jon Moore (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12629837.1359519430140.307405.1361315353389@arcas>
In-Reply-To: <JIRA.12629837.1359519430140@arcas>
References: <JIRA.12629837.1359519430140@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1310) Allow background validation to
 optionally back off after a number of failed requests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581726#comment-13581726 ] 

Jon Moore commented on HTTPCLIENT-1310:
---------------------------------------

I think this is reasonable functionality. I haven't reviewed the patch itself, but assuming code quality is good then I don't see any reason why we couldn't support this, especially as opt-in behavior.

A few of side HTTP notes, really unrelated to the patch or the functionality itself:
* Warning headers are pretty easily parseable; you just need the leading, non-whitespace 3-digit warning code (110). A 110 is always a stale response. The rest is just for the benefit of human readers. :)
* That said, you can, also tell if a response is stale by comparing its Age header with the max-age (or s-max-age) in the Cache Control header, or by comparing the Date header to the Expires header.
* Finally, one workaround without adding this feature would be to issue a request with 'Cache-Control: max-stale=31536000, only-if-cached'. This will give you a (possibly stale) cache entry if one exists, and an immediate 504 response if it doesn't. Then your application could proceed accordingly. [I think this is even better if you issue a HEAD for the cache test, although I can't remember if the cache module will answer a HEAD request with a cache entry from a GET].

All that said, it's far easier to build a backoff strategy into the background validator. :)

                
> Allow background validation to optionally back off after a number of failed requests
> ------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1310
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1310
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: Cache
>            Reporter: Martin Meinhold
>         Attachments: 0001-HTTPCLIENT-1310-Allow-clients-to-change-the-used-sch.patch
>
>
> We are successfully using the background validation to asynchronously update cache entries while returning a stale document (stale-while-revalidate cache control header). Also in case an error has happened, the stale document is used (stale-if-error cache control header). Works perfectly. Guys - great work you made this happen.
> Now the tricky part: as soon there is an issue like e.g. the remote server is down, the stale-if-error header prevent the cache from being updated (which of course is the intention of that header). But this also means, that code using the HttpClient has no way to discover that there was an issue. So every following request will get that stale document but also trigger a background revalidation.
> As an improvement it should be possible that the background validation backs off after a certain amount of failed requests. This should be optional and not the default.
> I want to contribute some code we already have working on a 4.2 branch. The central idea is to vary the scheduling strategy the AsynchronousValidation uses to estimate _when_ the background validation of a certain request should happen. Of course, the default would be immediately. 
> In fact this would move code currently submitting tasks to the executor from the AsynchronousValidation into a separate class. Thus the AsynchronousValidation would become kind of a director role by simply enqueuing next requests and keeping track which of them failed and which were successful. A strategy could - based on the failure count - execute them immediately or later. Again, to clarify: the default behaviour would be to execute every incoming background validation request immediately regardless of the error count.
> What do you think?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org