I agree with replacing the default socket factory; apart from lack of statistics, there is no proper control over re-use of connections with the default Sun version.
We looked at a possible replacement a while ago: HTTPClient 0.3-3 http://www.innovation.ch/java/HTTPClient/ [Because of the licence, this cannot be bundled with Apache.] But it might be possible to write an external wrapper to gather the statistics - perhaps it would be worth having a look at the implementation? Then there's Apache HttpClient: http://jakarta.apache.org/commons/httpclient/index.html I've not looked at this in any detail. Unlike the first HTTPClient it does not fully support the HttpUrlConnection API, so it cannot be used as a drop-in replacement. However, that is not necessarily a bad thing, as the HttpURLConnection API is not very flexible. Might be worth seeing what the Apache HttpClient team think about adding statistics to their version - if they don't already exist? === Aside: some of these e-mail trails are getting quite long - how about using the Wiki to collate the information? -- The opinions expressed herein are my own, and are not necessarily endorsed by my employer ... -----Original Message----- From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED] Sent: 12 August 2003 12:36 To: JMeter Developers List Subject: Re: AW: JMeter 2.0 [Re: Source dist build] Following Mike's prompt, I've been reading a little bit about socket factories, etc. and I now believe it can be done -- although it's probably difficult (or even very difficult). Here's my view of it: We replace the socket factory with one producing our own sockets. These sockets should do the same thing the current ones do, except they would leave trace of the times when relevant events happened: - Connection initiation - Connection established - 1st byte transmitted - last byte transmitted - 1st byte received - last byte received ... Having this data reach the sampler is not easy -- we'll probably need something hackish -- but I'm sure it can be done. Possibly keeping a registry of sockets in use by the current thread and having the app search for the right one. For protocols in which you can issue several requests over the same socket, there should also be a callback mechanism to reset the measuring and start over. This would provide, at the very least, the separation between 1+2+3+4 and 5, which is the most important. As I said, separating 1, 2 and 3 is probably not JMeter's role, but I'm sure we can still separate DNS resolution time by using the InetAddress class to do the resolution explicitly. With some more research, we can probably even reach some more detail... I'll start working on a proof-of-concept now: a socket that will output all those recorded times to stdout when it is closed. Salut, Jordi. Rittmeyer, Wolfram wrote: > Hi all, > > great ideas getting exchanged here between Mike, Jordi and Jeremy... > > I think seperation of tasks like Jordi mentioned would be a good think. I also highly welcome the idea of datasources by Mike. This would increase flexibility a lot. > > ----by Jordi: > >>Totally agree. The complete split would be: >>1- DNS resolution time >>2- Connection set-up time (SYN to SYN ACK) >>3- Request transmission time (SYN ACK to ACK of last request packet) >>4- Latency (ACK of last request packet to 1st response data packet) >>5- Response reception time >>I'm not sure JMeter is the tool to separate 1,2,3 (this is more of an >>infrastructure-level thing rather than application-level), >>but 1+2+3+4 >>separate from 5 is a must. Top commercial tools separate them all. > > > To my knowledge this will not be possible. DNS resolution time is not available with Java. Java does not give us access to these lowlevel data. No IP-flags as well. I once thought about it myself. The one and only solution I could think of was using JNI. But I didn't like the idea because we would loose platform independence with it. If I am wrong here I'd be glad to learn better... > > Anyway, future plans sound promising. > > Greetings, > > Wolfram Rittmeyer > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Salut, Jordi. --------------------------------------------------------------------- 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]
