jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BAZLEY, Sebastian" <>
Subject RE: HTTP timeout setting?
Date Mon, 05 Jul 2004 09:52:53 GMT
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.

>-----Original Message-----
>From: Sonam Chauhan []
>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
> setting a timeout (specified using this property:
>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:
>> -----Original Message-----
>> From: BAZLEY, Sebastian []
>> 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 []
>> 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:
>> <>
>> PS: Sorry if there is an obvious answer, but a google query 
>on "jmeter
>> http
>> timeout" 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:
>> For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message