hc-dev mailing list archives

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

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

Martin Meinhold commented on HTTPCLIENT-1310:

Thanks for your feedback, it is very appreciated.

"Did you test if this patch improves the performance of the cache in the case when the remote
server is down?"

The change can reduce the number of requests send to the remote server significantly. Assuming
the remote server is down and the background validation is required, ATM every request will
trigger the background validation. In our scenario we want performance over consistency, thus
we are more interested in limiting the number of requests (so lower the resource consumption)
with the drawback on not being up-to-date when the server is back. And yes, I've tested successfully
the patch.

"From the client point of view, as re-validation is done in the background, I guess it should
not make any difference."


"Why do you want to do this?"

We use the HttpClient as a transparent cache which stores documents from remote servers. Thus
we can access these documents very frequently without creating requests to the remote server.
Also the background validation is very handy in that situation as it avoids blocking a thread
while waiting on the remote server response.

As soon as the remote server goes down or returns a 5xx status code, every request will trigger
a network request to the remote server (which is of course the job of the HttpClient). As
described above, it is acceptable for us to work with a stale document and try the background
validation from time to time (e.g. once a minute or every 30 seconds). But the current implementation
doesn't allow to change the frequency when the background validation is run.

I understand that as a client, I can check for the existance of the Warning header. But IMHO
the value of the Warning ('110 localhost "Response is stale"') is not very machine readable
and looks too fragile to me to build my error handling on top of it. And even if I know that
I want to avoid the next background validation - how can I do that? Is there an easy way to
retrieve the cached document from the HttpClient without triggering a background validation?

The patch would make the information that the last x background validation requests have failed
more explicit. By extending the ExponentialBackOffSchedulingStrategy consuming clients can
even implement their own algorithm. While testing this again today I discovered that due to
AsynchronousRevalidationRequest being package protected it may be handy to extract some code
in an abstract class ...

Again, please feel free to post any feedback, concerns and comments.
> 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
> 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

View raw message