The Synchronizing Timer is sometimes launching the first group of users too soon - ie. before the 'Number of Simulated Users to Group by' has been reached. Subsequent groups are fired correctly. This leads to orphan threads and untidy test termination. This is an intermittent scenario, the very simple example below will reproduce this error about 50% of the time. Thread Group - 12 Users, 16 Sec Ramp Up, 1 Iteration --Dummy Sampler ----Synch Timer - Group By 3 (3 is a factor of 12) Approx. half of executions show that the 1st group to get fired off in synch is only composed of 2 users, not 3, which is unpredictable and leaves orphans. The rest of the time each synch group is correctly made up of 3 users and the test completes cleanly. Note. The results are still the same when the Synch timer is not a child of the Dummy Sampler.
Hello Oliver, Van you attach a simple test plan ? Regards Philippe
Created attachment 27937 [details] Simple example test plan | Synchronizing Timer Issue As requested, a simple test plan to replicate the issue.
Added attachment giving an example test plan to replicate the issue.
Note. I just tried reproducing it again and it (annoyingly) is less predictable. For some reason, using a ramp up value of 10 makes it worse and it only seems to happen after I halt the previous execution (CMD + PERIOD). After changing the Rmap Up to 10 seconds and then forcing the previous test to stop it seems to get out of whack and subsequent test runs exhibit the problem. Closing and re-opening the test plan fixes it.
(In reply to comment #4) > Closing and re-opening the test plan fixes it. So are you saying that the problem *only* occurs after a previously stopped test? [This would imply it could not happen in a batch test currently]
Yes, I would agree on that point. When I started with a freshly opened testplan and let the code execute to completion each time the problem did not occur, even over multiple test runs. A cleanly executed batch run would not see this issue so arguably it's not a major issue. Perhaps the presence of this discussion and the link to it in the forum is sufficient to aid anyone that may be searching for the same problem.
(In reply to comment #6) > Yes, I would agree on that point. When I started with a freshly opened testplan > and let the code execute to completion each time the problem did not occur, > even over multiple test runs. OK, useful to know - should help pinpoint the error (which is why I asked). > A cleanly executed batch run would not see this issue so arguably it's not a > major issue. Perhaps the presence of this discussion and the link to it in the > forum is sufficient to aid anyone that may be searching for the same problem. If it can be fixed, it should be, but as there is an easy work round it's not a high priority.
This maybe already fixed if you confirm issue occured on Stopped Test plan. See 51733. Otherwise issue maybe related to missing loop in wait, see 52183. Oliver can you test with nightly build ? Thanks
Ooh, buttons! OK, so I tested this on the nightly build and I can confirm that this problem is not present there. Switching back to 2.5.1 and I can replicate it again. Back to nightly (r1196526) and it goes away. Fixed.
*** This bug has been marked as a duplicate of bug 51733 ***
Thanks Oliver for your tests and time.
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2647