On Wed, 2014-12-17 at 16:17 +0530, srihari na wrote:
> Again thanks for the response however we are expecting answer for another
> question:
> Can we get a confirmation that this issue is resolved in later versions or
> a probable solution can be designed for the described scenario?
> 

I can confirm the latter.

http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/xref/org/apache/http/impl/conn/HttpClientConnectionOperator.html#96

Oleg

> Thank you
> 
> On Wed, Dec 17, 2014 at 2:39 PM, Oleg Kalnichevski <[email protected]> wrote:
> >
> > On Wed, 2014-12-17 at 11:55 +0530, srihari na wrote:
> > > Thank You for the quick response. Can we get a confirmation that this
> > issue
> > > is resolved in later versions or a probable solution can be designed for
> > > the described scenario? The reason we ask is our product bundled
> > > v4.2.5(upgraded from 3.1) of the library in April 2013 and moving to
> > > 4.3/4.4 would mean a lot of API/design changes that can significantly
> > > impact the product stability. It is therefore desirable for us to move
> > to a
> > > stable version which is covered under under Long Term Suppor (LTS). Is
> > > there a plan to support 4.3/4.4 for longer term or can you let us know
> > the
> > > current outlook for ending support for those streams? Also we will be
> > > interested to know if any support will be provided on 4.2 stream on
> > buying
> > > support for annual fee.
> > >
> >
> > Apache HC is a non-commercial project. We do not have LTS releases. We
> > are able to maintain two concurrent branches only only: dev (unstable)
> > and ga (stable). Current stable branch is 4.3. 4.4 GA can be expected in
> > Q1 2015.
> >
> > Oleg
> >
> > > Thank you hoping for a quick response.
> > >
> > > On Mon, Dec 15, 2014 at 7:48 PM, Oleg Kalnichevski <[email protected]>
> > wrote:
> > > >
> > > > On Mon, 2014-12-15 at 17:46 +0530, srihari na wrote:
> > > > > Hello Folks,
> > > > >
> > > > > We are using HttpClient 4.2.5 and Our scenario is that there is only
> > 1
> > > > > instance of HTTP client throughout the JVM and only one connection
> > pool
> > > > > linked to client. The same client using the single connection pool
> > > > > interacts with various http/https endpoints by creating a new method
> > > > > instance for every request. For https based connections we have our
> > own
> > > > > implementation for socket connection factory, when we try to
> > register a
> > > > new
> > > > > custom scheme using custom socket factory via local context, it is
> > not
> > > > > being picked by the client. It always tries to get the list of scheme
> > > > > registries from connection manager even though we try to override at
> > > > local
> > > > > context level. We use local context to pass authentication
> > information
> > > > > which works perfectly fine however schemeregistry is not picked up.
> > > > >
> > > > > AbstractHttpClient
> > > > > protected HttpRoutePlanner createHttpRoutePlanner() {
> > > > >         return new DefaultHttpRoutePlanner(*getConnectionManager*
> > > > > *().getSchemeRegistry()*);
> > > > >     }
> > > > >
> > > > >
> > > > > Now that local context scheme registry is not picked up we tried
> > > > > registering all the schemes at connection manager level with unique
> > > > scheme
> > > > > names and pass the respective scheme name in the HttpHost of the
> > execute
> > > > > method.
> > > > > In the first pass route planner has the proper scheme name we set in
> > the
> > > > > HttpHost so it pickedup the proper socket factory
> > > > > DefaultHttpRoutePlanner.determineRoute(HttpHost, HttpRequest,
> > > > HttpContext)
> > > > > line: 113
> > > > > DefaultRequestDirector.determineRoute(HttpHost, HttpRequest,
> > HttpContext)
> > > > > line: 791
> > > > > DefaultRequestDirector.execute(HttpHost, HttpRequest, HttpContext)
> > line:
> > > > 414
> > > > > DefaultHttpClient(AbstractHttpClient).execute(HttpHost, HttpRequest,
> > > > > HttpContext) line: 906
> > > > >
> > > > > In the second pass the target it reconstructed using the URI so the
> > > > custom
> > > > > scheme name is lost and our custom socket factory is not picked up
> > > > > DefaultRequestDirector.handleResponse(RoutedRequest, HttpResponse,
> > > > > HttpContext) line: 1110
> > > > > *HttpHost newTarget = URIUtils.extractHost(uri);*
> > > > >
> > > > > DefaultHttpRoutePlanner.determineRoute(HttpHost, HttpRequest,
> > > > HttpContext)
> > > > > line: 113
> > > > > DefaultRequestDirector.determineRoute(HttpHost, HttpRequest,
> > HttpContext)
> > > > > line: 791
> > > > > DefaultRequestDirector.handleResponse(RoutedRequest, HttpResponse,
> > > > > HttpContext) line: 1129
> > > > > DefaultRequestDirector.execute(HttpHost, HttpRequest, HttpContext)
> > line:
> > > > 548
> > > > >
> > > > > Request the forum to help solve our scenario. You help is much
> > > > appreciated,
> > > > > awaiting a quick response.
> > > > >
> > > > > Thank you
> > > > >
> > > >
> > > > Please consider upgrading to 4.3.x. Even if it is a bug in HttpClient
> > > > there will be no more releases from the 4.2.x branch.
> > > >
> > > > 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]

Reply via email to