On Fri, 2015-04-24 at 14:18 +0000, Mark A. Claassen wrote:
> 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?
> 

If you get an I/O error while executing a request via a proxy it is most
likely due to transport to proxy. All other type of errors would be
communicated as HTTP messages. I _guess_ it should be fairly safe to
black-list proxy on any sort of IOException (except for SSL exceptions).

Oleg

> 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]
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to