|Re: [jetty-users] HttpClient support for multi-homed hosts|
On 8/21/2015 2:00 AM, Simone Bordet wrote:
This change has been made only very recently, and it's not out to a release yet. So we can change SocketAddressResolver.resolve(...) to take a Promise<List<SocketAddress>>.
Good, my request is timely.
A couple of the implementations appear to pull objects, such as the HttpDestination, out of the Map<String, Object> and call modifying operations on them.For another, implementations of HttpClientTransport could assume that there would be only one attempt to call HttpClientTransport.connect(SocketAddress, Map<String, Object>) per destination. For example, HttpClientTransportOverHTTP2 aborts the HttpDestination on a connection failure.No, the connect() operation only notifies a callback.
InetSocketAddress has three attributes, but there is no way to construct an object through the public API specifying all three values. If the code uses the InetSocketAddress(InetAddress, int) constructor, then were any of the HttpClientTransport implementations to call the InetSocketAddress.getHostName() accessor (to log or generate an error message) that would cause a reverse-IP resolution.There's also the minor issue that it isn't possible to get a collection of InetSocketAddress for a multi-homed hostname where each InetSocketAddress knows its hostname.This I don't follow. Can you expand ?
Back to the top