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. I don't know HTTPClient well enough, but one approach might be to extend the class locally for JMeter and add the necessary performance metrics. peter On Wed, 7 Jul 2004 09:22:21 -0400, Jonathan Easterling <[EMAIL PROTECTED]> wrote: > 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 listening (in a single threaded send/response model) only when you try to send > more data down the line, then it pop's the exception. The internals however are not > to shabby (the Sun.io.*) but it's non-[(standard)(supported)(reconized)(stable)] so > it's not a good choice either. (btw, try to do FTP that does multiple gets using the > URL stuff, it's not easy). Instead of re-implementing the java.net.URL for this, I > agree it may be a more benifital approch to first switch over to the Apache > HTTPClient stuff (at least won't have to do all the manual re-direction stuff), and > then as a seperate task see what it would take to extend the HTTPClient, when that's > working right it would be a simple class replacement. > If this approch sounds reasonable, let me know and I will start to pull together > what would have to change (and learn how the commons.net stuff does it's IO) > Thanks > Jon. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
