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. 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) { }
(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're right with more needed, I just didn't understand the extra logic it was going through. I originally assumed that there would be a public boolean isRunning() method on the JMeterThread instance and was surprised to find there wasn't. Would this be a chance to expose state like that, as it would allow, particularly Java, samplers to also check state.
Author: pmouawad Date: Mon Aug 7 20:49:23 2017 New Revision: 1804356 URL: http://svn.apache.org/viewvc?rev=1804356&view=rev Log: Bug 61380 - JMeter shutdown using timers releases thundering herd of interrupted samplers Within this bug, improve fix for bug 57958 which does not handle correctly the shutdown. Bugzilla Id: 61380 Modified: jmeter/trunk/src/core/org/apache/jmeter/threads/JMeterThread.java jmeter/trunk/xdocs/changes.xml
Hello, Can you try nightly build tomorrow and give your feedback ? http://jmeter.apache.org/nightly.html Thanks
Tested the 3.1 build and the 3.2 nightly build, ref apache-jmeter-r1804400 and it fixed the problem. Thanks!
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/4459