Bug 48943 - Functions are invoked additional times when used in combination with a Config Element
Summary: Functions are invoked additional times when used in combination with a Config...
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 2.3.4
Hardware: All All
: P1 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
Depends on:
Reported: 2010-03-19 08:48 UTC by Radu Leterna
Modified: 2011-09-14 13:18 UTC (History)
2 users (show)

JMeter Test Plan used to reproduce this bug. (1.44 KB, application/zip)
2010-03-19 08:48 UTC, Radu Leterna
Patch to FunctionProperty#hashCode (637 bytes, patch)
2011-09-07 17:18 UTC, Philippe Mouawad
Details | Diff
Values.txt that work (238 bytes, text/plain)
2011-09-07 18:59 UTC, Philippe Mouawad

Note You need to log in before you can comment on or make changes to this bug.
Description Radu Leterna 2010-03-19 08:48:43 UTC
Created attachment 25151 [details]
JMeter Test Plan used to reproduce this bug.

1. Create a new JMeter Test Plan

2. Add a Thread Group and set:
Number of Threads=1
Loop Count=5

3. Add a Bean Shell sampler to your Thread Group and in the "Script" section add the following two lines:
System.out.println("___ " + "${readValues}" + "___ ")

4. Add a Simple Config Element to your Thread Group.

5. Save the Test Plan in the {JMETER_HOME}/bin folder.

6. Create a txt file called "Values.txt" in the {JMETER_HOME}/bin folder.

7. Fill in at least 10 lines in the file with some values (E.g. : numbers from 0 to 9).

8. Save the text file and close it.

9. Open your previous created JMeter test plan and run the test.

Expected result:
On the command window that opens with JMeter you can see the output of the test. We are expecting to see the first 5 values (5 lines) from the txt file.

Actual result:
After JMeter reads a line from the file, it will skip the next line. So, you will have displayed the lines 1,3,5,7,9.
If you disable the Simple Config Element and run the test again, you will notice that the behavior is the expected one.
Also, this only reproduces when using loops. If you put, for example, 5 threads and 1 loop, the values will be correctly displayed.

I attached to this bug a test plan and a data file that can be used to reproduce this bug, so you don't have to build your test again. Just unzip the files in the {JMETER_HOME}/bin folder and run the test.
Comment 1 Radu Leterna 2010-04-08 08:42:00 UTC
Changing priority since this is a very important problem for our project.
Comment 2 Sebb 2010-04-08 12:13:57 UTC
Sorry, but the priority is used to indicate the effect of the bug on the general behaviour of JMeter.

I don't know how long it will take to fix this, so I suggest you try using the CSV Dataset Config element to try reading the file.
Comment 3 Philippe Mouawad 2011-09-07 17:13:17 UTC
The issue occurs because ConfigTestElement ends up setting temporaryProperties in AbstractTestElement#temporaryProperties which is not null anymore.

Then during the call of JMeterThread#notifyTestListeners, we end up
 calling recoverRunningVersion on each TestElement.
This method does this:
=> if (isTemporary(prop)) {

isTemporary calls :

This one ends up calling FunctionProperty#hashCode which call super.hashCode => 
AbstractProperty#hashCode which call getStringValue() which 
 executes the BeanShell script again through this condition:
if (iter > testIteration || cacheValue == null) {
            testIteration = iter;
            cacheValue = function.execute();

=> Which leads to the issue.
execute is called outside of Sampling.

So this issue could occur as long as setTemporary is called on AbstractTestElement, so it is a big issue I think.

Now for the fix, I don't have the full code history, but I think that fix should be in:
- hashCode 

I find it strange that equals and hashCode does not work on same datas.

Please find a patch but have a critical review of it.
I tested on submitted case and it works.

Philippe Mouawad
Comment 4 Philippe Mouawad 2011-09-07 17:18:00 UTC
Created attachment 27468 [details]
Patch to FunctionProperty#hashCode

Patch as described in previous comment
Comment 5 Philippe Mouawad 2011-09-07 17:23:29 UTC
I think Bug should be renamed, FunctionProperty#function is reexecuted abusively by hashCode if inside a loop controller.
Comment 6 Philippe Mouawad 2011-09-07 18:59:21 UTC
Created attachment 27469 [details]
Values.txt that work

Initial Values.txt makes parse error failures.
This one is OK.
Comment 7 Sebb 2011-09-07 23:41:05 UTC
Thanks for the analysis; looks good.

A different approach might be to change the parent hashCode() and equals() to use getObjectValue() instead, as that does not execute functions.

Indeed, does it make sense to use a hash and equals methods that can vary between invocations for the same object?

Or possibly even drop the methods entirely and rely on Object equals and hashCode?

Need to do some testing to see whether distinct Property objects need to compare equal.
Comment 8 Sebb 2011-09-14 09:50:33 UTC
The unit tests still work if equals and hashCode in AbstractProperty are changed to use getObjectValue(), and that also fixes the issue whereby values are skipped because the function is evaluated when it should not be.

Using the object value also avoids the string conversions that are otherwise done.

So although your fix works, I think it would be better to fix the parent class.

BTW, a simpler test is to just use:

Comment 9 Sebb 2011-09-14 11:11:32 UTC
Curiously, I have so far been unable to provoke the issue with anything but the BeanShell sampler.

Even when this is fixed, however, using a function call in a test element Name field is likely to cause spurious function evaluations. Not sure why this is.
Comment 10 Sebb 2011-09-14 13:10:29 UTC
More general subject
Comment 11 Sebb 2011-09-14 13:18:33 UTC
Fixed in SVN

URL: http://svn.apache.org/viewvc?rev=1170595&view=rev
Bug 48943 - Functions are invoked additional times when used in combination with a Config Element