I've taken a closer look at what I've done. The Request/Response Interceptor approach doesn't work for catching the various timeouts since the interceptors aren't called in those cases. So what I have currently is an approach where you can instantiate a JmxEnabledHttpClient given an HttpClient (uses the decorator pattern from the HttpClient interface). Unit tests are also in place.
I think what makes the most sense is for me to remove the external dependencies, which shouldn't take me long, and then show it to Oleg to see what he recommends as far as the best way to integrate. I should have this ready by the end of the week. At the point at which I'm ready, what's the best way to handle showing it to folks? Check it in to the trunk or a branch? Or something more informal? Thanks, Mike ----- Original Message ----- From: mboyers <[email protected]> To: HttpClient User Discussion <[email protected]> Cc: Sent: Wednesday, August 8, 2012 10:46 PM Subject: Re: Instrumenting HttpClient library Jaikit, Thanks. I'll take a look at things on Friday when I return to work and will decide from there. Mike On Aug 8, 2012, at 1:41 PM, Jaikit Savla <[email protected]> wrote: > Hi Mike, > > I am fine with both options which you mentioned. What is the timeline you are > planning to integrate ? If you do not have bandwidth than I can assist you or > start from your code base. Let me know. > > Thanks, > Jaikit > > > ________________________________ > From: Gary Gregory <[email protected]> > To: HttpClient User Discussion <[email protected]> > Sent: Wednesday, August 8, 2012 5:44 AM > Subject: Re: Instrumenting HttpClient library > > Sounds like a nice contribution and efficient for you to do since you've > already done this before. > > Gary > > On Wed, Aug 8, 2012 at 8:41 AM, mboyers <[email protected]> wrote: > >> Hi Jakit, >> >> I'm the author of the original post you referenced below. I used the >> decorator pattern to create an InstrumentedHttpClient and I'm keeping JMX >> status for everything I mentioned below. >> >> My solution also uses some Spring dependencies so it would need to change >> a bit in order to integrate into the project, but all of the MBeans and >> tracking code is there. >> >> I could either hand this code to you as a starting point or could look >> into integrating it into the project myself. I've wanted to contribute for >> a while since I've used HttpClient for so many years. >> >> Thanks, >> Mike >> >> On Aug 8, 2012, at 4:29 AM, Jaikit Savla <[email protected]> >> wrote: >> >>> Hi Oleg, >>> >>> I have created a feature request with little detail about how I am >> planning to implement. Please comment if something needs to be corrected. >>> >>> https://issues.apache.org/jira/browse/HTTPCLIENT-1222 >>> >>> >>> Thanks, >>> Jaikit >>> >>> >>> ________________________________ >>> From: Oleg Kalnichevski <[email protected]> >>> To: "[email protected]" <[email protected]> >>> Sent: Tuesday, August 7, 2012 5:02 AM >>> Subject: Re: Instrumenting HttpClient library >>> >>> On Mon, 2012-08-06 at 21:39 -0700, Jaikit Savla wrote: >>>> For some reason my previous email had junk characters hence resending - >> sorry for spam. >>>> >>>> Hi Team, >>>> >>>> Is monitoring via JMX already implemented in HttpClient ? >>>> -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 >>>> >>>> If not than can someone please point me to some similar extensions ? I >> can submit a patch for JMX monitoring. >>>> >>>> related request: >>>> http://old.nabble.com/Instrumenting-HttpClient-4-td29464148.html >>>> >>>> Thanks, >>>> Jaikit >>> >>> Jaikit >>> >>> There is no JMX support in HttpClient at this point. If you are willing >>> to put some work toward providing JMX support in HttpClient through an >>> optional module, we would happily take it as a contribution. >>> >>> Cheers >>> >>> Oleg >>> >>> >>> --------------------------------------------------------------------- >>> 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] >> >> > > > -- > E-Mail: [email protected] | [email protected] > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- 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]
