[
https://issues.apache.org/jira/browse/HTTPCLIENT-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586141#comment-13586141
]
Jon Moore commented on HTTPCLIENT-1310:
---------------------------------------
@fx:
1. The failures here are quite different data that cached HTTP responses, so I
don't see a problem storing them somewhere else. I doubt this particular
information needs to be persisted, however; there wouldn't be much harm if,
after a restart, we "rediscovered" a remote host was down.
2. I don't think we want to apply this to synchronous revalidation, as there is
a client expectation in that case of, well, being synchronous. Introducing an
artificial delay or retrying with a backoff isn't transparent enough behavior,
in my opinion. I think it works fine for the asynchronous case because
stale-while-revalidate is already a 'best effort' feature without guaranteed
timing.
3. The exponential backoff has the benefit of eventually succeeding if the host
comes back up (before the allowed stale lifetime passes). I'd think we'd want a
similar recovery behavior to happen if we cut the host off; after some
"cooldown" period we'd re-enable the host and retry. However, that strikes me
as another SchedulingStrategy implementation more than anything else. I think
the exponential backoff is a well-tested networking technique that avoids
"thundering herds" once the host comes back awake.
> 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]
