Have been using Gatling 2.3.1, to perform some JMS RequestResponse load testing.
Have upgraded to Gatling 3.0.1.1 and found the JMS Correlation no longer works with IBM MQ.
We require correlation by “matchByMessageId”. The messageId from the request message, will be in the correlationId field of the response field.
Correlation is not working in Gatling 3.0.1.1 as the JmsMessageMatcher. MessageIdMessageMatcher does a getJMSMessageID BEFORE the message has been sent to MQ.
IBM MQ sets the message ID during the produce, not when the message is first instantiated.
So the message matcher thinks all the messageIds are null.
The problem is the strategy in Gatling 2.3 was racy.
If, like it was done in Gatling 2, you do:
- sender thread: send message
- sender thread: register correlationId
- listener thread: receive response and correlate
you risk that 3 sometimes happens before 2 and receive responses before their request is registered.
We could definitively reproduce this issue on our side with OSS brokers and it most likely happened with IBM MQ too.
As a result, it’s not possible to revert to Gatling 2 strategy as things now work as expected with brokers that set the MessageId prior to sending, or let users specify a CorrelationId.
If your company is willing to work with us to find a solution (we of course don’t have an IBM MQ testing platform), please let us know.
Otherwise, contributions are very welcome (as long as they don’t break things for other brokers).
Regards,