hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex, Joseph (Contractor)" <Joseph.A...@searshc.com>
Subject RE: Connection Pool and DNS Resolution timeout
Date Thu, 06 Mar 2014 13:12:43 GMT
Thanks Oleg. This will help for new connections getting created to pick up the new IP. But,
how can we manage connections that were established and exist in the pool when the DC switch
is made? . I saw that connectionmanger shutdown() will close all connections, but that would
also make it and the HttpClients unusable unless they are initialized again. Is there any
way to just flush all existing connections?


-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org] 
Sent: Tuesday, March 04, 2014 8:14 AM
To: HttpClient User Discussion
Subject: Re: Connection Pool and DNS Resolution timeout

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



To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

This message, including any attachments, is the property of Sears Holdings Corporation and/or
one of its subsidiaries. It is confidential and may contain proprietary or legally privileged
information. If you are not the intended recipient, please delete it without reading the contents.
Thank you.
View raw message