Gatling JMS api available for testing

Hi all

If you want to test JMS through the Gatling API - you can now try this out -

There’s still a bit to do to round it out (more in the checks API, and create some unit test coverage), and please raise any issues if you see any. It’s not extensively tested at this point. It’s built against 2.0.0-M3a.

Thanks @slandelle and the Gatling team for putting such a great tool together and for your help getting going. Much appreciated.


Thank you very much for contributing to the project. That’s a very cool add-on.


Very nice!

I’ll try to do some review in the next weeks. Do you have a sample that can be easily set up?


Hi Stephane -

You can see an example here -

Or were you looking for an end to end demo of how to set up (eg: setting up a jms broker etc).


The second one (lazy mode) :slight_smile:

Other questions: why did you choose FFMQ over other brokers? Is it particularly fast? Is it because you’re familiar with it? Is the project active? Will it support JMS2?

Hi Stephane

In my case, I chose FFMQ because it is simple and lightweight to set up (unzip and run). No need to configure queues manually. It claims to be fast, project does not seem active, and does not currently support Jms2 (though Jms2 should be backwards compatible).

By way of analogy, you can use Gatling to test HTTP whether you run on Apache or Microsoft IIS, Nginx, Websphere, etc. The same applies here to the JMS provider. The JMS provider is (almost) a part of hosting the service, so you have to take the JMS provider platform into account - but really you’re aiming to test the performance of your application components connected to it. So - asking why I chose FFMQ as my example is akin to asking why you choose a specific server for your tests, it doesn’t matter so much :).

JMS is an API spec and there are a number of brokers which implement the spec [1]. Whichever JMS provider you use is up to you, just change the protocol and it will work.

I’ll write a proper blog article at some point but till then feel free to ask more questions.




Sorry, I didn’t properly read your code at the time I wrote this email and thought you had a compile-time dep to FFMQ.

Hi All,

I am investigating the possibility of using Gatling to test JMS application which uses ActiveMQ.

I have a couple of questions:

  1. Is ActiveMQ supported by the gatling - jms plugin - here the implementation seems to be specific to FFMQ.
  2. In case ActiveMQ is supported is there an example.
  3. Would this be available in Gatling 2 only or also in 1.5?

Many thanks,


Hi Pierre DAL-PRA,

When I’m testing with ActiveMQ it throws me the following error:

I think that the contextFactory name is wrong, but I can’t find any that workds…Do you have any working example with ActiveMQ that you can share?


val jmsConfig = jms

