On Mon, 2014-03-03 at 12:59 +0000, Alex, Joseph (Contractor) wrote: > Hi, > > We use HttpClient 3.1 and Httpcomponents 4.2.x in some of our apps with > MultiThreadedHttpConnectionManager and PoolingClientConnectionManager > respectively. Some of our server endpoints use a Global Name which can be > switched to point to different data centers at runtime, depending on which > one is active (with the other DC still being "alive"). Example > www.global.com<http://www.global.com> which could either point to > www.dc1.com<http://www.dc1.com> or www.dc2.com<http://www.dc2.com>. When this > switch was done, we noticed that the connections were not picking up the new > DC's IP and still routing to the old one. Assuming that the DNS resolution > timeouts (networkaddress.cache.ttl) is set to a low value in the JVM, would > the connection pool honor this value and reset the connections accordingly? . > If they don't, what options do we have of ensuring that the connections are > reset, and recreated with the new DNS resolution, without having to restart > the JVM? > > Thanks, > Joseph
Hi Joseph HttpClient of all versions are fully reliant on the standard DNS resolution mechanism provided by JRE. They also do not attempt to cache or re-use resolved addresses, so 'networkaddress.cache.ttl' parameter should have effect. Since HttpClient 4.2 though, one can plug in a custom DNS resolver implementation [1] to replace or enhance the standard resolution mechanism. Hope this helps Oleg [1] http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/apidocs/org/apache/http/conn/DnsResolver.html --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
