Bug 39509 - Once-only controller running twice
Summary: Once-only controller running twice
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 2.1.1
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
: 47647 (view as bug list)
Depends on:
Reported: 2006-05-08 14:18 UTC by James Rowbotham
Modified: 2017-10-24 07:12 UTC (History)
2 users (show)

Test plan to show the bug (13.41 KB, application/octet-stream)
2007-05-11 06:37 UTC, Alf Hogemark
Unit test patch (12.63 KB, patch)
2007-05-14 06:42 UTC, Alf Hogemark
Details | Diff
Test showing diff behaviour of loop=1 and Simple Cont. (32.14 KB, text/plain)
2007-12-05 15:07 UTC, Sebb
Proposal patch (1.63 KB, patch)
2009-05-10 10:26 UTC, Milamber
Details | Diff
Test cases (50.45 KB, application/octet-stream)
2009-05-10 10:33 UTC, Milamber
Capture test plan execution with proposal patch (112.55 KB, image/png)
2009-05-10 10:34 UTC, Milamber
Proposal patch (917 bytes, patch)
2009-05-31 14:55 UTC, Milamber
Details | Diff
Test Plan to (not) show bug (use cases) (101.27 KB, application/octet-stream)
2009-05-31 14:58 UTC, Milamber

Note You need to log in before you can comment on or make changes to this bug.
Description James Rowbotham 2006-05-08 14:18:21 UTC
The samples within the first Once-only controller contained within an 
Interleave controller run twice. Any following Once-only controllers within 
the Interleave controller correctly run once.

The interleave controller contains 3 once-only controllers, each containing 2 
http requests. These are followed by 7 http requests.

I have also tried this on the 08 May 2006 build and get the same results.
Comment 1 Sebb 2006-05-20 20:31:08 UTC

A simple workround is to add a dummy sampler before the first Once Only
controller (e.g. Test Action)
Comment 2 Alf Hogemark 2007-05-11 06:37:30 UTC
Created attachment 20179 [details]
Test plan to show the bug
Comment 3 Alf Hogemark 2007-05-14 06:39:41 UTC
(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.
Comment 4 Alf Hogemark 2007-05-14 06:42:32 UTC
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.
Comment 5 Sebb 2007-12-05 15:00:03 UTC
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.
Comment 6 Sebb 2007-12-05 15:07:10 UTC
Created attachment 21233 [details]
Test showing diff behaviour of loop=1 and Simple Cont.
Comment 7 Sebb 2007-12-07 16:29:29 UTC
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...
Comment 8 Milamber 2009-05-10 10:26:21 UTC
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.
Comment 9 Milamber 2009-05-10 10:33:51 UTC
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
Comment 10 Milamber 2009-05-10 10:34:54 UTC
Created attachment 23636 [details]
Capture test plan execution with proposal patch
Comment 11 Sebb 2009-05-10 15:36:07 UTC
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.
Comment 12 Sebb 2009-05-10 17:04:44 UTC
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.
Comment 13 Milamber 2009-05-10 23:42:23 UTC
Ok, I suppose that is the "-1" start value for iteration number.
I will revise the patch
Comment 14 Milamber 2009-05-31 14:55:12 UTC
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)
Comment 15 Milamber 2009-05-31 14:58:47 UTC
Created attachment 23738 [details]
Test Plan to (not) show bug (use cases)
Comment 16 Sebb 2009-06-04 09:03:44 UTC
Thanks very much, that last patch seems to have done the trick!

URL: http://svn.apache.org/viewvc?rev=781785&view=rev
Bug 39509 -  Once-only controller running twice
Comment 17 Milamber 2009-08-05 05:47:51 UTC
*** Bug 47647 has been marked as a duplicate of this bug. ***
Comment 18 Philippe Mouawad 2017-10-24 07:12:51 UTC
Author: pmouawad
Date: Tue Oct 24 07:06:54 2017
New Revision: 1813140

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