Considerations when using JMS blocking send

Gatling version: 3.15.1
Gatling flavor: java kotlin scala javascript typescript
Gatling build tool: maven gradle sbt bundle npm

I made sure I’ve update my Gatling version to the latest release
I read the guidelines and how to ask a question topics.
I provided a SSCCE (or at least, all information to help the community understand my topic)
I copied output I observe, and explain what I think should be.

Hi,

First, thanks for an amazing tool. I have enjoyed working with it.

I am using Gatling to test our own JMS provider in a request/reply scenario. I can extract usable results, but I have some questions relating to how can I interpret them.

My understanding of the JMS Producer send specification is that it is a blocking action. MessageProducer.send(Message) has this in the JMS spec:

“These methods will block until the message has been sent. If necessary the call will block until a confirmation message has been received back from the JMS server.”

(In JMS 2.0, non-blocking variants were added, but I do not want to test those yet)

My Scala knowledge is not good - and this may be my issue - but I understand that producer.send may be being called on the virtual user event loop here - gatling/gatling-jms/src/main/scala/io/gatling/jms/action/JmsAction.scala at main · gatling/gatling · GitHub - and that this is supposed to be not good, as the event loop is assuming non-blocking actions in order to provide accurate statistics.

I don’t think I am in a position to provide code unfortunately, but so far I am getting OK (== understandable) results. I am more interested in my throughput bottlenecks than absolute latencies. But would you be able to help me understand whether I have a potential issue with the blocking producer.send in my simulation, and what the potential effects of such blocking calls on the stats calculated by Gatling might be?

Many thanks - Alastair

Hi,

Indeed, our implementation currently uses the JMS 1 blocking variant and indeed it’s not optimal as it’s going to block the Gatling IO threads. The question is then “how much?”, which will depend on how fast your JMS implementation accepts the message.

I don’t think I am in a position to provide code unfortunately, but so far I am getting OK (== understandable) results. I am more interested in my throughput bottlenecks than absolute latencies. But would you be able to help me understand whether I have a potential issue with the blocking producer.send in my simulation, and what the potential effects of such blocking calls on the stats calculated by Gatling might be?

I’m afraid the impact can only be measured in your real environment, on your real use cases, which is something we can only help with through consulting.