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