question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Armeria doesn't stop between test suites when running with Spring Boot

See original GitHub issue

Consider the following scenario:

  • A Spring Boot application backed by Armeria just like the one in the examples;
  • We want to test our application using different configurations (for instance an application that uses different datasources, or caches, or something else)

One way to do this is to use Spring @ContextConfiguration where we inject the configurations we want to use. So if we reuse the spring-boot-minimal example we would do something like the following:

package example.springframework.boot.minimal;

// our import declarations

@ActiveProfiles("testbed")
@SpringBootTest(webEnvironment = WebEnvironment.NONE)
@ContextConfiguration(initializers = { HelloApplicationIntegrationTest.Initializer.class })
class HelloApplicationIntegrationTest {

    static class Initializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
        public void initialize(ConfigurableApplicationContext configurableApplicationContext) {
            TestPropertyValues
                    .of("the property overrides we want to test against")
                    .applyTo(configurableApplicationContext.getEnvironment());
        }
    }

// our test cases and so on

}

If we debug this test suite with a breakpoint at the ArmeriaServerGracefulShutdownLifecycle.java the execution will stop at the stop() method during shutdown as expected.

The issue here is that if we create another test class to test another configuration setup:

package example.springframework.boot.minimal;

// our import declarations

@ActiveProfiles("testbed")
@SpringBootTest(webEnvironment = WebEnvironment.NONE)
@ContextConfiguration(initializers = { HelloApplicationIntegrationTest2.Initializer.class })
class HelloApplicationIntegrationTest2 {

    static class Initializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
        public void initialize(ConfigurableApplicationContext configurableApplicationContext) {
            TestPropertyValues
                    .of("the property overrides we want to test against different than the ones used at HelloApplicationIntegrationTest")
                    .applyTo(configurableApplicationContext.getEnvironment());
        }
    }

// same tests as HelloApplicationIntegrationTest

}

… and debug the tests again the stop() method at ArmeriaServerGracefulShutdownLifecycle.java will be called twice (as expected since we wanted to test 2 different Server instances) but at the end of the entire test execution and not at the end of each test suite.

This means that given a sufficiently big project that needs to test different configurations (like the one I’m currently working on) we will eventually reach an out of memory error because all Server instances are only stopped at the end of the execution.

Currently what we are seeing in our tests is the following:

// several log entries stating that an Armeria Server instance is shutting down
Error:  Surefire is going to kill self fork JVM. The exit has elapsed 30 seconds after System.exit(0).

My guess is that Spring’s Application Context is bound to the lifecycle of the JVM (shutdown hook or something similar) and Armeria is bound to Spring’s Application Context lifecycle which explains why it is stopping when Spring stops as well.

Is this the intended behaviour? Shouldn’t Spring stop the current Armeria Server before launching the new one or am I missing a piece of configuration?

Issue Analytics

  • State:open
  • Created a year ago
  • Reactions:1
  • Comments:6 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
minwooxcommented, Aug 19, 2022

Thanks for the report, @jmadureira! @kojilin Would you mind taking a look at this? 😄

0reactions
minwooxcommented, Sep 13, 2022

My 2 cents is that this should be included in the spring-boot examples otherwise someone will eventually bump into this problem.

That’s a good suggestion. Are you interested in fixing the example?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Testing with Spring Boot and @SpringBootTest - Reflectoring
A tutorial on when and how to use Spring Boot's @SpringBootTest annotation and how to reduce test runtime.
Read more >
Run Spring test cases concurrently not sequentially
1 Answer 1 ... You need to combine @SpringBootTest with maxParallelForks. Annotate your unit tests with @SpringBootTest. @SpringBootTest will boot ...
Read more >
Spring Boot Integration Testing With @SpringBootTest
Spring's test framework caches application context between tests. This mechanism means that if subsequent tests use the same configuration, they ...
Read more >
41. Testing - Spring
By default Spring Boot will put WebDriver beans in a special “scope” to ensure that the driver is quit after each test, and...
Read more >
Guide to @SpringBootTest for Spring Boot Integration Tests
When starting to work with Spring Boot, it's usually the first test annotation to stumble over. That's because many testing tutorials use it, ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found