Previously, if you had a temporary queue replicated across cluster nodes, closing connections to the temporary queue on a given node did not purge the server resources associated with the queue, i.e., the queue had an address leak. This issue is resolved. You can now use the address-queue-scan-period parameter to specify how often the broker scans queues for potential deletion.

Attaching example broker.xml for 2-node cluster, along with a producer using temporary queues for reply addresses. Code looks like: connection = factory.createConnection(); connection.setClientID(clientPrefix + "." + destination + "-" + Integer .toString(threadNum)); connection.start(); if (transacted) { session = connection.createSession(transacted, Session.SESSION_TRANSACTED); } else { session = connection.createSession(transacted, Session.AUTO_ACKNOWLEDGE); } if (dynamic) { producer = session.createProducer( null ); } else { producer = session.createProducer(destination); } producer.setTimeToLive(ttl); if (persistent) { producer.setDeliveryMode(DeliveryMode.PERSISTENT); } else { producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT); } if (replyTo) { tempDest = session.createTemporaryQueue(); responseConsumer = session.createConsumer(tempDest); responseConsumer.setMessageListener( this ); } ... @Override public void onMessage(Message message) { String messageText = null ; try { if (message instanceof TextMessage) { TextMessage textMessage = (TextMessage) message; messageText = textMessage.getText(); LOG.info( "messageText = " + messageText); } } catch (JMSException e) { //Handle the exception appropriately } } On the consumer side, I tried using the same session and spinning up a producer to produce to the replyTo address, and also tried it with a new session for each response. Behavior was the same, either way: Message message = consumer.receive(messageTimeoutMs); if (message != null ) { msgsRecd++; LOG.info( " Thread {}: {} : Got message {}; total: {} path: {}." , this .threadNum, System .currentTimeMillis(), message.getJMSMessageID(), msgsRecd, ((ActiveMQMessage) message).getBrokerPath()); if (message.getJMSReplyTo() != null ) { replySession = connection.createSession(transacted, Session.AUTO_ACKNOWLEDGE); MessageProducer producer = replySession.createProducer(message.getJMSReplyTo()); producer.setTimeToLive(1000); String response = "Received: " + message.getJMSMessageID(); LOG.info( "Sending Response: " + response); Message responseMsg = new ActiveMQTextMessage(); ((ActiveMQTextMessage)responseMsg).setText(response); producer.send(responseMsg); producer.close(); replySession.close(); replySession = null ; } ... To reproduce the issue: 1. Deploy a new AMQ 7.6.0 instance host1 and one to host2 2. Copy the broker-node1.xml file to the host1/$AMQ_INSTANCE/etc/ directory 3. Copy the broker-node2.xml file to the host2/$AMQ_INSTANCE/etc/ directory 4. Update cluster configuration as needed for new environment 5. Edit bootstrap.xml and jolokia-access.xml to enable remote access 6. Extract threaded-consumer-2.1.0-SNAPSHOT.zip, edit jndi.properties java.naming.provider.url to point to your host2 instance 7. Extract threaded-producer-2.1.0-SNAPSHOT.zip, edit jndi.properties java.naming.provider.url to point to your host1 instance 8. Start the consumer application and verify that it connects to the host2 AMQ instance 9. Start the producer application and verify it connects to the host1 instance 10. Watch for the creation of temporary reply queues on each instance 11. Interrupt the producer application with CTRL-C, leaving the consumer running 12. Wait for > 30 seconds (I waited 20 minutes) 13. Observe that temporary queues are not cleaned up, as they should be 14. Interrupt consumer with CTRL-C 15. After a few seconds temporary reply queues are now cleaned up