Bug 61380 - JMeter shutdown using timers releases thundering herd of interrupted samplers
Summary: JMeter shutdown using timers releases thundering herd of interrupted samplers
Status: RESOLVED FIXED
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 3.1
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-03 23:36 UTC by Antony Bowesman
Modified: 2017-08-09 00:25 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antony Bowesman 2017-08-03 23:36:34 UTC
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) {

}
Comment 1 Sebb 2017-08-04 10:57:06 UTC
(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.
Comment 2 Antony Bowesman 2017-08-07 00:47:14 UTC
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.
Comment 3 Philippe Mouawad 2017-08-07 20:51:31 UTC
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
Comment 4 Philippe Mouawad 2017-08-07 20:52:13 UTC
Hello,
Can you try nightly build tomorrow and give your feedback ?
http://jmeter.apache.org/nightly.html
Thanks
Comment 5 Antony Bowesman 2017-08-09 00:25:51 UTC
Tested the 3.1 build and the 3.2 nightly build, ref apache-jmeter-r1804400 and it fixed the problem.

Thanks!