olegk wrote: > > I think so, but I just do not see a point. Why not just setting a higher > connections per host number? TSCM does not pre-allocate connections, so > the pool will never grow, unless really needed. >
I guess the difference is ThreadPoolExecutor sets a TTL on Thread instances so in addition to being able to scale up, it can scale back down. If, for instance, there is a burst in requests then a drop, a large number of objects are not left in the pool. I guess this question is mostly academic since I don't really have much of a use case behind what I'm asking for. I originally would have had the "max concurrent request count" be a mutable property on my AsyncHTTPBuilder class rather than a final value set in a constructor. But since TSCCM's pool size is not dynamic, it means mine can't be either unless I create a new one each time the value is changed -- which I don't want to do. But anyway, it is not really a problem. olegk wrote: > > I have not used retrotranslator myself so I cannot really tell. > > We held a poll on the minimal JRE level for HttpClient 4.0 about a year > ago, and if my memory does not fail me, not a single person voted in > favor of 1.4 compatibility: > If HC 4 is built with maven, it's easy to add in Retrotranslator via the plugin: http://mojo.codehaus.org/retrotranslator-maven-plugin/examples/project-translation.html But i suppose I don't have a real requirement for that either, I would have done it "just because" :) -- View this message in context: http://www.nabble.com/ThreadSafeClientConnManager-and-pool-size-tp21079444p21128914.html Sent from the HttpClient-User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
