DefaultMessageListenerContainer does not clear Session and MessageConsumer for paused invokers

[krezovic]

I have created the following minimal reproducer https://github.com/krezovic/spring-issues/tree/artemis-jakarta-server-suspend

Run with ./mvnw clean verify and observe the output.

This worked fine in Spring Boot 3.

Scenario:

• Test 1: Test Context 1, listens on destination "test"
• Test 2: Test Context 2 (simulated with DirtiesContext, otherwise we use different properties and profiles), listens on same destination "test"
• Test 3: Test Context 1 (no change in annotations or properties compared to Test 1), again listens on same destination "test"

Context used for Test 1 is paused when Test 2 starts to execute. Once Test 2 is finished, Test 3 is started and resumes the context used by Test 1. This results in a runtime error with listener created in Test 1 as follows

2025-11-29T14:09:00.602+01:00  INFO 26756 --- [demo] [ntContainer#0-1] o.s.j.c.CachingConnectionFactory         : Encountered a JMSException - resetting the underlying JMS Connection

jakarta.jms.IllegalStateException: AMQ219017: Consumer is closed
        at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.checkClosed(ClientConsumerImpl.java:934) ~[artemis-core-client-2.43.0.jar:2.43.0]
        at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:206) ~[artemis-core-client-2.43.0.jar:2.43.0]
        at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:376) ~[artemis-core-client-2.43.0.jar:2.43.0]
        at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:213) ~[artemis-jakarta-client-2.43.0.jar:2.43.0]
        at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:134) ~[artemis-jakarta-client-2.43.0.jar:2.43.0]
        at org.springframework.jms.support.destination.JmsDestinationAccessor.receiveFromConsumer(JmsDestinationAccessor.java:131) ~[spring-jms-7.0.1.jar:7.0.1]
        at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:438) ~[spring-jms-7.0.1.jar:7.0.1]
        at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:314) ~[spring-jms-7.0.1.jar:7.0.1]
        at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:268) ~[spring-jms-7.0.1.jar:7.0.1]
        at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1416) ~[spring-jms-7.0.1.jar:7.0.1]
        at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1406) ~[spring-jms-7.0.1.jar:7.0.1]
        at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1283) ~[spring-jms-7.0.1.jar:7.0.1]
        at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
Caused by: org.apache.activemq.artemis.api.core.ActiveMQObjectClosedException: AMQ219017: Consumer is closed
        ... 13 common frames omitted

2025-11-29T14:09:00.604+01:00  INFO 26756 --- [demo] [vemq-localhost)] org.apache.activemq.audit.message        : AMQ601500: User anonymous@invm:0 sent a message CoreMessage[messageID=32, durable=true, userID=9254e86b-cd24-11f0-896e-bcfce76747f1, priority=4, timestamp=Sat Nov 29 14:09:00 CET 2025, expiration=0, durable=true, address=test, size=228, properties=TypedProperties[__AMQ_CID=91b43b92-cd24-11f0-896e-bcfce76747f1, _AMQ_ROUTING_TYPE=1]]@1685128485, context: RoutingContextImpl(Address=test, routingType=ANYCAST, PreviousAddress=test previousRoute:ANYCAST, reusable=true, version=-2147483645)
..................................................
***** durable queues test:
- queueID=12 address:test name:test filter:null
***** non durable for test:
..................................................
, transaction: null
2025-11-29T14:09:00.605+01:00  INFO 26756 --- [demo] [ntContainer#0-1] org.apache.activemq.audit.resource       : AMQ601768: CORE connection 91b41480-cd24-11f0-896e-bcfce76747f1 for user anonymous@invm:0 destroyed
2025-11-29T14:09:00.606+01:00  WARN 26756 --- [demo] [ntContainer#0-1] o.s.j.l.DefaultMessageListenerContainer  : Setup of JMS message listener invoker failed for destination 'test' - trying to recover. Cause: AMQ219017: Consumer is closed
2025-11-29T14:09:00.606+01:00  INFO 26756 --- [demo] [ntContainer#0-1] org.apache.activemq.audit.resource       : AMQ601768: CORE connection 92544c27-cd24-11f0-896e-bcfce76747f1 for user anonymous@invm:0 destroyed
2025-11-29T14:09:00.607+01:00  INFO 26756 --- [demo] [ntContainer#0-1] org.apache.activemq.audit.resource       : AMQ601767: CORE connection 92555d9c-cd24-11f0-896e-bcfce76747f1 for user unknown@invm:0 created

While the connection is successfully re-established due to default reconnect policy, it may not always be the case depending how the listener was configured to retry.

This issue is amplified with increasing number of tests switching between pause and resume.

[wilkinsona]

Thanks for the report. This is out of Spring Boot's control. The suspend and resume is driven by Spring Framework's test context framework. JMS is involved in that because Framework classes like SingleConnectionFactory implement Lifecycle. We'll transfer this to the Framework issue tracker so that they can investigate further.

[jhoeller]

This turns out to be an older bug in DefaultMessageListenerContainer where it clears the shared Connection once all invokers have been stopped but it does not clear the Session and MessageConsumer in the remaining scheduler invokers themselves. This nevertheless worked since the invoker would recover on restart - in a reliable fashion actually but with that noisy log that you noticed.

Since this is not directly related to the Test Context Suspend/Resume feature in 7.0 but rather affecting any stop/restart attempt at runtime (in a way that we support it since 6.1), I'll fix this in 7.0.2 as well as 6.2.15.