Bug 39509

Confirmed.

A simple workround is to add a dummy sampler before the first Once Only
controller (e.g. Test Action)

Created attachment 20179 [details]
Test plan to show the bug

(In reply to comment #2)
> Created an attachment (id=20179) [edit]
> Test plan to show the bug
> 

I have not been able to make a patch for this problem, mainly because I am not
sure how the correct behaviour would be.
Below is some of my thoughts after working on this, in case someone else are
going to have a look at this bug.

To me, the problem seems to be related to InterleaveController, and the way that
controller increases iteration count, and is being reinitialized.

The OnlyOnceController has an if test : "if (event.getIteration() == 1) {".
But for the InterleaveController, the first "iteration count" is 0, while for
LoopController it is 1, because LoopController overrides "getIterCount".

The "InterleaveController" also never resets the iteration count, so you will
only once get the "iteration count" equal to 1 from a InterleaveController.
The LoopController resets the iteration count, so for each time the loop is
entered, the OnlyOnceController is executed.

Created attachment 20192 [details]
Unit test patch

This patch is meant as a help if someone picks up the work on this bug.
It is a slight restructuring of the current tests, plus a failing test, to
expose the problem reported on the InterleaveController and OnlyOnceController.

Once Only also behaves oddly under a Simple Controller - which one would 
expect to be equivalent to a Loop Controller with count=1 - the OO should run 
each time round the thread group, but it only runs twice.

Test plan to follow.

Created attachment 21233 [details]
Test showing diff behaviour of loop=1 and Simple Cont.

The Once Only Controller needs to to know the state of its parent; this is 
currently achieved via the iterationStart() method.

Unfortunately, not all Controllers actually call this method, and the 
iteration count is not consistent - e.g. Loop Controller goes from 1 to 
loopmax, and repeats when the loop repeats, whereas for the Simple Controller, 
it starts at 0, and increments continually.

The behaviour of the OOC when part of a looping controller seems fairly well-
defined - and it performs as documented. But how should it behave as part of 
other non-looping controllers? This does not seem to be well defined, nor does 
it seem obvious how it should behave...

Created attachment 23634 [details]
Proposal patch

I think that the problem is :
* Thread group and Loop Controller is starting with 'iterCount' at 1 
* but other controllers iterCount is starting with 0

thus, OOC is executed 2 times (iterCount = 0 and = 1) when it is sub element of a controller which isn't a Loop or TG.

The patch modify TG and Loop Controller to start to 0 and changing the "if (event.getIteration() == 1) {" to 0 in OOC.

Created attachment 23635 [details]
Test cases

Element "04 TC Java Request" must be count 1 time
Element "05 L OO Java Request" must be count 5 times 
Element "01 Java Request" must be count 1 time
Element "00 Java Request" must be count 1 time
Element "02 Java Request" must be count 5 times
Element "03 TC Java Request" must be count 1 time
Element "07 IL A Java Request" must be count 1 time
Element "09 L OO Java Request" must be count 5 times
Element "10 Loop Java Request" must be count 20 times
Element "08 IL A Java Request" must be count 3 times

Created attachment 23636 [details]
Capture test plan execution with proposal patch

Thanks, the updated patch fixes the test case so it behaves as expected.

However, some unit tests now fail. It's not yet clear whether the tests are wrong.

I've had second thoughts about the Simple Controller. Rather than being regarded as a Loop count of 1, it should probably be regarded as just a grouping controller which does not affect its children, i.e. they should behave the same whether or not the controller is there. This agrees better with the existing documentation.

At least one of the unit tests is correct in failing - a loop count of 0 should not run any samples, but it runs forever. So I'm afraid the patch needs a bit more work.

Ok, I suppose that is the "-1" start value for iteration number.
I will revise the patch

Created attachment 23737 [details]
Proposal patch

New (replacing) patch to this bug.
Now a "(event.getIteration() == 0)" when the precedent controller aren't a instance of LoopController (including Thread Group) 

All test cases works (ant tests)

Use cases:
When OOC directly attached to TG : 1 iteration
When OCC directly attached to Loop Controller : 1 iteration per loop
When OOC attached to another controller : 1 iteration (scope TG)

Created attachment 23738 [details]
Test Plan to (not) show bug (use cases)

Thanks very much, that last patch seems to have done the trick!

URL: http://svn.apache.org/viewvc?rev=781785&view=rev
Log:
Bug 39509 -  Once-only controller running twice

*** Bug 47647 has been marked as a duplicate of this bug. ***

Author: pmouawad
Date: Tue Oct 24 07:06:54 2017
New Revision: 1813140

URL: http://svn.apache.org/viewvc?rev=1813140&view=rev
Log:
Bug 39509 - Once-only controller running twice
Remove out of date note since this bug fixed the issues.

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