Oleg, OK, I did this. I thought that, given that using DefaultHttpClient was deprecated in favor of using CloseableHttpClient, the API had been changed to a "build immutable objects for better performance" model, with the fluent API as a side-effect.
Is the API still totally or partially mutable then, with a new requirement to maintain related object instances instead of obtaining them from the HTTP client instance? I've not noticed any significant reduction in lines of code, and it took a lot of time and searching (despite the hints and tutorial) to rewrite code such that there were no "deprecated" warnings. Thanks, Christopher On 5 November 2013 10:57, Oleg Kalnichevski <[email protected]> wrote: > On Mon, 2013-11-04 at 20:35 +0100, Christopher BROWN wrote: > > Hello, > > > > I'm upgrading HTTP Client from 4.2 to 4.3.1, and one issue I'm > encountering > > is that I can't seem to find how to change some properties at runtime, > like > > this: > > > > final ClientConnectionManager cm = _http.getConnectionManager(); > > if (cm instanceof PoolingHttpClientConnectionManager) > > { > > cm.setDefaultMaxPerRoute(networkPoolSize); > > cm.setMaxTotal(networkPoolSize); > > } > > > > Would I be correct in assuming that I have to drop my instance of > > CloseableHttpClient (shutdown and so on, hopefully without disrupting > > service) and replace it with a new instance? > > > > -- > > Christopher > > Christopher > > Discarding perfectly valid CloseableHttpClient should not be necessary. > Why do not you simply keep a reference to the connection manager in > order to apply different connection limits? > > --- > PoolingHttpClientConnectionManager connman = new > PoolingHttpClientConnectionManager(); > CloseableHttpClient client = HttpClients.custom() > .setConnectionManager(connman).build(); > connman.setMaxTotal(networkPoolSize); > --- > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
