Resolving Parameter Dependency Conflicts within bzm - Parallel Controller

[yanzi feng]

Description​​:

I'm using the bzm - Parallel Controller to execute child elements truly concurrently in JMeter (v5.2+). However, I’ve encountered a fundamental conflict when child samplers have ​​parameter dependencies​​.

Scenario

​​Sampler A​​: Returns a dynamic value (e.g., orderID) in its JSON response.

​​Sampler B​​: Requires orderID from Sampler A as a request parameter.

Problem

Since bzm - Parallel Controller launches all child elements simultaneously:

Sampler B starts execution ​​before​​ Sampler A completes.

The ${orderID} variable (extracted via JSON Extractor from Sampler A) is null or stale when Sampler B runs.

Attempts to add conditional logic (e.g., If Controller + ${JMeterThread.last_sample_ok}) still fail due to race conditions.

Attempted Solutions

Approach Result

JSON Extractor + If Controller Race condition: If check runs before extraction

JSR223 Sampler with sleep() Breaks concurrency, unreliable

Moving Sampler B outside controller Works but loses parallel execution context

Core Question

​​What is the correct pattern to handle inter-sampler parameter dependencies while preserving the bzm - Parallel Controller's concurrent execution behavior?​​

Specific Asks

Does BlazeMeter provide a built-in mechanism for this (e.g., a "sync point" or "barrier")?

Are there plugins/extensions to enable ordered execution for specific dependent samplers within the parallel block?

Is restructuring to use JMeter thread groups the only reliable solution?

​​Environment​​: JMeter 5.2.1, bzm - Parallel Controller 1.0, Java 11.

[Dmitri T]

If you need to execute 2 samplers sequentially - you don't need the Parallel Controller. "Sync point" can be achieved with Synchronizing Timer

Parallelism can be achieved by increasing the number of threads in the Thread Group, Parallel Controller is for edge cases like AJAX requests. 

Make sure that each JMeter thread represents a real user using a real browser and I cannot think of the situation when a real user (or upstream application) is trying to use an orderID which is not yet available because relevant request hasn't finished yet.