hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois-Xavier Bonnet (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1310) Allow background validation to optionally back off after a number of failed requests
Date Thu, 21 Feb 2013 12:00:16 GMT

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

Francois-Xavier Bonnet commented on HTTPCLIENT-1310:
----------------------------------------------------

Jon,
The code quality is good and the patch includes good unit tests, but before I commit anything
I would like to have your opinion on some points:
* this new feature introduces a failure cache (the default implementation is based on a ConcurrentMap).
Is it consistent to have separate caches for http responses and for failures? Wouldn't it
be better to store failure information in the existing cache with http responses?
* in the patched version, the backoff strategy is implemented by a class SchedulingStrategy
class that can be used only when doing asynchronous revalidation. For me it would make sense
to be able to apply this backoff strategy also when doing synchronous revalidation 
* if the goal is to avoid sending requests again and again when the backend server is down,
don't you think it would be more efficient to stop all requests to this host? It would look
like what Apache connectors do when a worker is considered in error state. Then this would
be a feature for HttpClient project that could be used even without cache.
Your opinion?


                
> 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


Mime
View raw message