Created attachment 29025[details]
Test Plan showing the synchronization timer issue.
Hello,
It seems when I add a synchronizing timer, it blocks the test end if it is used in a thread group that stops based on the test duration.
It stops all threads that are not on a wait() command from the synchronization timer, but not those that are. It seems the test end function should have a notify, or a timeout property should be added to the CyclicBarrier so that the user can add a timeout to the timer. As it is, one cannot use it at all during duration tests.
I've attached a small test that shows the issue. Once the 20 seconds are up, the test usually hangs as it cannot properly end the test and the program is stuck forever. I'm using 2.7 r1342410.

Hello,
I investigated this issue.
My idea to fix it is the following:
Add 2 new methods on AbstractThreadGroup:
public void start() => Called when StandardJMeterEngine#startThreadGroup is called just before JMeterThread creation loop. It will notify AbstractThreadGroup that it is started
public void registerStartedThread(JMeterThread jmeterThread, Thread newThread) , which will be called just after Thread creation
public void stop(); => Called when stop or shutdown is called
Then in ThreadGroup, if scheduler mode is on , start will start a Timer that will execute on end of duration or at endTime. This timer will call on each JMeterThread of the Group:
JMeterThread item = entry.getKey();
item.stop(); // set stop flag
item.interrupt(); // interrupt sampler if possible
Thread t = entry.getValue();
if (t != null ) { // Bug 49734
t.interrupt(); // also interrupt JVM thread
}
I will also have to handle premature stops to cancel timerTask.
These changes will impact AbstractThreadGroup which is extended by Plugins (JMETER Plugins @GC for example). But for now they will just have to recompile.
They will also have to call super.start() if they implement method in the future.
It tried it and it fixes the issue but I wanted your ideas on impacts I may not have foreseen.
Regards

Hi,
Well, I managed to fix the issue on my own by adding a timeout to the wait command on the barrier (barrier.await()) in the synchronization timer, and catching the time out exception in the outer call. If you do this with a single property timeout, it shouldn't really affect how the threads must be called, and would deal with the issue at hand. I would just consider taking this path as to not force plugin makers to recompile.
But your method seems to be a bit more broad, targeting the end thread rather than the timer itself. In the regular JMeter implementation the only component that seems to cause this is the synchronization timer, but perhaps you could also achieve it through a beanshell timer, or in another synchronization plugin. Then its an issue on whether the plugin/beanshell timer maker should have to deal with ending threads on timeout or not.
Regards,
Andres

Hello,
Yes my method aims at this because adding a timeout on CyclicBarrier for this would break Sync Timer contract as you will make timer return even if the number of participant is lower than what was set. How would you set this timeout correctly ?

From my understanding, the timeout on the cyclic barrier doesn't return the thread, it throws an exception. So you might make it so it restarts the thread (which would then go back to the timer), or you could change the sync timer contract by adding a box in the GUI for timeout duration, when given 0 it defaults to no time out or something.

Currently (as of git 05f071840c7f6, https://svn.apache.org/repos/asf/jmeter/trunk@1481155) JMeter just calls sleep and it does not check if the "time-after-wakeup" is still in thread schedule.
I do not find interrupts, mentioned in comment #1.
The bug is reproducable with simple Constant Timer
The behaviour is as follows:
1) Set test duration (via threadgroup scheduler) to 1 minute
2) Timer says: "sleep 5 minutes" (e.g. Constant Timer)
3) The thread sleeps, ignoring the scheduler
4) Test finishes only after 5 minutes
Expected behaviours is as follows:
3) Thread terminates, as there is no sense in sleeping
4) Test finishes in 1 minute as per scheduler

(In reply to Vladimir Sitnikov from comment #6)
> Currently (as of git 05f071840c7f6,
> https://svn.apache.org/repos/asf/jmeter/trunk@1481155) JMeter just calls
> sleep and it does not check if the "time-after-wakeup" is still in thread
> schedule.
>
> I do not find interrupts, mentioned in comment #1.
>
> The bug is reproducable with simple Constant Timer
>
> The behaviour is as follows:
> 1) Set test duration (via threadgroup scheduler) to 1 minute
> 2) Timer says: "sleep 5 minutes" (e.g. Constant Timer)
> 3) The thread sleeps, ignoring the scheduler
> 4) Test finishes only after 5 minutes
>
>
> Expected behaviours is as follows:
> 3) Thread terminates, as there is no sense in sleeping
> 4) Test finishes in 1 minute as per scheduler
The scheduler is designed to stop the test once the duration has been reached. It is not designed to interrupt the test. So this test does not show a problem

This is ASF Bugzilla: the Apache Software Foundation bug system. In case
of problems with the functioning of ASF Bugzilla, please contact
bugzilla-admin@apache.org.
Please Note: this e-mail address is only for reporting problems
with ASF Bugzilla. Mail about any other subject will be silently
ignored.