Possible bug in JMS protocol

Hello! I am using Gatling to test SQS based app and I use Gatling JMS feature for that. I have noticed that I combine to simulations in one scenario then they “steal” messages from one another. For example

class AllRequestsCustomSimulation extends Simulation {
  setUp(
    FundsRequests.fundsRequestsSimulationScn.inject(
      //   atOnceUsers(10)
      nothingFor(7 minutes),
      constantUsersPerSec(24 * usersMagnifier) during (3 * durationMagnifier minutes),
      nothingFor(20 minutes),
    )
    Taps.newCardsTaps.inject(
      constantUsersPerSec(10 * usersMagnifier) during (30 * durationMagnifier minutes)
    )
  )
    .protocols(SQSTestBase.jmsConfig)
    .maxDuration(maxDuration minutes)
}

Both simulations use "requestReply" mode of JMS and connected to the same queues though they send/receive different messages. In this scenario some users will never finish because they don't get reply messages (which already have been consumed by other simulation and ignored there)

I can workaround it by creating one combined simulation but it is not really convenient, because it makes sense to describe each message type in separate class and then combine them together

What do you think?

I fail to see how it could work as you expect as long as the different scenarios (not simulations) hit the same queues.

Just a thought… Maybe, scenarios can share the same “matching engine” somehow? I found a workaround for this case anyway, I combine different request in one long scenario. This is less convenient than to be able to combine different scenarios on one simulation as lego bricks to get the proper load profile. But it works well

There’s one tracker instance per (destination, selector) pair.
No idea what you mean by “they steal messages from one another”. Your JmsMessageMatcher is supposed to be in charge of properly matching outgoing and incoming messages.

Oh, I just got what do you mean by “There’s one tracker instance per (destination, selector) pair” - I have 4 different scenarios combined in one simulation, 3 were identical in terms of that pairs and last one had different “entry queue” but the same “reply queue”. It explains why some messages have been lost in that simulation.
.