On Wed, 2016-01-06 at 13:18 +0000, Tamás Cservenák wrote: > +1 for xposing CacheKeyGenerator >
We happily accept PRs at GitHub Oleg > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
