Don't see any problems with that as a short term solution. I will take a
look at a longer term solution here when I get a chance.
- Dan
Michael Youngstrom wrote:
Yes, that helps some. Perhaps what I'll do for now is try creating my
own channel that simply retains the HttpClient in a ThreadLocal to
help solve our problem right now and let you do the correct solution
of moving things around to reuse Channel instances when you get a
chance. :) If I get some time perhaps I'll take a stab at it but that
may be a little much for me.
Do you see any immediate red flags with storing the HttpClient in a
ThreadLocal in the channel keyed by its URL? As a short term patch of
course.
Mike
On 3/16/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:
Michael Youngstrom wrote:
I've been experiencing some performance problems with Xfire
originating from I believe Http connection times. I was doing some
research into support for persistent connections and it appears Http
commons supports this automatically. The problem is you need to use
the same HttpClient instance for each client.executeMethod() call and
it appears CommonsHttpMessageSender is creating a new HttpClient each
time a message is sent, HttpChannel is creating a new
CommonsHttpMessageSender with every message, and it appears
SoapHttpTransport is creating a new Channel for each invocation.
Do you think it would be possible to either enhance
CommonsHttpMessageSender to reuse HttpClient instances or create an
alternative MessageSender that supports persistent connections?
I'd be happy to do it myself with a little direction. My current
hiccup is I am unsure about the direction I should take with
SoapHttpTransport creating a new channel with each invocation, etc..
Is that necessary? Does anyone this it would be theoretically
possible to create a custom SoapHttpTransport that can reuse a channel
and hence reuse an HttpClient?
Mike
Yes, we definitely need to start reusing the HttpClients. I think its
probably best to rework things a bit so we reuse the same Channel every
time and cache things that way. We are caching the HttpState in
ThreadLocal right now, but I think that method is pretty limited and we
need to move to something else.
Is that enough to get you going? Regards,
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
