jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Race condition in JMS_TESTS.xml
Date Tue, 28 May 2019 07:30:16 GMT

It looks like there's a race condition in JMS_TESTS.xml.
I think it causes batch JMS_TESTS.jmx to fail, and I think this failure has
nothing to do with Gradle patch.

"setUp Thread Group" starts JMS server
Then JMS tests are performed
"tearDown Thread Group" shuts down the JMS server

Then notifyTestListenersOfEnd is called, and it seems to cause
"JMSException: Cannot send, channel has already failed".
Note: the JMS server has already been closed by that point, so it is not
clear which sense does it make to close connections then.

The call sequence is as follows
StandardJMeterEngine.notifyTestListenersOfEnd ->
jms.sampler.PublisherSampler.testEnded -> jms.client.ClientPool.clearClient
-> ActiveMQMessageProducer.close

Theoretically speaking, the solution is to move "JMS server shutdown"
*after* testEnded event, however it looks like there's no such a feature

It looks like somebody has thought of that scenario, and I see a 5sec delay
before jms shutdown.
However it does not really help: JMeter waits till the finish of teardown
group anyway, so that 5 sec delay just increases test duration, and it has
nothing to do with preventing ClientPool.clearClient and jms shutdown

Any thoughts on that?

It looks like the teardown in question needs to be reworked to use a new
thread which would postpone JMS server shutdown.
That is something behind the lines of

import org.apache.jmeter.util.JMeterUtils;

BrokerService broker = props.get("ACTIVEMQ_BROKER");
new Thread(() -> {
    FileUtils.deleteDirectory(new File(JMeterUtils.getJMeterHome(),


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message