Created attachment 36977 [details] Example Testplan to verify the bug I encountered the following issue while working with JMeter: If parameters of a ThreadGroup are changed in a preprocessor, e.g. Num of Threads, Loop Count or Duration, then the ThreadGroup is ran with the values present BEFORE changing them in a ThreadGroup. The following setup can be used to reproduce: Testplan * JSR223 Preprocessor (Groovy) * props.setProperty("threads", "1") * Summary Group * Thread Group(Number of threads: ${__P(threads,10)} ) * JSR223 PreProcessor (Groovy) * log.info("==========================A THREAD WAS RUN") * Property Display Following need to be taken to reproduce the issue: 1) Create the setup 2) Close and Re-Open JMeter 3) Open Testplan 4) Verify that threads is not present in PropertyDisplay 5) Execute Testplan 6) Verify that Summary Report shows 10 Samples, Output is seen in log 7) Re-Run the Testplan 8) Verify that Summary Report now shows 11 Samples, Output is seen in log I could neither find this behaviour documented nor find a proper workaround for it, so I assume this is unintended behavior.
It's a misunderstanding about how JMeter works. A PreProcessor is a scoped component that only runs if a sampler runs, so it will run only before JSR223 Sampler is run in your case. As a consequence you cannot update Thread Group number of threads from it.
(In reply to Philippe Mouawad from comment #1) > It's a misunderstanding about how JMeter works. > > A PreProcessor is a scoped component that only runs if a sampler runs, so it > will run only before JSR223 Sampler is run in your case. > As a consequence you cannot update Thread Group number of threads from it. So what you're saying is that the first PreProcessor, i.e. the one outside of a ThreadGroup calling props.setProperty(String, String), is only run inside the ThreadGroup instead of outside of it (as the TestPlan would imply)? That makes sense if that's what the JMeter-PreProcessor does conceptually, albeit I'd argue that it is very counterintuitive. A PreProcessor is an element pre-processing things, not necessarily bound to a sampler. Though I suppose I'm arguing semantics now.
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/5228