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? > > > > 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? > > > And one final question: I'd like to consider the > possibility of handing out an HttpClient that will not talk > to any host unless it has been explicitly configured (to > force developers to think about the proper max pool size so > we fail fast when a remote source is having issues). > What I'm thinking is something like: > > ConnPerRouteBean connPerRoute = new > ConnPerRouteBean(0); > > > > // Then explicitly enable hosts as follows > > HttpHost localhost = new HttpHost("localhost", > 8080); > > localhostRoute = new HttpRoute(localhost); > > connPerRoute.setMaxForRoute(localhostRoute, > 10); > > > ConnManagerParams.setMaxConnectionsPerRoute(params, > connPerRoute); > > > > But I currently get an exception when instantiating > ConnPerRouteBean with 0 (needs to be a positive > integer). Is there a different way to accomplish this > other than the path I've outlined above? > > > > We have not thought of this kind of situation so currently > there is not > way to prevent the pooling connection manager from creating > connections > to a particular target host by setting the per route limit > to zero. > > The only solution to the problem I can think of from the > top of my head > is a custom connection manager that requires an explicit > route > configuration before a connection for that particular route > can be made. > > Overall, I think you will be better off by developing a > custom > connection manager given a fairly uncommon set of > requirements that you > have. I will probably not worry about this for now and will instead just set a relatively small default value for max connections per pool. Thanks Oleg. Your response was helpful. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
