Bug 48943

Changing priority since this is a very important problem for our project.

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.

Hello,
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)) {
                iter.remove();
                clearTemporary(prop);
            }


isTemporary calls :
temporaryProperties.contains(property);

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.

Regards
Philippe Mouawad

Created attachment 27468 [details]
Patch to FunctionProperty#hashCode

Patch as described in previous comment

I think Bug should be renamed, FunctionProperty#function is reexecuted abusively by hashCode if inside a loop controller.

Created attachment 27469 [details]
Values.txt that work

Initial Values.txt makes parse error failures.
This one is OK.

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.

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:

System.out.println("${__counter(FALSE)}");

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.

More general subject

Fixed in SVN

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

Modified:
   jakarta/jmeter/trunk/bin/testfiles/BatchTestLocal.csv
   jakarta/jmeter/trunk/bin/testfiles/BatchTestLocal.jmx
   jakarta/jmeter/trunk/bin/testfiles/BatchTestLocal.xml
   jakarta/jmeter/trunk/src/core/org/apache/jmeter/testelement/property/AbstractProperty.java
   jakarta/jmeter/trunk/xdocs/changes.xml

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