All entries are present and they are all progressing through the queues in the correct order (that has been manually validated)
I'm using a JMS publisher to publish to the incoming queue and a JMS Subscriber to consume from the outgoing queue. Everything works correctly with a single thread. If increase to 5 threads with a 10 second ramp up period it's all still fine. If increase to 30 threads with a 10 second ramp up period it JMeter seems to be losing track of which message should be consumed from the outgoing queue and I start to get failures. 30 threads with a 10 seconds ramp up is when the queue is being loaded faster than the application can process items on the incoming queue and place them on the outgoing queue (i.e. when the queue actually starts being used in anger). The application only process one item at a time, so it is not picking multiple items off the incoming queue and putting them on the outgoing queue in a different order (this has been manually checked and validated). Each thread is adding another consumer to the outgoing queue so what would appear to be happening is that as the threads have to start waiting for messages to pop out the other side they don't wait in turn but just all try to consume at the same time resulting in a big bun fight and each thread grabbing the first message it can see which is not the one it is expecting. It seems I would need a way to do one of the following: * Force the threads to wait for their turn rather than having a bun fight. * Somehow configure a single consumer that can marshal messages to the correct thread. Maybe I need to have a custom consumer that loads everything in outgoing into a new topic and let the JMS Subscriber search the topic for the message it is expecting? -----Original Message----- From: sebb [mailto:[email protected]] Sent: 31 May 2012 10:26 To: JMeter Users List Subject: Re: Jmeter With JMS Queues On 31 May 2012 09:40, Mark Collin <[email protected]> wrote: > I'm currently using 2.6 at the moment (upgrading to 2.7 some point > this > week) > > JMS provider is ActiveMQ > > The problem I'm seeing is that JMeter is not consuming from the > outgoing queue in the same order it is publishing to the incoming > queue when running the test with multiple threads. Is it skipping any outgpoing entries? Or are they all present but in a different order? Which JMS Samplers are you using? How many threads? Does the behaviour improve if you use a single thread? > > -----Original Message----- > From: sebb [mailto:[email protected]] > Sent: 30 May 2012 23:29 > To: JMeter Users List > Subject: Re: Jmeter With JMS Queues > > On 30 May 2012 12:39, Mark Collin <[email protected]> wrote: >> Does anybody have any useful resources for working with JMS Queues? >> >> >> >> I'm currently using JMeter to load a JMS Queue(incoming) that my >> application consumes from. The application then processes the >> message and then places another message on a different queue(outgoing). >> >> >> >> I can load the incoming queue up with no problems, and I can consume >> from the outgoing queue and check that the order id matches the >> message on the incoming queue. >> >> >> >> My problem is when I start ramping up the number of threads, JMeter >> seems to be losing track of which message should be getting picked up >> from the outgoing queue next. The application is processing items on >> the queue in order (manually verified), but JMeter is losing track of >> which response is next so when I check the order id it thinks the >> wrong message is on the outgoing queue. > > No idea what that means. > >> >> >> >> Does anybody have any hints? > > It would be helpful to know which version of JMeter you are using, and > which samplers. > > > Also potentially which JMS provider. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
