Is there any facility in JMeter already to define code/script based configuration once for threads or thread groups to then use later on? Meaning a single execution is done to dynamically generate the needed test data (and utility methods) at test startup, then this whole config "object" is referenced by threads in thread groups later on during the actual test run.
Browsing over the JMeter docs, I'm not aware if that already exists, or how best to implement this. Basically, in terms of JMeter extensions/plugins, I'm thinking of a config element that's like a static class or singleton, don't want each thread trying to instantiate their own instance. And/or something similar to user defined variables at the test plan root level, only the variable is a Java object/struct rather than simple string (that could be typecasted to int) - or that defining the Java object is a lot of logic that can't simply be done with JMeter functions to then flatten object (serialized) to JSON string. If there already is such facility & best practice, that would be great as I don't want to have to deal with instance checking, synchronization, and thread safety myself unless I have to, when instantiating the globally shared data across threads. Nor do I want each thread to have their own "copy" as that eats up memory/resources as we scale the load up. I'm currently using a Java-based config element based off the CSV Data Set Config (from kafkameter project). Would placing the config element under test plan rather than under a thread group affect how it executes? E.g. execute once and result/output global to all threads, or would it also be executed X times for X threads, being globally used by them all, but not global in the sense of being already executed once with its output readily accessible? This discussion would be with respect to things like config elements, or say pre-processors, in Java, Beanshell, javascript - but in the global execute once context rather than execute per thread, while providing its output (as JMeter variables, etc.) being global to all threads.
