jmeter-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 61380] JMeter shutdown using timers releases thundering herd of interrupted samplers
Date Fri, 04 Aug 2017 10:57:06 GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=61380

--- Comment #1 from Sebb <sebb@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.
Mime
View raw message