On Fri, 2010-08-27 at 11:41 -0700, Mike Boyers wrote: > My comments inlined below. > > --- On Tue, 8/17/10, Oleg Kalnichevski <[email protected]> wrote: > > > From: Oleg Kalnichevski <[email protected]> > > Subject: Re: Instrumenting HttpClient 4 > > To: "HttpClient User Discussion" <[email protected]> > > Date: Tuesday, August 17, 2010, 5:05 PM > > On Tue, 2010-08-17 at 12:18 -0700, > > Mike Boyers wrote: > > > I've been a user of HttpClient 3 for several years and > > am now migrating to using HttpClient 4. > > > > > > With version 3, I wrapped (extended) the client in > > order to instrument it (via JMX). I kept track of the > > following pieces of information, per host: > > > -Number of request (socket) timeouts > > > -Number of connection timeouts > > > -Number of timeouts while waiting for connection from > > pool > > > -Total number of requests > > > -Average Request duration > > > -Maximum Request duration > > > -Number of connections currently in pool > > > -Max connections in pool > > > > > > With HttpClient version 4, I'd rather not extend the > > client and would instead like have developers use a > > pre-configured httpclient that was created with a > > ThreadSafeClientConnManager. > > > > > > I can see how to use a HttpRequestInterceptor and > > HttpResponseInterceptor > > > to record things like number of transactions, request > > durations, etc. > > > > > > What I need help with is determining how I can record > > timeout information. When I'd recorded this in the > > past, I caught exceptions thrown by HttpClient's execute > > method in my extended class. It looks like when I call > > execute on HttpClient 4, if an exception is thrown, the > > HttpResponseInterceptor will not be called. I'm not > > sure where to intercept in this case. > > > > HttpClient is an interface in 4.x, so instead of extending > > its default > > implementation you should consider using the Decorator > > pattern in order > > to introduce additional functionality. > > > > Yes - I will use the decorator pattern to achieve this. > > I was wondering if there was a wider interest in the type of instrumentation > I mentioned? I know when I implemented it for HttpClient 3, it was > invaluable in being proactive about tracking problems. I'm using some other > packages (ehCache, logback) that support JMX out of the box (made optional > via configuration if you don't want it). Is there any community interest for > doing so in HttpClient or is it considered out of scope? >
I think it would be a valuable contribution. Please note it is generally easier to integrate new code into an existing ASF project if it does not bring many new external dependencies with it. > > > > > > Another related question: I typically have a scheduled > > task that occasionally calls the connection manager's > > closeIdleConnections method. After I do this, when I > > want to learn how many connections are in each pool, I have > > to have kept track of each HttpRoute and then call the > > getConnectionsInPool(route) method for each route. Is > > there a way I can have the connection manager give me the > > list of routes so I don't have to keep track of them > > myself? > > > > > > > Presently not. It should be fairly easy to add, though, as > > the > > ConnPoolByRoute class maintains a map of unique routes > > internally. > > That would be great if it could be added. Is this something I need to > formally request? > Raising a feature request in JIRA is the recommended way to go about such things. Please also consider investing some into providing an initial implementation of the requested feature. Wiliness to 'scratch your own itch' usually helps a great deal. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
