🥇Queues and JMeter: sharing with Publisher and Subscriber

Hey Habr! This is a sequel to my previous publication, in which I will talk about options for placing messages in queues using JMeter.

We are building a data bus for a large federal company. Various request formats, transformations, intricate routing. For testing, you need to send a lot of messages in the queue. Manually - a pain that not every chiropractor can handle.

Introduction

Although this pain had to put up with at first. It all started with RFHUtil. Powerful, but uncomfortable and scary: You know Rusa.

Indispensable in some cases, but steadily falling in case of active use.
Convenient testing with it is impossible.

With JMeter, everything has become easier. After the first stage with mastering and getting used to, the hope for a happy test dawned.

I actively use JMS Publisher and JMS Subscriber samplers. Unlike JMS Point-to-Point, this couple seemed more convenient to work with. For example, you can specify a variable in Subscriber in JMS Selector, but not in Point-to-Point (or this method is not too obvious).

Sampler preparation

JMS Publisher

Setup-Each Sample. Apache Recommends use this option if queues/topics are defined via variables.
Expiration (ms) = 120000. In case of failure, test requests will disappear from the queue after 2 minutes.
Use non-persistent delivery mode? - true. IBM claimsthat persistent mode ensures that transmitted messages are securely stored in the event of a sudden failure. And faster exchange in non-persistent mode. For test purposes, speed is more important.

In each Publisher, I set the jms property that the Subscriber will use in the JMS Selector. For each submission, a random value is generated in the User Parameters test plan element:

This way you can be sure that the correct message is being read.

The final "blank" of the pre-configured JMS Publisher:

JMS Subscriber

Setup-Each Sample. Well, you understand.
Timeout (ms) = 100000. If the request does not arrive in the queue after 100 seconds of waiting, then something went wrong.
Stop between samples? - true.

JMS Selector - pretty handy thing. Final JMS Subscriber:

How to deal with Cyrillic in transmitted messages. In JMeter, by default, after subtraction, it is displayed crooked. To avoid this and enjoy the great and powerful always and everywhere, you need:

Add a JVM argument to the JMeter "launcher":
```
-Dfile.encoding=UTF-8
```
Add JSR223 PostProcessor to Subscriber with groovy line:
```
prev.setDataEncoding("UTF-8")
```

Text transmission

The laziest option. Suitable for debugging freshly written tests. Or for cases when you need to send at least something small. Choose an option Message source - Textarea and place the body of the message in a text block:

File transfer

The most frequent option. Suitable for most scenarios. Choose an option Message source - From file and specify the path to the message in the field File-Filename:

Transferring a file to a text box

The most versatile option. Suitable for most scenarios + can be used in JMS Point-to-Point which does not have a second send option:

Passing a byte array

The most difficult option. Suitable for checking the infallibly accurate transmission of requests up to a byte, without distortion, sms and perturbation. You won't be able to do this in the default JMeter, here I was clearly told this.

So I had to download sources and modify code JMS subscriber.

Replaced in the method extractContent(..) line:

buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");

to:

byte[] bytes = new byte[(int) bytesMessage.getBodyLength()];
bytesMessage.readBytes(bytes);
try {
	buffer.append(new String(bytes, "UTF-8"));
} catch (UnsupportedEncodingException e) {
	throw new RuntimeException(e);
}

and rebuilt JMeter.

It remains to add a couple of JSR223 Samplers. The first is before the Publisher/Subscriber pair to create a DAT file containing random bytes:

import org.apache.commons.lang3.RandomUtils;

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;

vars.put("PATH_TO_BYTES", "C:temprandomBytes.dat");
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
byte[] arr = RandomUtils.nextBytes((int)(Math.random()*10000));
        try {
            FileOutputStream fos = new FileOutputStream(RESULT_FILE);
            fos.write(arr);
            fos.close();
        } catch (IOException e) {
            System.out.println("file not found");
        }

The second one, at the end of the script, deletes the file:

import java.io.File;

File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();

And do not forget to add the path to the file in Publisher:

And also a check in JSR223 Assertion for Subscriber - compare the original bytes with those that come to the recipient's queue:

import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.Arrays;

Path path = Paths.get(vars.get("PATH_TO_BYTES"), new String[0]);
byte[] originalArray = Files.readAllBytes(path);
byte[] changedArray = ctx.getPreviousResult().getResponseData();
System.out.println(changedArray.length);

if (Arrays.equals(originalArray, changedArray))
	{
     	SampleResult.setResponseMessage("OK");

	} else {
	   SampleResult.setSuccessful(false);
     	   SampleResult.setResponseMessage("Comparison failed");
	   SampleResult.setResponseData("Bytes have changed","UTF-8");
     	   IsSuccess=false;
	}

Conclusion

Described four ways to send messages to the queue, which I use daily in practice. I hope this information makes your life easier. In continuation, I plan to talk about my experience in testing an exchange, where at one end is a queue, and at the other is a database or file system.

Take care of your time. And thanks for your attention.

Source: habr.com

Queues and JMeter: Exchange with Publisher and Subscriber