How do I determine the failure type? If the connection can't be established, then it can be considered a proxy failure, but there are other possible errors that would not involve the proxy. If I just get a IOException back, how can I be sure of which type of failure it was? Also, is this where I would receive the proxy authentication challenge? If so, wouldn't it be better to establish the credentials on a separate connection so that the thread making the request can be oblivious to these details?
Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:[email protected] Voice: (574)232-3784 Fax: (574)232-4014 -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: Friday, April 24, 2015 9:50 AM To: HttpClient User Discussion Subject: Re: Proxy Failover On Fri, 2015-04-24 at 13:08 +0000, Mark A. Claassen wrote: > Thank you. I did see this, but saw that is was never finished. > > I looked into the RetryHandler first, but wasn't sure if that was > where to put it. It seemed the RetryHandler stuff was not intended to > work on non-idempotent operations. That is why I tried to do this in > the RoutePlanner, since it would clear that no request entities had > yet been sent. (Eventually, I will want to send POST requests through > the proxy.) > It will not be very elegant but one probably could have RetryHandler and RoutePlanner share state through HttpContext and make RetryHandler 'black-list' proxies upon failure instead of RetryHandler probing good proxies. Oleg > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:[email protected] > Voice: (574)232-3784 > Fax: (574)232-4014 > > > -----Original Message----- > From: Oleg Kalnichevski [mailto:[email protected]] > Sent: Friday, April 24, 2015 6:39 AM > To: HttpClient User Discussion > Subject: Re: Proxy Failover > > On Thu, 2015-04-23 at 16:45 +0000, Mark A. Claassen wrote: > > I found some information on proxy failover and HttpClient, but not much. I > > was wondering, though, if my approach is OK. I realize there are > > inefficiencies, but before I go there, I want to know if I am even on the > > right track. > > > > I extended DefautRoutePlanner and implemented the determineProxy method. > > In that method I get the list of potential proxies and then test them. > > I return the first one in the list that works. (Also, when I find > > one that works, I remember it so I don't need to test it again.) > > > > In my constructor for my route planner, I create a separate HttpClient > > instance that just uses the DefaultRoutePlanner, which returns NULL for > > determineProxy(). > > > > Has anyone done anything like this? > > > > Thanks, > > Mark > > > > > > > > private boolean testProxy(URI targetURI, Proxy proxy) { > > boolean rval; > > if (proxy.type() != Proxy.Type.DIRECT) { > > InetSocketAddress address = (InetSocketAddress) > > proxy.address(); > > HttpHost host = new > > HttpHost(address.getHostName(), > > address.getPort(), ApacheNetworkImpl.SCHEME_HTTP); > > > > try { > > URI uri = new URI(host.toURI()); > > RequestBuilder rb = > > RequestBuilder.get(uri); > > HttpUriRequest request = rb.build(); > > try { > > HttpResponse resp = > > testClient.execute(request); > > rval = true; > > } > > catch (IOException ex) { > > rval = false; > > connectFailed(targetURI, > > address, ex); > > } > > finally { > > request.abort(); > > } > > } > > catch (URISyntaxException ex) { > > rval = false; > > } > > } > > else > > rval = true; > > return rval; > > } > > > > Mark, > > There is a JIRA for similar feature request > > https://issues.apache.org/jira/browse/HTTPCLIENT-1176 > > It should be possible to come with a more efficient solution by using a > custom HttpRequestRetryHandler in additional to a custom RoutePlanner. > > Hope this helps > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
