Hey, I'd really like to get some help. TL;DR : MessageListenerContainers which were created in the previous contexts are still listening, grinding the tests to a halt.

// Major libraries
Spring Boot 2.5.4
maven.compiler.target 11
spring-cloud 2020.0.3
ibmmq 2.5.0
testcontainer-junit 1.15.3
testcontainer-kafka 1.15.3

Setup @KafkaListener and @JmsListener; @Testcontainers on abstract @SpringBootTest with @DynamicProperty used to load data from @Containers

What can be seen MessageListenerContainers created with the data loaded in @DynamicProperty are persisted between runs - before contexts loads (With/without @DirtiesContext) I can see that both KafkaListeners and JMSListeners are trying to connect to their respective servers with the ports from the "previous (docker) container" - previous @DynamicContext, and by consequence prevous context

Additionally, MessageListenerContainer from Kafka and JMS are not related, except they share only one interface worth mentioning, SmartLifecycle

What I suspect SmartLifecycle is not destroyed/stopped on context refresh.

Please help? :)

Comment From: Venthe

Clarification: After testing with the debugger, it seems that 'some' SmartLifecycle implementors have their .stop() called, but not KafkaListenerEndpointRegistry. Test is annotated with @DirtiesContext(classMode = AFTER_CLASS)

I still believe that the problem is on the core Spring side, as the same error is with JMS

Comment From: wilkinsona

Thanks for the report. I can't think why some SmartLifecycle implementations would have stop() called, while others do not unless some of the instances of those implementations are not Spring-managed beans. Can you provide a minimal sample that reproduces the behaviour that you've described? I don't think we'll be able to help you without one.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: kerkhofsd

I am experiencing similar behaviour and created a minimal reproducing application: https://github.com/kerkhofsd/spring-boot-gh-28312

Given * any bean which implements SmartLifeCycle * multiple @SpringBootTests * at least one of the @SpringBootTests contains an @TestConfiguration

Actual behaviour * during executing of the two @SpringBootTests, the SmartLifecycle is started twice * after the first @SpringBootTest execution, the first SmartLifecycle bean instance is not stopped

Detailed timeline

  1. During the first test execution, an instance of CustomSmartLifeCycle implements SmartLifecycle is created and started
2022-12-07T09:24:23.536+01:00  INFO 5541 --- [           main] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@1ddd3478] ctor()
2022-12-07T09:24:23.589+01:00  INFO 5541 --- [           main] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@1ddd3478] isRunning()
2022-12-07T09:24:23.589+01:00  INFO 5541 --- [           main] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@1ddd3478] start()
  1. After the first test execution, the SmartLifecycle is not stopped!
  2. During the second test execution, another CustomSmartLifeCycle is created and started
2022-12-07T09:24:24.133+01:00  INFO 5541 --- [           main] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@490c7a83] ctor()
2022-12-07T09:24:24.153+01:00  INFO 5541 --- [           main] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@490c7a83] isRunning()
2022-12-07T09:24:24.153+01:00  INFO 5541 --- [           main] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@490c7a83] start()
  1. Only after the entire test suite execution, the SmartLifecycle beans are stopped
2022-12-07T09:24:24.168+01:00  INFO 5541 --- [ionShutdownHook] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@1ddd3478] isRunning()
2022-12-07T09:24:24.168+01:00  INFO 5541 --- [ionShutdownHook] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@1ddd3478] stop()
2022-12-07T09:24:24.170+01:00  INFO 5541 --- [ionShutdownHook] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@490c7a83] isRunning()
2022-12-07T09:24:24.170+01:00  INFO 5541 --- [ionShutdownHook] c.g.k.s.CustomSmartLifeCycle             : [com.github.kerkhofsd.springbootgh28312.CustomSmartLifeCycle@490c7a83] stop()

I'm experiencing this to be a problem especially for MessageListenerContainers instances, given that the original container is still running and does accept / handle messages.

Comment From: kerkhofsd

@wilkinsona could this be reopened please, or would you prefer creating a new issue for this?

Thanks in advance!

Comment From: bclozel

@kerkhofsd I think that what you're seeing is not a bug, since all beans are closed as expected. This issue what about beans not being closed at all.

In this case, what you're seeing is the Context Caching feature in action: contexts are cached and reused within a test suite and are closed at the end.

Comment From: kerkhofsd

@bclozel thanks for your feedback!

I can see how this behaviour fits in the context caching feature. For MessageListenerContainers beans this does give some undesired side effects though. However indeed probably unrelated to this issue. Thanks again for your input!

Comment From: NicoStrecker

@bclozel I have the same Problem after upgrading to Spring Boot 3.1.2 and switiching from ActiveMQ Classic to ActiveMQ Artemis.

Failed to shut down 1 bean with phase value 2147483647 within timeout of 10000ms: [org.springframework.jms.config.internalJmsListenerEndpointRegistry]

My Test uses @DirtiesContext (no Context Caching)

Comment From: outsideMyBox

For what it is worth, I have the same issue as @NicoStrecker in my tests (without any @DirtyContext) Shutdown phase 2147483647 ends with 1 bean still running after timeout of 30000ms: [org.springframework.jms.config.internalJmsListenerEndpointRegistry]

Spring Boot 3.2.6 org.apache.activemq:artemis-junit 2.12.0

Comment From: bclozel

@outsideMyBox I'm not seeing any issue on my side. If you believe you have found a bug, please create a new issue with a minimal application showing the problem.

Comment From: outsideMyBox

Sorry, wrong person.