jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Shutdown test releases thundering herd
Date Wed, 02 Aug 2017 08:34:08 GMT
On 2 August 2017 at 03:42, Antony Bowesman
<Antony.Bowesman@williamhill.com.au> wrote:
> Seems like there's a flaw in the shutdown logic
>
> When a test is running, it goes through JMeterThread. executeSamplePackage() where it
goes into the delay(pack.getTimers()) call.
>
> If you shut down a test, it will interrupt the timers and you will see these messages
in jmeter.log
>
> jmeter.threads.JMeterThread: The delay timer was interrupted - probably did not wait
as long as intended
>
> As a result, all threads blocked waiting to sample() will get released at pretty much
the same time and as the JMeter iteration logic does the delay _before_ the sample() rather
than after, it means all threads will go into sample() at about the same time.

If the test is stopping it does not make sense to start a new sample.
That seems like a bug, but I'm surprised it has not been noticed previously.

> We've had cases where we've had to stop a production test as we're breaking it and the
shutdown exacerbates the problem.
>
> As the JMeterThread.stop() sets the running flag to false, it's probably a simple fix
to wrap the code following the delay() call with
> if (running)
> {
>
> }
>
> With some possible additional logic for the compiler.done() call, which I don't yet understand.
>
> Another option would be to expose the running flag via JMeterThread.isRunning() so that
the sampler can find out if it's running, but that sounds more like a hack to solve the problem.
>
> Is this a bug or a feature?
>
> Antony
>

Mime
View raw message