You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2017/08/04 10:57:06 UTC

[Bug 61380] JMeter shutdown using timers releases thundering herd of interrupted samplers

https://bz.apache.org/bugzilla/show_bug.cgi?id=61380

--- Comment #1 from Sebb <se...@apache.org> ---
(In reply to Antony Bowesman from comment #0)
> 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

Those messages should be suppressed if 'running' is false.

> 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.
> 
> 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) {
> 
> }

May have to do a bit more than that in order to complete transaction samplers.

-- 
You are receiving this mail because:
You are the assignee for the bug.