[ERROR] [12/29/2014 10:38:11.668] [] [akka://GatlingSystem/user/jmsReqReply-3] scheme failover not recognized exception during creation
at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:279)
at akka.dispatch.Mailbox.exec(Mailbox.scala:231)
at scala.concurrent.forkjoin.ForkJoinTask.doExec(
at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.pollAndExecAll(
at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(
at scala.concurrent.forkjoin.ForkJoinPool.runWorker(
Caused by: javax.naming.NamingException: scheme failover not recognized
at org.apache.activemq.jndi.ReadOnlyContext.lookup(
at javax.naming.InitialContext.lookup(
at io.gatling.jms.client.SimpleJmsClient.(SimpleJmsClient.scala:58)
at io.gatling.jms.JmsReqReplyAction.(JmsReqReplyAction.scala:49)
at io.gatling.jms.JmsReqReplyActionBuilder$$anonfun$build$1.apply(JmsReqReplyActionBuilder.scala:31)
at io.gatling.jms.JmsReqReplyActionBuilder$$anonfun$build$1.apply(JmsReqReplyActionBuilder.scala:31)
… 10 more


In your example, you’re mixing the ConnectionFactory name with the URL.
And ActiveMQ’s DEFAULT_BROKER_URL is a valid URL, but not a valid JNDI path.

This is a working example of ActiveMQ usage with Gatling’s JMS support, which we use in your tests:



Hi Pierre,

Thanks for the example, after changing to connectionFactoryName(“ConnectionFactory”) it’s not failing on that exception anymore.

However I’m still not able to run the test to completion:
Caused by: java.lang.UnsupportedOperationException: There were no requests sent during the simulation, reports won’t be generated

My ActiveMQ server have nothing special, I’ve just installed and thats it. Should I configure anything in order to have this testnig running ?
Should I do anything with the MQ server ?


package computerdatabase

import net.timewalker.ffmq3.FFMQConstants
import io.gatling.core.Predef._
import io.gatling.jms.Predef._
import scala.concurrent.duration._

import io.gatling.core.Predef._
import javax.jms._
import org.apache.activemq.ActiveMQConnectionFactory

class JMS10k extends Simulation {

val duration = Integer.getInteger(“duration”, 60).toInt

def jmsConfig = jms

val scn = scenario(“JMS DSL test”).repeat(0) {
jms(“req reply testing”).reqreply
.textMessage(“hello from gatling jms dsl”)
.property(“test_header”, “test_value”)

setUp(scn.inject(rampUsersPerSec(10) to 1000 during (10 seconds)))

def checkBodyTextCorrect(m: Message) = {
m match {
case tm: TextMessage => tm.getText == “HELLO FROM GATLING JMS DSL”
case _ => false


[INFO] Scanning for projects…
[INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder with a thread count of 1
[INFO] ------------------------------------------------------------------------
[INFO] Building gatling-maven-plugin-demo 2.1.1
[INFO] ------------------------------------------------------------------------
[INFO] — gatling-maven-plugin:2.1.1:execute (default-cli) @ gatling-maven-plugin-demo —
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/x/.m2/repository/ch/qos/logback/logback-classic/1.1.2/logback-classic-1.1.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/x/.m2/repository/org/apache/activemq/activemq-all/5.8.0/activemq-all-5.8.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See for an explanation.
12:15:52,000 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
12:15:52,000 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:/C:/opt/scala_workspace/gatling-maven-plugin-demo/target/test-classes/logback-test.xml]
12:15:52,001 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback-test.xml] occurs multiple times on the classpath.
12:15:52,001 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback-test.xml] occurs at [file:/C:/opt/scala_workspace/gatling-maven-plugin-demo/target/test-classes/logback-test.xml]
12:15:52,001 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback-test.xml] occurs at [file:/C:/opt/scala_workspace/gatling-maven-plugin-demo/src/test/resources/logback-test.xml]
12:15:52,090 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
12:15:52,102 |-INFO in ch.qos.logback.classic.joran.action.LoggerContextListenerAction - Adding LoggerContextListener of type [ch.qos.logback.classic.jul.LevelChangePropagator] to the object stack
12:15:52,128 |-INFO in ch.qos.logback.classic.jul.LevelChangePropagator@37fcdbc5 - Propagating DEBUG level on Logger[ROOT] onto the JUL framework
12:15:52,128 |-INFO in ch.qos.logback.classic.joran.action.LoggerContextListenerAction - Starting LoggerContextListener
12:15:52,128 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
12:15:52,131 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [CONSOLE]
12:15:52,140 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
12:15:52,197 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to WARN
12:15:52,197 |-INFO in ch.qos.logback.classic.jul.LevelChangePropagator@37fcdbc5 - Propagating WARN level on Logger[ROOT] onto the JUL framework
12:15:52,197 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [CONSOLE] to Logger[ROOT]
12:15:52,198 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
12:15:52,200 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@39c07f3a - Registering current configuration as safe fallback point

SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
Simulation computerdatabase.JMS10k started…

val scn = scenario(“JMS DSL test”).repeat(0) : That is your problem.
Your thousands of users are executing a scenario which does absolutely nothing. since the loop never get executed. repeat(0) is a nonsense.
And so Gatling complains during the reports generation that there was no requests executed in your scenario.


M trying to test JMS application which uses TIBCO queues, could you please elaborate about integration of Gatling with TIBCO jars.

Akhila begum

Hi All,

is there any way in Gatling to use JMS Protocol to test the IBM Websphere MQ, if so can you please let me know how we can do it

Thanks in Advance…!!!

Venkatesh Nayak