Ok, after some poking around in code, the
org.apache.jmeter.protocol.http.sampler.HTTPSampler, it appears to use the standard
java.net.URL stuff (IMHO is a very poor effort on Sun's part) It does not allow for
lower level control of the IO. For example you only know of a disconnect when you are
I believe commons.HTTPClient uses sockets, so extending it with
performance metrics should be simple technically.
the trick will be to get the commons developers to accept the patch.
Most people do not use HTTPClient to measure performance, so having it
as part of HTTPClient may be questionable.
We already have a sampler using Apache HTTPClient, which is the class
org.apache.jmeter.protocol.http.sampler.HTTPSampler2
[Part of my original e-mail was about making it easier to use this sampler
elsewhere.]
So that part is done; what needs to be established is what stats can be
obtained
I think this is all a great idea. My suggestion would be to separate
the data from the execution (oi, not OO!) and here's why:
If you had a class that just held the data for a web request,
independent of Sun's HTTP Client or Apache's, then that would solve your
last problem by having everything
