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.
-----Original Message----- From: BAZLEY, Sebastian [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 11:39 AM To: 'JMeter Developers List' Subject: RE: Proposed changes to HTTP Samplers [long] It is easy enough to enhance the Sample Result class(es) to include fields to hold the extra information, and some of it is easy to collect, e.g. the sizes. However, some of the timings may not be available without changes to the underlying http protocol. This will need to be investigated - maybe you can help here? In fact, apart from the sizes, it is probably not possible to collect any of the extra information from the default http implementation (one of the reasons we are trying HTTPClient). == AFAIK, connections can already be re-used with HTTPClient (set keep-alive); it's not possible to do this with the standard http implementation. [The reasons have been discussed several times in the lists.] As you say, the GUIs would need to be enhanced as well to make use of the new information. S. -----Original Message----- From: Jonathan Easterling [mailto:[EMAIL PROTECTED] Sent: 06 July 2004 13:45 To: JMeter Developers List Subject: RE: Proposed changes to HTTP Samplers [long] While changes are going on, may I make a few suggestions about making JMeter more robust in the HTTP Statistics area: Record the time to the first byte in the request. Record the time to the first byte in the response. Record the time to the last byte in the request. Record the time to the last byte in the response. Record the time to the connect. Record the time to the disconnect. Record the size of the request. Record the size of the response. Option to re-use connections (like IE does). By a brief look at the code, it would appear the GUI would also have to change to handle this area. Right now it would appear that the GUI only knows how to handle one timer event. We could add a hashtable to have all the timer events and still have the Sampler return the current implementation as default but if the gui can extract the data, then it could get a reference to the hashtable and start plotting/calulating/displaying based on all the hashtable. Suggestions, comments? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___________________________________________________________________________ --------------------------------------------------------------------- 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]
