Not yet; we are discussing how to best integrate the HttpClient implementation at the moment - there are quite a few places that assume the standard http implementation is being used.
Sebastian -----Original Message----- From: Sonam Chauhan [mailto:[EMAIL PROTECTED] Sent: 06 July 2004 05:06 To: 'JMeter Users List' Subject: RE: HTTP timeout setting? Thanks Seb. I won't be able to test right away, but I hope to get back to you soon. I use the web services sampler in some tests. This setting does not apply to the web services or XML/RPC sampler, right? With regards, Sonam Chauhan -- Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Fax: 9335-0753, Email: [EMAIL PROTECTED] > -----Original Message----- > From: Sebastian Bazley [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 6 July 2004 9:38 AM > To: JMeter Users List > Subject: Re: HTTP timeout setting? > > Found some time and updated the main and rev 2.0 branches; just set the > jmeter property "httpclient.timeout" (see jmeter.properties). > Set the property to 0 (the default) to disable timeouts. > > Please let us know if this works - or not. > > S. > ----- Original Message ----- > From: "BAZLEY, Sebastian" <[EMAIL PROTECTED]> > To: "'JMeter Users List'" <[EMAIL PROTECTED]> > Sent: Monday, July 05, 2004 10:52 AM > Subject: RE: HTTP timeout setting? > > > > I've added the stopThreadNow() method, and one can automate the > BeanShell > > server by passing it a suitable startup script - however it would be > hard > > work for the script to detect the hanging threads. Anyway, using a > timeout > > means that the thread could potentially continue. > > > > [In theory one could use the TCPClient to issue the HTTP requests, but > > again, that would be hard work.] > > > > It should be easy enough to add a call to the HTTPClient.setTimeout() > > method, based on the value of a JMeter property. It would be a bit more > work > > to make the timeout variable, so perhaps best to start simple and extend > as > > needed. I'll see about adding it later this week - or, if you have the > > facilities to build JMeter, I guess you could do it yourself if you need > it > > right away. > > > > S. > > >-----Original Message----- > > >From: Sonam Chauhan [mailto:[EMAIL PROTECTED] > > >Sent: 05 July 2004 04:32 > > >To: 'JMeter Users List' > > >Subject: RE: HTTP timeout setting? > > > > > > > > >Thanks Seb. Since my JMeter are automated, changing the > > >timeout is the only > > >option I have. I looked up the Jakarta HTTPClient documentation and it > > >mentioned this method: > > >-------------------------------------- > > >HTTPClient.setTimeout(int newTimeoutInMilliseconds) > > > Sets the socket timeout (SO_TIMEOUT) in milliseconds > > >which is the > > >timeout for waiting for data. > > >-------------------------------------- > > > > > >However, grepping the 1.9.1 codebase for 'setTimeout' shows only > > >TCPSampler.java setting a timeout (specified using this property: > > >"TCPSampler.timeout"). > > > > > >Does this means that the default timeout for the HTTP samplers > > >is '0' (never > > >time out)? > > > > > >With regards, > > >Sonam Chauhan > > >-- > > >Corporate Express Australia Ltd. > > >Phone: +61-2-9335-0725, Fax: 9335-0753, Email: [EMAIL PROTECTED] > > > > > > > > >> -----Original Message----- > > >> From: BAZLEY, Sebastian [mailto:[EMAIL PROTECTED] > > >> Sent: Friday, 2 July 2004 7:57 PM > > >> To: 'JMeter Users List' > > >> Subject: RE: HTTP timeout setting? > > >> > > >> I just recently checked in a change to the rel 2.0 branch > > >which allows one > > >> to use the BeanShell server to shut a test or a thread - see > > >my recent > > >> posting in reply to "how can i see which thread is currently being > > >> run?(solution to RAMP DOWN!)" > > >> > > >> The new methods correspond to the GUI Stop and Shutdown options: > > >> stopEngine() = GUI shutdown > > >> stopEngineNow() = GUI stop > > >> > > >> In your case, you'ld probably need to use the > > >stopEngineNow() method, as > > >> the > > >> others just set a flag and wait for current activity to cease. But at > > >> least > > >> you could get JMeter to finish up. > > >> > > >> Perhaps I should add a stopThreadNow() method? > > >> > > >> == > > >> > > >> As to the timeout, it might be worth checking the Apache HTTPClient > > >> documentation - this is used by the new HTTP Sampler. If there is a > > >> timeout > > >> facility, it should be quite easy to add it - or it might > > >even already be > > >> controllable by a property. > > >> > > >> Sebastian > > >> -----Original Message----- > > >> From: Sonam Chauhan [mailto:[EMAIL PROTECTED] > > >> Sent: 02 July 2004 08:47 > > >> To: 'JMeter Users List' > > >> Subject: HTTP timeout setting? > > >> > > >> > > >> Hello JMeter experts! > > >> > > >> I have been using JMeter to tease out a server bug that only shows up > > >> under > > >> load. The problem is that when I reproduce this bug, the > > >remote server > > >> hangs, but due to the HTTP connections already being made, > > >JMeter hangs > > >> too. > > >> I run JMeter in non-GUI mode (-n), so I have no easy way to > > >stop the test > > >> threads. > > >> > > >> Is there a HTTP timeout setting that will cause JMeter (or Java) to > > >> terminate an HTTP connections if no bytes were transmitted > > >for a timeout > > >> duration? > > >> > > >> With regards, > > >> Sonam Chauhan > > >> > > >> -- > > >> Corporate Express Australia Ltd. > > >> Phone: +61-2-9335-0725, Fax: 9335-0753, Email: [EMAIL PROTECTED] > > >> <mailto:[EMAIL PROTECTED]> > > >> > > >> PS: Sorry if there is an obvious answer, but a google query > > >on "jmeter > > >> http > > >> timeout site:jakarta.apache.org" didn't showup anything. > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >_______________________________________________________________ > > >___________ > > >> _ > > >> > > >> 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] > > > > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- 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]
