You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Jaikit Savla <ja...@yahoo.com> on 2012/09/29 01:21:53 UTC
Re: Instrumenting HttpClient library
Hi Mike,
Have you submitted the patch ?
Thanks,
Jaikit
----- Original Message -----
From: Oleg Kalnichevski <ol...@apache.org>
To: Mike Boyers <mb...@yahoo.com>
Cc: HttpClient User Discussion <ht...@hc.apache.org>
Sent: Monday, August 13, 2012 11:08 AM
Subject: Re: Instrumenting HttpClient library
On Sun, 2012-08-12 at 20:00 -0700, Mike Boyers wrote:
> 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
>
Mike
Probably the most practical approach is to clone HttpClient [1] at
GitHub and start hacking on your private copy. Once reasonably satisfied
with your solution, raise a JIRA and attach a patch generated as a diff
between your private branch and HttpClient trunk. You might as well
create a pull request but currently there is no way of merging pull
requests from GitHub to the official ASF repository (I know of).
Please also note there have been a number of significant API changes on
the trunk. They mainly concern the way various processing aspects can be
chained together into a processing pipeline. This should give you more
options as to at which point to inject JMX probes. For instance, when
collecting stats on the HttpClient interface level one may be unable to
differentiate simple HTTP exchanges from those that require redirect(s)
or authentication, which can distort the stats.
Oleg
PS: I'll be away on vacation starting tomorrow until August 22nd and may
be unable to review patches promptly enough. Please be patient.
[1] https://github.com/apache/httpclient
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Instrumenting HttpClient library
Posted by Mike Boyers <mb...@yahoo.com>.
Jaikit,
I have submitted the patch via JIRA: https://issues.apache.org/jira/browse/HTTPCLIENT-1246
Mike
----- Original Message -----
From: Mike Boyers <mb...@yahoo.com>
To: HttpClient User Discussion <ht...@hc.apache.org>; Jaikit Savla <ja...@yahoo.com>
Cc:
Sent: Monday, October 1, 2012 8:57 AM
Subject: Re: Instrumenting HttpClient library
Jaikit,
I have not.
At this point, I don't know when things are going to let up for me, and I don't want to hold this effort up.
What I have at this point is a version of an InstrumentedHttpClient that implements the HttpClient interface. You can instantiate an InstrumentedHttpClient given an HttpClient. I have decoupled it from the work I had done previously (Spring-dependent), so it works without any additional dependencies. I probably just need a couple more hours to clean this area up. I did work on it a bit yesterday.
But I have not made progress in integrating the stats more closely with the HttpClient codebase. So it doesn't currently have visibility into some of the underlying behavior of HttpClient and some of the mechanisms for retaining and managing statistics could probably be done more cheaply if they were integrated more closely. This is the area I just don't think I'm going to be able to find the time to do, sadly.
So what I'm thinking at this point: I'll hand off what I've done (which is functional) and you guys can decide on whether or not to use it as the basis for anything going forward. Even if you decide not to ultimately check it in with the rest of the HttpClient code, it could still be useful to you in the short-term, as it could easily be turned into its own jar and used with the existing HttpClient. I'm pretty sure it records everything we talked about previous except the current pool size.
Mike
----- Original Message -----
From: Jaikit Savla <ja...@yahoo.com>
To: HttpClient User Discussion <ht...@hc.apache.org>; Mike Boyers <mb...@yahoo.com>
Cc:
Sent: Friday, September 28, 2012 7:21 PM
Subject: Re: Instrumenting HttpClient library
Hi Mike,
Have you submitted the patch ?
Thanks,
Jaikit
----- Original Message -----
From: Oleg Kalnichevski <ol...@apache.org>
To: Mike Boyers <mb...@yahoo.com>
Cc: HttpClient User Discussion <ht...@hc.apache.org>
Sent: Monday, August 13, 2012 11:08 AM
Subject: Re: Instrumenting HttpClient library
On Sun, 2012-08-12 at 20:00 -0700, Mike Boyers wrote:
> 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
>
Mike
Probably the most practical approach is to clone HttpClient [1] at
GitHub and start hacking on your private copy. Once reasonably satisfied
with your solution, raise a JIRA and attach a patch generated as a diff
between your private branch and HttpClient trunk. You might as well
create a pull request but currently there is no way of merging pull
requests from GitHub to the official ASF repository (I know of).
Please also note there have been a number of significant API changes on
the trunk. They mainly concern the way various processing aspects can be
chained together into a processing pipeline. This should give you more
options as to at which point to inject JMX probes. For instance, when
collecting stats on the HttpClient interface level one may be unable to
differentiate simple HTTP exchanges from those that require redirect(s)
or authentication, which can distort the stats.
Oleg
PS: I'll be away on vacation starting tomorrow until August 22nd and may
be unable to review patches promptly enough. Please be patient.
[1] https://github.com/apache/httpclient
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Instrumenting HttpClient library
Posted by Mike Boyers <mb...@yahoo.com>.
Jaikit,
I have not.
At this point, I don't know when things are going to let up for me, and I don't want to hold this effort up.
What I have at this point is a version of an InstrumentedHttpClient that implements the HttpClient interface. You can instantiate an InstrumentedHttpClient given an HttpClient. I have decoupled it from the work I had done previously (Spring-dependent), so it works without any additional dependencies. I probably just need a couple more hours to clean this area up. I did work on it a bit yesterday.
But I have not made progress in integrating the stats more closely with the HttpClient codebase. So it doesn't currently have visibility into some of the underlying behavior of HttpClient and some of the mechanisms for retaining and managing statistics could probably be done more cheaply if they were integrated more closely. This is the area I just don't think I'm going to be able to find the time to do, sadly.
So what I'm thinking at this point: I'll hand off what I've done (which is functional) and you guys can decide on whether or not to use it as the basis for anything going forward. Even if you decide not to ultimately check it in with the rest of the HttpClient code, it could still be useful to you in the short-term, as it could easily be turned into its own jar and used with the existing HttpClient. I'm pretty sure it records everything we talked about previous except the current pool size.
Mike
----- Original Message -----
From: Jaikit Savla <ja...@yahoo.com>
To: HttpClient User Discussion <ht...@hc.apache.org>; Mike Boyers <mb...@yahoo.com>
Cc:
Sent: Friday, September 28, 2012 7:21 PM
Subject: Re: Instrumenting HttpClient library
Hi Mike,
Have you submitted the patch ?
Thanks,
Jaikit
----- Original Message -----
From: Oleg Kalnichevski <ol...@apache.org>
To: Mike Boyers <mb...@yahoo.com>
Cc: HttpClient User Discussion <ht...@hc.apache.org>
Sent: Monday, August 13, 2012 11:08 AM
Subject: Re: Instrumenting HttpClient library
On Sun, 2012-08-12 at 20:00 -0700, Mike Boyers wrote:
> 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
>
Mike
Probably the most practical approach is to clone HttpClient [1] at
GitHub and start hacking on your private copy. Once reasonably satisfied
with your solution, raise a JIRA and attach a patch generated as a diff
between your private branch and HttpClient trunk. You might as well
create a pull request but currently there is no way of merging pull
requests from GitHub to the official ASF repository (I know of).
Please also note there have been a number of significant API changes on
the trunk. They mainly concern the way various processing aspects can be
chained together into a processing pipeline. This should give you more
options as to at which point to inject JMX probes. For instance, when
collecting stats on the HttpClient interface level one may be unable to
differentiate simple HTTP exchanges from those that require redirect(s)
or authentication, which can distort the stats.
Oleg
PS: I'll be away on vacation starting tomorrow until August 22nd and may
be unable to review patches promptly enough. Please be patient.
[1] https://github.com/apache/httpclient
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org