+1 for xposing CacheKeyGenerator On Tue, Jan 5, 2016 at 11:45 PM Sam Perman <s...@permans.com> wrote:
> Ok. Thanks for the quick response. I think I'll keep using the deprecated > APIs then. :) > > > On Jan 5, 2016, at 2:29 PM, Oleg Kalnichevski <ol...@apache.org> wrote: > > > >> On Tue, 2016-01-05 at 13:45 -0500, Sam Perman wrote: > >> That isn't exposed at this point, right? > > > > It is not. > > > > Oleg > > > >>> On Tue, Jan 5, 2016 at 10:04 AM, Oleg Kalnichevski <ol...@apache.org> > wrote: > >>> > >>>> On Tue, 2016-01-05 at 08:56 -0500, Sam Perman wrote: > >>>> If I can reuse cache entries creating during failover, it means I can > >>>> absorb failures without the cache hit rate suffering. > >>> > >>> Probably the best solution to the problem is actually using exposing > >>> CacheKeyGenerator through public APIs. > >>> > >>> Oleg > >>> > >>> > >>>>> On Tue, Jan 5, 2016 at 8:20 AM, Oleg Kalnichevski <ol...@apache.org> > >>>> wrote: > >>>> > >>>>>> 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 > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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 > >
