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/03 23:36:34 UTC
[Bug 61380] New: JMeter shutdown using timers releases thundering
herd of interrupted samplers
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.
[Bug 61380] JMeter shutdown using timers releases thundering herd of
interrupted samplers
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61380
--- Comment #4 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Hello,
Can you try nightly build tomorrow and give your feedback ?
http://jmeter.apache.org/nightly.html
Thanks
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 61380] JMeter shutdown using timers releases thundering herd of
interrupted samplers
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61380
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
CC| |p.mouawad@ubik-ingenierie.c
| |om
--- Comment #3 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 61380] JMeter shutdown using timers releases thundering herd of
interrupted samplers
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61380
--- Comment #2 from Antony Bowesman <an...@williamhill.com.au> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 61380] JMeter shutdown using timers releases thundering herd of
interrupted samplers
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61380
--- Comment #5 from Antony Bowesman <an...@williamhill.com.au> ---
Tested the 3.1 build and the 3.2 nightly build, ref apache-jmeter-r1804400 and
it fixed the problem.
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 61380] JMeter shutdown using timers releases thundering herd of
interrupted samplers
Posted by bu...@apache.org.
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.