Issue running scenarios on 2.1.7 with ActiveMQ

Gatling (Open-Source)
1

Hello,

Gatling version in use 2.1.7

When I run JMS scenarios, things seem to run fine and the html output looks good. One section we look at is ‘response time during simulation’ as shown in the image below

If I add Activemq 5.11 .jar file to the lib and run any scenario, they do not run correctly and the scenarios finish with unusually high numbers.

For example start with 1200 ‘waiting’ users.
They move to ‘active’ in blocks of 50.
After 120sec all 1200 are ‘active’ and all the messages are waiting on the reply queue.
After a long time the scenario eventually finished with very high response times.
The html output no longer has a section titled ‘response time during simulation’

`
Simulation com.uprr.ctl.testing.gatling.amqjms.AMQRequestReply started…
INFO | Total number of users : 1200
INFO | Initializing
INFO | Initializing
INFO | Initialized
INFO | Initialized
INFO | Start user #4342972264893824327-0
INFO | Got InitialContext javax.naming.InitialContext@148122ba
INFO | Got ConnectionFactory org.apache.activemq.ActiveMQConnectionFactory@78d16a7d

2

Are you sure that ActimeMQ matches by correlation ID?
I thought it was matching by message ID instead.

3

I thought it should, but I went ahead and changed to .matchByMessageID and had very similar results.

One interesting view in the report makes it look like all the requests are sent first, then the responses happen which could explain the long time. I’m just not sure why it would do that.

4

Honestly, no idea. You’re the first one to ever report something like this.
Can you provide a dummy sample that exhibits the issue, our does it only happen with your system?

5

I figured out where the 120 second delay was coming from. I’ll leave it here in case anyone else runs into this. It was actually in the AMQ broker configuration on a static queue. Every destination can have a timeBeforeDispatchStarts setting… I found that this had been set to 12000ms as a default for all queues on the broker. After removing this setting the test worked as expected.

It’s always the little things!

6

Thanks for your feedback! And glad you could figure it out :slight_smile: