In this blog post we’re going to take a look at the Inter-Thread Communication plugin. This is an interesting plugin that expands Apache JMeter™’s default functionality by enabling managing data between different thread groups. With an Inter-Thread Communication PostProcessor, an Inter-Thread Communication PreProcessor and fifoPut, fifoGet, fifoPop and fifoSize functions, we can synchronize separate thread groups in JMeter. This is useful for scenarios where we need to share access tokens/cookies between thread groups, implement asynchronous downloads and much more.

• The Inter-Thread Communication PostProcessor puts an item into the queue;
• The Inter-Thread Communication PreProcessor reads an item and removes it from the queue;
• The fifoPut puts an item into the queue;
• The fifoGet reads an item from the queue without removing it;
• The fifoPop reads an item and removes it from the queue;
• The fifoSize returns the number of items in the queue.

In addition to removing/not removing items from a queue, another difference between fifoGet and fifoPop is that fifoGet doesn’t wait for data in the queue and will return an empty string if no data is present. fifoPop waits until a thread puts some data into the queue.

The official page of the Inter-Thread Communication plugin can be found here. On the page we can find helpful information and download the plugin. If you need help with installing plugins you can find that information here: How to Install the JMeter Plugins Manager.

We will create a simple JMeter script to demo the Inter-Thread Communication plugin. I have chosen the BlazeDemo website to create our load script and run tests. This is a demo website that allows us to search flights. We will create a demo script with two Thread Groups. The script will collect departure and destination cities in one Thread Group and pass this information to another Thread Group, by using the Inter-Thread Communication plugin components.

Let’s create our script!

1. Add a Thread Group to the Test plan.

Test plan -> Add -> Thread (Users) -> Thread Group

Change the name of the Thread Group to ‘First Thread Group’.

This Thread Group will be used for collecting information.

2. Add an HTTP Request, which opens the Blazedemo website.

First Thread Group -> Add -> Sampler -> HTTP Request

Fill in the following values:

• Name: Blazedemo
• Protocol: http
• Server name or IP: www.blazedemo.com

This sampler makes a request to the landing page of the BlazeDemo website. This page contains two selectors with departure and destination cities respectively.

3. Add an XPath Extractor to grab a random departure city.

Blazedemo -> Add -> Post Processors -> XPath Extractor

Enter the following values:

• Name: Departure XPath Extractor
• Use Tidy: Yes
• Quiet: Yes
• Name of created variable: departure_city
• XPath query: //select[@name='fromPort']/option
• Match No.: 0
• Default Value: ERROR

The Xpath Extractor will extract the name of a random departure city from the proper selector and store it in the ‘departure_city’ variable.

4. Add an Inter-Thread Communication PostProcessor.

Blazedemo -> Add -> Post Processors -> jp@gc - Inter-Thread Communication PostProcessor

Type the following values:

• FIFO Queue Name to Put Data Into: departure_queue
• Value to Put: ${departure_city}

The Inter-Thread Communication PostProcessor will take the value from the departure_city variable and put it in the departure_queue queue.

5. Add another Thread Group to the Test plan.

Test plan -> Add -> Thread (Users) -> Thread Group

Rename this Thread Group to ‘Second Thread Group’.

This Thread Group will be used to accept data from the First Thread Group.

6. Add a Dummy Sampler.

Second Thread Group -> Add -> Sampler -> jp@gc - Dummy Sampler

This sampler will be used to present the accepted values.

7. Add an Inter-Thread Communication PreProcessor.

Dummy Sampler -> Add -> Pre Processors -> jp@gc - Inter-Thread Communication PreProcessor

Fill in the following values:

• FIFO Queue Name to Get Data Into: departure_queue
• Variable Name to Store Data: departure_data

This PreProcessor will take the first value from the departure_queue queue and save it to the departure_data JMeter variable.

8. Now it is time to read a value from this variable.

Change the default value of Request Data to the ‘Departure city = ${departure_data}’.

9. Add a View Results Tree listener to see the results of the tests.

Test Plan -> Add -> Listener -> View Results Tree

This listener will collect requests from both Thread Groups.

10. Run the script.

The test passed! The departure XPath Extractor took the value “São Paolo”. The Inter-Thread Communication PostProcessor put it in the departure_queue queue. The Inter-Thread Communication PreProcessor got the value from the departure_queue queue in another Thread group. The Dummy Sampler showed “São Paolo” in the Request tab.

Great! We took a look at passing information from one thread to another with the Inter-Thread Communication PostProcessor and PreProcessor.

But there is another way to do it! For an alternative approach we will use functions. Functions can be used for any type of JMeter element that enables writing script. Let’s look at an example.

11. Add an XPath Extractor to grab a random destination city.

Blazedemo -> Add -> Post Processors -> XPath Extractor

Enter the following values:

• Name: Destination XPath Extractor
• Use Tidy: Yes
• Quiet: Yes
• Name of created variable: destination_city
• XPath query: //select[@name='toPort']/option
• Match No.: 0
• Default Value: ERROR

This XPath Extractor will extract the name of random destination city and store it in the ‘destination_city’ variable.

12. Add a Response Assertion.

Fill in the following values:

• Patterns Matching Rules: Equals Not
• Patterns to Test: ${__fifoPut(destination_queue,${destination_city})}

This is kind of a trick. This assertion will not fail the Blazedemo request, but will execute the fifoPut function instead. So the destination_city value will be put in the destination_queue queue.

13. Update the Dummy Sampler to check how the functions work.

Change the default value of the Response Data:
Size of queue before get = ${__fifoSize(destination_queue)}
Get destination = ${__fifoGet(destination_queue,destination_data)}
Size of queue after get = ${__fifoSize(destination_queue)}
Pop destination = ${__fifoPop(destination_queue,destination_data)}
Size of queue before pop = ${__fifoSize(destination_queue)}

fifoSize will return the size of the destination_queue queue. fifoGet will read the value from the destination_queue queue, store it to the destination_data variable and return it as a function execution result. fifoPop will get the value from the destination_queue queue, put it to the destination_data variable and return it as a function execution result.

14. Run the script again!

We can see that the size of queue wasn’t changed with the fifoGet function, but the size of queue was decreased with the fifoPop function. It looks like the fifoGet and fifoPut functions returned the proper values. Test passed!

So! In this blog post we took a look at the Inter-Thread Communication plugin as well as all of its elements and functions. Feel free to use it in your advanced scripts for your own purposes. I hope this blog post will help!

Running Your JMeter Test in BlazeMeter

After setting up your JMeter script, run it in BlazeMeter. You will be able to massively scale your test, get advanced reporting and collaborate on tests and reports.

Try out BlazeMeter by putting your URL in the box below, and your test will start in minutes. Or, request a performance testing demo from one of our engineers.