Bug 53501 - Synchronization timer blocks test end.
Synchronization timer blocks test end.
Status: REOPENED
Product: JMeter
Classification: Unclassified
Component: Main
2.7
PC Linux
: P2 normal (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on: 53418
Blocks:
  Show dependency tree
 
Reported: 2012-07-03 14:51 UTC by Andres Romero
Modified: 2014-02-04 14:32 UTC (History)
2 users (show)



Attachments
Test Plan showing the synchronization timer issue. (3.84 KB, application/octet-stream)
2012-07-03 14:51 UTC, Andres Romero
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andres Romero 2012-07-03 14:51:35 UTC
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.
Comment 1 Philippe Mouawad 2012-07-08 13:45:20 UTC
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
Comment 2 Andres Romero 2012-07-08 14:17:14 UTC
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
Comment 3 Philippe Mouawad 2012-07-08 14:27:19 UTC
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 ?
Comment 4 Andres Romero 2012-07-08 16:27:24 UTC
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.
Comment 5 Philippe Mouawad 2012-08-20 19:53:42 UTC
Issue has been fixed by sebb within work on issue 53418.
Would it be possible for you to check on nightly build:
- http://ci.apache.org/projects/jmeter/nightlies/
Comment 6 Vladimir Sitnikov 2013-05-12 10:58:54 UTC
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
Comment 7 Gaël G. 2014-02-04 13:05:35 UTC
Is there any workaround to this bug ? It's a major problem for one of the projects I work on.
Comment 8 Sebb 2014-02-04 14:32:31 UTC
(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