Suspected memory leak

[bilsch-nice]

Suspected memory leak

[FSchumacher]

You should not construct dynamic JSR 223 snippets within your tests, as those will end up in the metaspace.

What you did is, for every sample, you created a new text snippet. That snippet gets compiled into a groovy (class), which ends up in the metaspace.

The templating syntax ${...} should be avoided by all means in (groovy) JSR 223 scripts. Those parts get replaced while JMeter runs the test. As you are generating random text for each call of the sampler, you will get a unique script.
Another reason to not use templating inside groovy scripts, is that there is often a faster alternative. For your example, I believe the following snippet would be equivalent:

import org.apache.commons.lang3.RandomStringUtils;

String randomString = RandomStringUtils.randomAlphanumeric(16)
String hexString = randomString.getBytes("UTF-8").encodeHex();

vars.put("trace_id", hexString);

Another possibility would be to work with arguments and place the random bits with the templating syntax into the parameters section of the JSR 223 sampler (or pre-processor).

[KingRabbid]

Hi,

OOM aside, why do you need that complicated piece of code? You run a JSR223PreProcessor so you have full access to Groovy runtime, there's no need to call the ${__groovy()} function inside again.

I guess you need a unique value to use as trace identifier, this should be enough:
vars.put("trace_id", UUID.randomUUID().toString())
Sample output: ebd7bca8-c365-3b64-8157-11b165df0341

[bilsch-nice]

Hi,

OOM aside, why do you need that complicated piece of code? You run a JSR223PreProcessor so you have full access to Groovy runtime, there's no need to call the ${__groovy()} function inside again.

I guess you need a unique value to use as trace identifier, this should be enough: vars.put("trace_id", UUID.randomUUID().toString()) Sample output: ebd7bca8-c365-3b64-8157-11b165df0341

The format of the trace_id needs to conform to the opentelemetry spec. Its a 32-byte hex string.

I actually switched over to gatling for this load test script. Generating the traceid in scala code directly and its proven stable so I've moved on from this.

Would be interested in someone else being able to re-create the scenario. If I understand the problem just adding the preprocessor with the code I included in this issue should be enough to replicate - don't even need to reference the variable I suspect.