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 2018/08/19 12:48:23 UTC
[Bug 62637] New: Synchronizing Timer set by threads is stuck when
adding duration
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
Bug ID: 62637
Summary: Synchronizing Timer set by threads is stuck when
adding duration
Product: JMeter
Version: 4.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Main
Assignee: issues@jmeter.apache.org
Reporter: orimarko@gmail.com
Target Milestone: ---
Created attachment 36099
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36099&action=edit
jmx reproducer
When I'm using Synchronizing Timer set by threads (Number of Simultaneous Users
to Group by) it works well except when using with Thread group's duration,
When it's used together the test hang, probably because of Synchronizing issue,
as documented:
If timeout in milliseconds is set to 0 and number of threads never reaches
"Number of Simultaneous Users to Group by" then Test will pause infinitely.
Only a forced stop will stop it. Setting Timeout in milliseconds is an option
to consider in this case.
Also Runtime Controller isn't a valid replacement for limiting the duration,
Is there other way to limit test duration, but still use some kind of
Synchronization of threads?
Can I add a hook using JSR233 Sampler when test duration over and stop all
threads?
I'm thinking of using Precise Throughput Timer, but it seems over complicated
for this specific requirement.
I can make test no hang if I put a value in Timeout in milliseconds with value
higher than expected in a normal flow, as 10 seconds, 10000, and then after 10
seconds the test stops, but I'm not sure it fixes the issue completely.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
Felix Schumacher <fe...@internetallee.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #36100|0 |1
is obsolete| |
--- Comment #5 from Felix Schumacher <fe...@internetallee.de> ---
Created attachment 36101
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36101&action=edit
Use endTime of JMeterThread for SyncTimer
As noted by Vladimir, we have the endTime already at hand. So use that for the
Timer.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
--- Comment #3 from Vladimir Sitnikov <si...@gmail.com> ---
Ah, https://bz.apache.org/bugzilla/show_bug.cgi?id=60049 did not add
"interrupt", but it just added a cap on maximum delay (to ensure the delay is
within the test duration).
However, there's long endTime = getThreadContext().getThread().getEndTime(), so
there's still no need in new interface.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
--- Comment #2 from Vladimir Sitnikov <si...@gmail.com> ---
Felix, is BlockingTimer really required there?
It looks like SyncTimer fails to respond to Thread#interrupt which is used by
JMeter to terminate threads at test finish.
Current action is just "return 0", however it should probably call
Thread.currentThread().interrupt(); before returning.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
--- Comment #14 from Felix Schumacher <fe...@internetallee.de> ---
Date: Wed Aug 22 16:16:00 2018
New Revision: 1838655
URL: http://svn.apache.org/viewvc?rev=1838655&view=rev
Log:
Remove unit test, as it interferes with the other tests right now
The Spock mock/stub mechanism seems to play not nicely together with our test
runner
that executes all tests in one JVM.
Bugzilla Id: 62637
Date: Wed Aug 22 16:41:12 2018
New Revision: 1838658
URL: http://svn.apache.org/viewvc?rev=1838658&view=rev
Log:
Add a unit test that is hopefully compatible with our test runner
The first unit test with Spock caused havoc on our test runner. This unit test
includes the same tests without using a mock/stub from Spock.
Bugzilla Id: 62637
Added:
jmeter/trunk/test/src/org/apache/jmeter/timers/SyncTimerTest.java (with
props)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
--- Comment #1 from Felix Schumacher <fe...@internetallee.de> ---
Created attachment 36100
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36100&action=edit
Add a BlockingTimer interface
The main problem here is, that SyncTimer does not calculate a delay, but IS the
delay.
To mitigate this, this patch adds a new interface BlockingTimer, that indicates
this behaviour. Anyone implementing this interface has the responsibility to
stop "calculating" the delay when max end time has reached.
With this patch I am not able to reproduce the reported hangs anymore.
But to be honest, it will be easy to produce similar hangs with other timers
that behave in the same way and block while calculating the delay.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
--- Comment #8 from Felix Schumacher <fe...@internetallee.de> ---
Created attachment 36103
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36103&action=edit
Allow Long.MAX_VALUE as value for initialDelay in TimerService
If initialDelay is too big we get an overflow and the wrong value will be
returned.
This is needed for the actual patch for this bug.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
--- Comment #6 from Vladimir Sitnikov <si...@gmail.com> ---
Felix, it looks like org.apache.jmeter.timers.TimerService#adjustDelay(long) is
the way to go here.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
Felix Schumacher <fe...@internetallee.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
Target Milestone|--- |JMETER_5.0
--- Comment #13 from Felix Schumacher <fe...@internetallee.de> ---
@orimarko can you test, whether the changes are really fixing your problems?
Date: Wed Aug 22 15:29:50 2018
New Revision: 1838648
URL: http://svn.apache.org/viewvc?rev=1838648&view=rev
Log:
Take scheduler into account when calcuting delay for Synchronizing Timer
Bugzilla Id: 62637
Added:
jmeter/trunk/test/src/org/apache/jmeter/timers/SyncTimerSpec.groovy (with
props)
Modified:
jmeter/trunk/src/components/org/apache/jmeter/timers/SyncTimer.java
jmeter/trunk/xdocs/changes.xml
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
--- Comment #9 from Vladimir Sitnikov <si...@gmail.com> ---
Thanks for pushing it forward.
The use of adjustDelay makes code cleaner in my point of view (and it confines
all the black magic to a single method).
If you change "if (timeoutInMs == 0) {" to "if (timeoutInMs <= 0) {", it makes
"Negative value for timeout" branch obsolete.
So I would prefer either remove the else branch or keep "timeoutInMs == 0"
>if (initialDelay > endTime - now) {
It might make sense to add a comment that explains that "now + initialDelay >
endTime" does not work for initialDelay==Long.MAX_VALUE (so others won't
re-introduce the bug)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |FixedInTrunk
CC| |p.mouawad@ubik-ingenierie.c
| |om
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
Felix Schumacher <fe...@internetallee.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #36103|0 |1
is obsolete| |
--- Comment #11 from Felix Schumacher <fe...@internetallee.de> ---
Created attachment 36106
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36106&action=edit
Allow Long.MAX_VALUE as value for initialDelay in TimerService
Add a unit test to help future developers from mistakenly re-introducing the
overflow. (I think that is better than a comment ;)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
Felix Schumacher <fe...@internetallee.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #36102|0 |1
is obsolete| |
--- Comment #10 from Felix Schumacher <fe...@internetallee.de> ---
Created attachment 36105
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36105&action=edit
Use endTime of JMeterThread for SyncTimer
Only use first branch, if timeoutInMs == 0 (as noted by Vladimir, again :)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
Felix Schumacher <fe...@internetallee.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #36101|0 |1
is obsolete| |
--- Comment #7 from Felix Schumacher <fe...@internetallee.de> ---
Created attachment 36102
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36102&action=edit
Use endTime of JMeterThread for SyncTimer
Use TimerService#adjustDelay as pointed out by Vladimir.
Note that Long.MAX_VALUE will not work without the next patch as value for
adjustDelay.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
--- Comment #12 from Felix Schumacher <fe...@internetallee.de> ---
Date: Wed Aug 22 15:25:41 2018
New Revision: 1838646
URL: http://svn.apache.org/viewvc?rev=1838646&view=rev
Log:
Part of 62637 Avoid Integer overrun when dealing with very large values in
TimerService#adjustDelay
Bugzilla 62637
Added:
jmeter/trunk/test/src/org/apache/jmeter/timers/TimerServiceTest.java
(with props)
Modified:
jmeter/trunk/src/core/org/apache/jmeter/timers/TimerService.java
jmeter/trunk/xdocs/changes.xml
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 62637] Synchronizing Timer set by threads is stuck when adding
duration
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62637
--- Comment #4 from Felix Schumacher <fe...@internetallee.de> ---
(In reply to Vladimir Sitnikov from comment #3)
> Ah, https://bz.apache.org/bugzilla/show_bug.cgi?id=60049 did not add
> "interrupt", but it just added a cap on maximum delay (to ensure the delay
> is within the test duration).
>
>
> However, there's long endTime = getThreadContext().getThread().getEndTime(),
> so there's still no need in new interface.
Great, I will amend the patch.
--
You are receiving this mail because:
You are the assignee for the bug.