Test ends before all threadgroups started

[asfimport]

Christoph (Bug 43007):
We have a test that consists of several threadgroups. The first testgroup
contains an "if-controller", that can disable all requests in that testgroup.
in some cases, the test ends and all other testgroups are not started.

Severity: normal
OS: Windows XP

[asfimport]

Christoph (migrated from Bugzilla):
you can test this bug with this testplan.
all threadgroups are disabled by if-controller except the last one, that should
make a request to google. as you can see, in most cases this request is not
executed.

Created attachment bug.jmx: Test this bug with this testplan

[asfimport]

Sebb (migrated from Bugzilla):
Works fine for me.

Please attach the jmeter log file for a failing run.

[asfimport]

Christoph (migrated from Bugzilla):
this logfile was generated for a run where request in testgroup "test15" was
not executed.
this problem does not show up for every run, i have tested this script on 3
different windows-machines and in 3 of 10 times "test15" is not sampled.

Created attachment jmeter.log: jmeter log file for failed run

[asfimport]

Sebb (migrated from Bugzilla):
The jmeter log is missing some information.

One difference from my tests is that the log contains messages like:

INFO - jmeter.engine.StandardJMeterEngine: Ending thread 0

which I don't understand.

However the thread groups "Test15" does start and stop, so I suggest you add a
dummy sampler to the thread group before and after the If Controller.

Also, it's very confusing to have multiple thread groups all called "Test14" -
please remove/rename those.

How are you running the test? GUI? non-GUI? Remote?

[asfimport]

Christoph (migrated from Bugzilla):

• renamed all threadgroups
• all threadgroups disabled by if-controller except last one (test25)
• removed if-controller from last threadgroup

Created attachment test.jmx: new testplan for testing this bug

[asfimport]

Christoph (migrated from Bugzilla):
log file shows 2 runs, first run was not ok (threadgroup "test25" not
processed), second run was ok.

i'm running the test in GUI mode, but this problem does also occur in
non-GUI-mode.

Created attachment jmeter.log: new jmeter.log file

[asfimport]

Sebb (migrated from Bugzilla):
Thanks for the updated test plan and log file.

However the logs are incomplete - I need the whole of each log file please.

[asfimport]

Christoph (migrated from Bugzilla):
Created attachment jmeter.log: logfile showing successful run

[asfimport]

Christoph (migrated from Bugzilla):
i openend the testplan more than 10 times and the problem did not show up.
in this logfile, the first run is OK, only in the second run the request in
testgroup "test25" was not sampled.

the problem is mostly occuring if a test is started more than 1 times. on my
PC, in most times the first run (after starting jmeter) is OK, and in the next
10 runs about 7 runs are failing.

Created attachment jmeter.log: logfile showing failed run

[asfimport]

Sebb (migrated from Bugzilla):
Changed the version to 2.2, as that is what the log files show.

This at least explains the messages:

INFO - jmeter.engine.StandardJMeterEngine: Ending thread 0

which were fixed in 2.3RC3.

[asfimport]

Sebb (migrated from Bugzilla):
Finally found the problem: when a thread group stops, the code checks to see
if there were any other groups left.

Sometimes it would happen that all the earlier thread groups would complete
before the next group was even created, so the count would be zero.

This is only likely to happen if the thread groups complete very quickly - as
is the case here.

Fixed in SVN r564931.

[asfimport]

Christoph (migrated from Bugzilla):
thanks a lot for the bugfix!
i've tested this testplan also with R2.3, the problem is also occurring here
(should be fixed here too).

cheers,
christoph

[asfimport]

Sebb (migrated from Bugzilla):
The fix will be in the next release, probably 2.3 GA.

In the meantime, any nightly build after r564931 will have the fix if you want
to try and break that ;-)

I forgot to say this earlier, so thanks for reporting the issue, and for
providing the test cases/logs.