hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erwan Arzur" <ear...@gmail.com>
Subject Re: HttpClient & custom host names resolving
Date Tue, 30 Jan 2007 17:05:19 GMT
Hey Roland,

it is not exactly attached to the request, but a context which would
be attached to the HttpClient. Basically i'd like to be able to create
several HttpClient instances, each using
different DNS server.

So i have built my own ProtocolSocketFactory which is called by my own
HttpConnection and HttpConnectionManager (mimics
MultiThreadedHttpConnectionManager using commons pool's
KeyedSimpleObjectPool, i did not feel like modifying that beast ;-))

I did a few stress test runs today and it seems to handle the load properly.

I agree about the code duplication with open(), and relying on
HttpClient instance variables not being modified being really risky
and would like to find a better, more elegant solution.

My understanding with Protocol is that there is only one Protocol
instance in the VM for a given protocol ("http", "https", etc ...),
and that doesn't suits me because i need to be able to use different
ProtocolSocketFactory instances for the same Protocol. Am i utterly
wrong in that assumption ?

I'm not very familiar with ThreadLocal so don't understand your
solution. It seems very elegant and would like you to elaborate ;-)
Again, correct me if i'm wrong but Protocol.registerProtocol() doesn't
allow to register more than one instance for the whole VM, while I'm
running several HttpClient instances concurrently.

Thanks for all, glad to have such in-depth technical responses to my
first message on this list !

Erwan
On 1/29/07, Roland Weber <http-async@dubioso.net> wrote:
> Hello Erwan,
>
> > instance variables of HttpConnection to "protected", in order to be
> > able to override open() in an inheriting class. This creates code
> > duplication (because open() has a lot of logic inside), but seems to
> > provide the service.
>
> How that? Didn't you say you want to switch based on any information
> in the request? You don't have access to the HttpMethod from within
> the connection. Besides, you need to change the connection manager
> as well, because the connection class is derived there. That creates
> ugly mutual dependencies between the modified HttpClient code and
> your code.
>
> > If there is another, more simple or proper way of doing that, i'd be
> > happy to hear about it ;-)
>
> Simple *and* proper? Not with 3.x I'm afraid ;-(
>
> If you have to change the HttpClient code anyway, you can either
> put your code directly in place, or you could implement hook methods
> to be overridden by derived classes:
>
>    open(...) throws... {
>       ...
>       WhatINeed win = createSocketHook(...);
>       Socket s = new Socket(...win...);
>    }
>
> Another alternative is that you write your own socket factory and
> access the HttpMethod object (=request) from a ThreadLocal attribute
> somewhere. Damn, I should have thought about that in the first place.
> Let the application put the method in a ThreadLocal just before
> HttpClient.execute is called. The socket factory will be called by
> the same thread. You tell HttpClient to use your own socket factory
> by registering instances of the Protocol class:
> http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/protocol/Protocol.html
>
> hope that helps,
>   Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>

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


Mime
View raw message