jmeter-issues mailing list archives

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

            Bug ID: 61380
           Summary: JMeter shutdown using timers releases thundering herd
                    of interrupted samplers
           Product: JMeter
           Version: 3.1
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Main
          Assignee: issues@jmeter.apache.org
          Reporter: antony.bowesman@williamhill.com.au
  Target Milestone: ---

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

}

-- 
You are receiving this mail because:
You are the assignee for the bug.
Mime
View raw message