random function generate multiple value when access more than once

[mehrdad2000]

Hi
I'm using jmeter 5.6.2 with iso8583 plugin.

try to use this groovy script but seems jmeter create two value for field 11 that use random function ${__Random(111111111111,999999999999,)}!

seems random function generate multiple value when access more than once!

if (!vars.getObject('addMac')) {
    def macKey = new javax.crypto.spec.SecretKeySpec(
        org.jpos.iso.ISOUtil.hex2byte('1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A'), 'ISO9797ALG3')
    def ssm = new nz.co.breakpoint.jmeter.iso8583.SecurityModule()

    vars.putObject('addMac', { sampler ->
        def msg = sampler.getRequest()
        def p = msg.getPackager()

        def bytes = [0,2,11,12,47].collect {
            p.getFieldPackager(it).pack(msg.getComponent(it))
        }.flatten() as byte[]

        sampler.addField('64', ssm.generateMAC(bytes, macKey, macKey.getAlgorithm()))
    })
}
vars.getObject('addMac').call(sampler)

FYI: main issue report here and developer of this plugin told me this issue related to jmeter 5.6.2!

Would you please fix this issue?
Any idea?
Thanks

[tilln]

This appears to be caused by #5788 in version 5.6
Setting the property function.cache.per.iteration=true reverts to the old behaviour.

[vlsi]

seems random function generate multiple value when access more than once!

That seems about right for a random function, doesn't it?

[mehrdad2000]

@vlsi in this case we need to use that variable for generate mac.
So I turn cache on as @tilln mentioned.

[vlsi]

I would say function.cache.per.iteration is a wrong approach to handle things. At the same time I don't understand the problem you have.

[mehrdad2000]

@vlsi the main problem is generate random number and use that number to generate Mac.
Finally put the generated mac into the message field and send.

[vlsi]

Could you share a reproducer script, expected and the actual output?

[tilln]

Here is a script: jmeter-regression-v5.6.jmx.txt

Expected would be that the SampleResult's label and URL match as they do with the caching.

JTL output from v5.5

timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,URL,Latency,IdleTime,Connect
1713123663745,963,GET https://www.google.com/search?q=AECC,200,OK,Thread Group 1-1,text,true,,115147,130,1,1,https://www.google.com/search?q=AECC,658,0,457

vs. 5.6.3

timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,URL,Latency,IdleTime,Connect
1713123690243,961,GET https://www.google.com/search?q=EEDB,200,OK,Thread Group 1-1,text,true,,90089,130,1,1,https://www.google.com/search?q=EABD,711,0,493

This might be an unintended consequence of the caching removal, but I think this is not unreasonable to expect that the sampler properties are evaluated once.
I have written a lot of scripts with random functions or other, non-idempotent functions in sampler payloads in conjunction with some sort of access to sampler properties (via Preprocessors or plugins such as the one the author is using), that break after upgrading to v5.6.

[tilln]

At the same time I don't understand the problem you have.

The problem the author has is that the Random function is evaluated once when accessing the sampler payload for generating the MAC (in his JSR223 Preprocessor or likewise in a plugin's preprocessor) and then again when the sampler samples, resulting in a MAC mismatch.