Queues and JMeter: sharing with Publisher and Subscriber

Hi, Habr!

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

We are making a data bus for a large federal company. Different request formats, conversions, intricate routing. For testing, you need to send a lot of messages in the queue. Manually - the pain that not every manual worker can handle.
')

Introduction

Although this pain had to be tolerated at first. It all started with RFHUtil. Powerful, but uncomfortable and scary: Well, you know Rus.



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

With JMeter, everything is easier. After the first stage with mastering and addiction, the hope of happy testing began to dawn.

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

Sampler Training

JMS Publisher

• Setup - Each Sample. Apache recommends using this option if queues / topics are set 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 claims that persistent mode ensures reliable storage of transmitted messages 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 a jms property that Subscriber will use in JMS Selector. For each dispatch, a random value is generated in the element of the User Parameters test plan:



So you can be sure that you read the correct message.

The final "blank" 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 sample? - true.

JMS Selector is a pretty handy thing . Summary JMS Subscriber:



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

1. Add JVM argument to JMeter launcher:
   

   -Dfile.encoding=UTF-8 

2. Add JSR223 PostProcessor to Subscriber with a groovy line:

    prev.setDataEncoding("UTF-8") 

Text transfer

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

File transfer

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

File transfer to text field

The most versatile option. Suitable for most scenarios + can be used in JMS Point-to-Point, in which there is no second sending option:

Transfer byte array

The most difficult option. Suitable for checking the immaculate-accurate transmission of requests up to a byte, without distortion, sms and perturbation. To do this in the default JMeter will not work, here I was definitely told about it.

So I had to download the source code and modify the JMS Subscriber code .

Replaced the line in the extractContent(..) method:

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

on:

 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 pair of JSR223 Sampler. The first is before a 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:\\temp\\randomBytes.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 - 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:



As well as the check in JSR223 Assertion for Subscriber - compare the original bytes with those that arrive in 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 every day in practice. I hope this information will make your life easier. In the sequel, I plan to talk about my exchange testing experience, where there is a line at one end and a database or file system at the other.

Take care of your time. And thank you for your attention.