[
https://issues.apache.org/jira/browse/HTTPCLIENT-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Meinhold updated HTTPCLIENT-1310:
----------------------------------------
Attachment: 0001-HTTPCLIENT-1310-Allow-clients-to-change-the-used-sch.patch
Let me know if there are any changes / documentation required.
> 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: [email protected]
For additional commands, e-mail: [email protected]
