Bug 45703

Summary:	Synchronizing Timer
Product:	JMeter - Now in Github	Reporter:	JingFeng Zhu <zhujf>
Component:	HTTP	Assignee:	JMeter issues mailing list <issues>
Status:	RESOLVED FIXED
Severity:	normal	CC:	iblavins, jens_0
Priority:	P2
Version:	2.4
Target Milestone:	---
Hardware:	PC
OS:	Windows XP

Description JingFeng Zhu 2008-08-28 03:05:42 UTC

When I try to request with 20 threads on the same time, I use the Synchronizing Timer and loop the request.
--If the request is slow, finished successfully.
--Bug if the requuest is quick, all of the requests is stoped all along, but the threads still exist.

Comment 1 Ian Blavins 2008-09-13 01:49:59 UTC

(In reply to comment #0)
> When I try to request with 20 threads on the same time, I use the Synchronizing
> Timer and loop the request.
> --If the request is slow, finished successfully.
> --Bug if the requuest is quick, all of the requests is stoped all along, but
> the threads still exist.

I concur there is a problem here. 

With a very simple test plan (the skeleton of a test plan in which all 
users initialise and then synchronize before proceeding):

UDV threadCount = 5, iterationCount = 12
Threadgroup (${iterationCount}, ${threadCount)}
Synchronize (${threadCount}}
Java sampler to write to log

the test gives unpredictable results - in different runs I've seen the test hang without doing any executions, do 25 executions, do 35 executions etc. If I remove the synchronisation controller I reliably get 60 executions as expected.

Comment 2 Sebb 2008-10-05 04:24:20 UTC

I don't have any problems with the Synch Timer.

What OS and JVM are you using?
Are you experiencing the problem in GUI, non-GUI or client-server modes?

Comment 3 jens_0 2010-10-20 06:05:28 UTC

The synchronizing timer has the following problems:

-It checks whether JMeterContextService.getNumberOfThreads number of threads are waiting. If a ramp up period was chosen, getNumberOfThreads returns a lower number than the expected number of total threads. Better would be to use getTotalThreads()

-TimerCounter is never reset to 0, meaning that later test runs never sync.

-If multiple thread groups are used in a test, getNumberOfThreads returns the number of threads of all Thread Groups, the synchronizing timer is however local to one thread group and therefore does not reach the number of threads.

Comment 4 Sebb 2010-10-20 06:32:57 UTC

I agree that the counter ought to be reset. 

I'm not so sure that waiting for total activeThreads is the correct behaviour. 

If there is a single thread-group, this would prevent the timer from being used to wait for all the threads to start. I think it would be better to use the total number of threads in the thread group.

Comment 5 Sebb 2010-10-20 20:52:41 UTC

URL: http://svn.apache.org/viewvc?rev=1025799&view=rev
Log:
Bug 45703 - Synchronizing Timer

Modified:
   jakarta/jmeter/trunk/src/components/org/apache/jmeter/timers/SyncTimer.java
   jakarta/jmeter/trunk/xdocs/changes.xml

Will be in nightly builds from r1025799

Comment 6 The ASF infrastructure team 2022-09-24 20:37:42 UTC

This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2148