CODEWITHSUNDEEP
scalajmsgatling
Steve H
Steve H

Reputation: 378

Is it possible to have Gatling JMS listen for messages only?

I've been exploring the use of Gatling for JMS testing as part of broader perf testing of our AUT. I've played with the example as found at https://gatling.io/docs/current/jms/, and have successfully had gatling create a queue on my test ActiveMQ server, and read the message.

However, actual AUT testing needs dictates that services in our app will create the msgs on our ActiveMQ server - and all I want in my Gatling code is make REST calls to our services that generate the messages, then the Gatling JMS code should pick up the messages, parse them as appropriate, and when I find a certain message, move on to the next bit of the test.

As per the gatling link above, "Currently, requestReply and send (fire and forget) requests are supported." Does this mean what I am trying to do is impossible? Does this mean I have to create the messages with Gatling, but not necessarily look for a reply?

If it is possible, I assume I could split the example I've been playing with into 2 separate exec actions - one to send, and one to receive? But how?

Thanks!

Upvotes: 1

Views: 768

Answers (2)

Julian
Julian

Reputation: 4085

If I understand it well what you want it here is to involve more than one service integrating to each other. In your business flow an API call is made to one of your services, this generates a JMS request into an ActiveMQ JMS broker and another service pics it up and sends a response into a response queue. We have multiple such scenario in some it was just one micro service taking the API call and producing the response in others were multiple hops, but this is irrelevant. All you want is make an API call and wait for a JMS response to arrive.

This is doable, we done it. For legal reasons I cannot drop the code here, but this is how we done it.

  • Implement your own HttpToJmsAction and HttpToJmsActionDsl classes.
  • The above action will make an API call passing a unique request identifier as a HTTP header or some request body content. It is important that that unique identifier will be propagated to the JMS response either as a JMS header or somewhere in the response body.
  • Implement a JMS listener class that will listen to the response queue, extract the unique identifier and save it in a structure, say a Map with the identifier as the key and the JMSTimestamp as the value.
  • After making the API call the action will asynchronously stay in a loop waiting for the key to pop up in the responses Map. It is important this loop is happening in a different thread, so you are not blocking the threads making API calls.
  • Because when producing the API request, you know the request time and you have the response time in the responses Map you can easily make the difference and have the response time. At this point you can log your status with Gatling

It worked for us. Part of the HttpToJmsActionDsl you might need to add support for additional functionality such as a KeyExtractor, the JmsConsumer, etc but that would be part of your own design.

Be aware the solution is not perfect, and we encountered issues with negative KOs. You can read about this in my stack overflow question here. Our solution to that was to make timeout bigger but there is no guarantee you won't get any false KOs.

Things to watch out for is to implement performant JMS listeners able to cache JMS connections and scale up and down the number of concurrent consumers from the response queue. Useless to say the write access to the response Map must be synchronized.

Hope it helped

Upvotes: 0

Stéphane LANDELLE
Stéphane LANDELLE

Reputation: 6623

No, it's not possible at the moment (Gatling 3.3).

Upvotes: 0

Related Questions