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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
