How to Pass a Variable From One Thread Group to Another in JMeter

1. Introduction

In this quick tutorial, we’ll explore how to share variables between JMeter Thread Groups. This is a common need when one group performs a setup task, like authentication or data preparation, and another group consumes the result.

Since JMeter variables are local to each thread, we’ll explore some techniques for passing data between groups in simple and more robust ways.

2. Scenario and Setup

Our test scenario involves two actions:

• POST some data to an endpoint, which returns a UUID
• Use that UUID in a subsequent GET request to retrieve the posted data

We’ll split these actions across two thread groups:

• The first thread group handles the POST request and stores the returned UUID
• The second thread group performs the GET request using the stored UUID

2.1. Creating a Setup Thread Group

Because JMeter runs thread groups concurrently by default, we’ll use a special thread group type to control execution order.

Let’s right-click the Test Plan, and then choose:

Add -> Threads (Users) -> setUp Thread Group

This ensures the setup logic (that is, the POST request and saving the variable) is executed before other thread groups begin.

2.2. Posting Random Data

To POST random test data, we’ll use a simple HTTP Request element with ${__RandomString(5)}:

In every approach, we’ll use a JSR223 PostProcessor element after the POST request to retrieve and save the response text in a shareable way across thread groups. Then, we’ll use a JSR223 PreProcessor before the GET request to retrieve that saved response value and use it in the request. Most importantly, we’ll use Java as the language for the scripts.

2.3. Understanding JMeter Context Variables

We can access built-in scripting variables when working with JMeter components like Samplers, PreProcessors, or PostProcessors. For this tutorial, we’ll use prev, props, and vars:

• prev: The SampleResult of the previous sampler, typically an HTTP request, used to extract the response body and status code
• props: The JMeter Properties object, which is global across the entire test and useful for sharing values between threads or thread groups
• vars: The JMeter variables for the current thread, which are useful for reading or writing values (accessible via ${} syntax) in components

3. Using JMeter Properties

The simplest method for sharing values across thread groups is through props. These are shared across the entire test execution and persist throughout executions:

String response = prev.getResponseDataAsString();
props.put("uuid", response);

Note that the props variable is an Object map, so we’re not limited to String values. Then, in another thread group, we can retrieve it and store it in vars to make it available to other elements:

String uuid = props.get("uuid");
vars.put("uuid", uuid);

Once stored in vars, we use the ${uuid} syntax in HTTP requests or other test elements:

Properties are shared across threads and thread groups, which works well for single values or when the setup thread group uses only one thread. Let’s see other approaches for when more complex coordination is required.

4. Using the bsh.shared Namespace

A more flexible (but older) option is to use the BeanShell shared namespace, bsh.shared, which acts like a global object store shared among all BeanShell scripts across the test plan. This technique is useful when sharing more complex data structures, like queues or maps.

Let’s create a new variable, uuidQueue. We’ll check if it’s defined by comparing it to void, then initialize it as a LinkedList:

String response = prev.getResponseDataAsString();

if (bsh.shared.uuidQueue == void) {
    bsh.shared.uuidQueue = new LinkedList();
}

We can then use it normally to add items:

bsh.shared.uuidQueue.add(response);

Conversely, to retrieve it in another thread group:

String uuid = bsh.shared.uuidQueue.poll();
vars.put("uuid", uuid);

As a caveat, BeanShell is considered slower and less safe than Groovy or pure Java scripts.

5. Writing to and Reading From a File

When we need complete visibility or persistence between runs, file-based communication is another viable option, albeit more verbose. In this example, we’ll use the ctx.getThreadNum() to create separate files based on the thread number:

String response = prev.getResponseDataAsString();
File file = new File("/tmp/shared-file" + ctx.getThreadNum() + ".txt");

Then, the standard boilerplate for writing files is:

try {
    FileWriter writer = new FileWriter(file);
    writer.write(response);
    writer.close();
} catch (IOException e) {
    log.error("Failed to write file", e);
}

Ultimately, we read it back:

File file = new File("/tmp/shared-file" + ctx.getThreadNum() + ".txt");

try {
    Scanner reader = new Scanner(file);
    String uuid = reader.hasNextLine() ? reader.nextLine().trim() : "";
    reader.close();

    vars.put("uuid", uuid);
} catch (IOException e) {
    log.error("Failed to read file", e);
}

Advantages:

• Good for debugging, persistence, or manual manipulation between runs
• Safer for larger data sets or bulk exports

Downsides:

• Slower due to disk I/O
• Must manage file cleanup and thread-specific paths carefully

6. Conclusion

In this article, we examined several techniques for passing data between thread groups in JMeter. Starting with JMeter Properties is suitable for simple, single-value data sharing. For advanced scenarios, like per-thread queues or persistent test artifacts, bsh.shared helps despite being older. Finally, we saw a file-based approach for greater flexibility.