Pause unused application contexts in the TestContext framework

[fabian-flechtmann]

Overview

Since the introduction of the Spring TestContext Framework in 2007, application contexts have always been stored in the context cache in a "running" state. However, leaving a context running means that components in the context may continue to run in the background. For example, JMS listeners may continue to consume messages from a queue; scheduled tasks may continue to perform active work, etc.; and this can lead to issues within a test suite.

To address such issues, we should introduce built-in support for pausing application contexts when they are not in use and restarting them if they are needed again.

Related Issues

• SmartLifecycle beans are not closed in @SpringBootTest spring-boot#28312
• Introduce ConfigurableApplicationContext.restart() method #35171

Original Issue Description

There have been several reports of message listeners still actively listening while being the in the application context cache during integration tests. There does not seem to be a mechanism to keep these listener beans in the cache while also switching off the listening.

Would it make sense to extend the SmartLifecycle interface?

Something like onEnterActiveContext and onLeaveActiveContext could be intercepted in the listener beans to toggle the listening. These methods would be called when a bean moves into or out of the active application context. It's not the same as start and stop, which are only called when the bean is loaded for the first time and when the application shuts down.

[jhoeller]

Actually, stop() and re-start() is a quite good fit when becoming inactive and then active again. Those are not just for startup and shutdown, they also allow for intermediate pausing and restarting, with a lot of refinements having gone into that in 6.1 in particular (not least of it all for CRaC snapshots).

ConfigurableApplicationContext itself extends Lifecycle for that reason, providing context-level stop() and start() methods that propagate to all contained Lifecycle beans. We could possibly call those methods when a context becomes inactive (entering the context cache) and then active again (taken out of the context cache).

[fabian-flechtmann]

Thanks for getting back to me!

That sounds like a good fit. The listener i'm working with is already reacting to start() and stop() as you propose and others probably are as well.

Do you think it would break any existing behavior to call these methods when a context becomes inactive?

[jhoeller]

I see it as a pretty straightforward step for the state of the context itself.

That said, the Test Context Framework needs to be able to track when a context actually becomes inactive. At the moment, multiple tests can use the same context from the cache without 'returning' it, so there is no actual tracking when a context becomes inactive (in the sense of not being used by any test at the moment). I need to discuss this with @sbrannen, let's see what we can do there.

[sbrannen]

After discussing this with @jhoeller, we have decided that it is worthwhile investigating whether we can stop an inactive ApplicationContext in the TestContext framework.

This could potentially be achieved via the following.

• Track "active" contexts in the ContextCache via some sort of active usage counter.
• Increment the active usage counter and restart any stopped ApplicationContext whenever TestContext.getApplicationContext() is invoked for a given test class.
• Decrement the active usage counter whenever a test class completes (for example, via an "after test class" callback).
• If the decrement results in the active usage counter dropping to zero, stop the ApplicationContext.

Figuring out when TestContext.getApplicationContext() is invoked the first time for a given test class is likely not possible without tracking the "active test class" along with the "active usage counter". Thus, we might need some form of concurrent data structure (or a structure within DefaultContextCache) for that purpose. Actually, we might be able to track only the "active test classes" instead of any actual counter.

[sbrannen]

As a side note, this is somewhat related to the following issue which resulted in the introduction of test events such as BeforeTestClassEvent and AfterTestClassEvent.

• Publish test execution events to the test ApplicationContext [SPR-13916] #18490