On Tue, 2016-01-05 at 07:30 -0500, Sam Perman wrote:
> If the url changes from one request to the next without a special client, 
> wouldn't the responses be two separate cache entries?
> 

Why is that bad? 

Oleg 

> sam
> 
> > On Jan 5, 2016, at 7:00 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> > 
> >> On Tue, 2016-01-05 at 06:28 -0500, Sam Perman wrote:
> >> Maybe there is another way to implement what I'm trying to do? In my case, 
> >> if the backend request fails, I want to retry the request against a 
> >> different url, but still cache the response.
> > 
> > Why do you need a special client for that?
> > 
> > Oleg
> > 
> >> thanks
> >> Sam
> >> 
> >>>> On Jan 5, 2016, at 4:58 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> >>>> 
> >>>> On Mon, 2016-01-04 at 17:21 -0500, Sam Perman wrote:
> >>>> Hello
> >>>> 
> >>>> I'm using the CachingHttpClient in a way that is deprecated in 4.5 and am
> >>>> trying to figure out the right non-deprecated way to do this.
> >>>> 
> >>>> In my cause, I have a custom implementation of HttpClient that will do 
> >>>> some
> >>>> request rewriting and retrying if it sees certain error conditions.
> >>>> 
> >>>> This is what the old deprecated code looks like:
> >>>> 
> >>>>       CacheConfig config = buildCacheConfig();
> >>>>       HttpClient myBackendClient = new CustomHttpClient();
> >>>>       CachingHttpClient cachingHttpClient = new
> >>>> CachingHttpClient(myBackendClient, config);
> >>>> 
> >>>> It looks like the recommended way to build caching http clients in 4.5 is
> >>>> to use the CachingHttpClientBuilder, but I see no way to provide my own
> >>>> implementation of HttpClient for use as the backend. Is this possible to 
> >>>> do
> >>>> in a non deprecated way?
> >>> 
> >>> Sam,
> >>> You can't. The problem is that caching logic needs to be inserted at a
> >>> particular point in the protocol processing chain in order to work
> >>> correctly in all cases. The approach of adding a caching layer as a
> >>> decorator for an arbitrary HttpClient instance turned out to be not good
> >>> enough.
> >>> 
> >>> Oleg
> >>> 
> >>> 
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> >>> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> >> 
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> >> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Reply via email to