Spring integration tests with Axon performance issues + db affected by previous test

Imported from Google Groups
1

Hi,
we are runnign Spring Boot 2.1.5 with Axon 4.1, spring boot test and Spock.

In tests we have InMemoryEventStorage configured like

`

@Bean
@Primary
InMemoryEventStorageEngine inMemoryEventStorageEngine() {
    def engine = new InMemoryEventStorageEngine()
    engine
}

@Bean
@Primary
EmbeddedEventStore embeddedEventStore() {
    def store = EmbeddedEventStore.builder()
            .storageEngine(inMemoryEventStorageEngine())
            .build()
    store
}

`

Each integration test inherits from ControllerIntegrationTest

`

@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
@SpringBootTest(webEnvironment = RANDOM_PORT)
@ActiveProfiles("test")
@ContextConfiguration(classes = [IntegrationTestConfiguration])
abstract class ControllerIntegrationTest extends Specification {

    @Autowired
    WebApplicationContext context

    MockMvc mockMvc

    @Autowired
    ObjectMapper mapper

    def setup() {
        mockMvc = MockMvcBuilders
                .webAppContextSetup(context)
                .apply(springSecurity())
                .build()
    }

`

When running the tests with @DirtiesContext, the tests are performing ok, no failures, but each test has performance issues since its waiting till all the processors shut down (see log). Shutting each processor takes about second. While we have dozens of processor, the build time takes couple of extra minutes.

2019-08-03 07:09:07.088 INFO 80745 --- [ main] o.a.e.TrackingEventProcessor : Shutdown state set for Processor 'fi.traficom.lilja.applicationservice.log.projection'. Awaiting termination... e... 2019-08-03 07:09:07.898 INFO 80745 --- [ main] o.a.e.TrackingEventProcessor : Shutdown state set for Processor 'TasksForStateSagaProcessor'. Awaiting termination... ...

When we remove the @DirtiesContext, performance is increased significantly, but some tests are affected by the state of the previous one in the suite, e.g. where the first test flags CreateEntityCommand while the second test’s db is still containing the projection record for the given entity.

Is there any way how to avoid this situation?

I also tried to run the test db in the container (TestContainers), but the result was the same, still can see the records from previous test

Thank you for you help in advance!

2

Hi Tomáš,

Do you need to start up all your Tracking Event Processors for every Test class?
Maybe you can configure your integration tests to only contain the TEP’s which are actually needed for that test class.
Whether this makes sense in your test set up is something you can answer a lot better of course.
Segregating in smaller junks was at least the first thing I thought off.

Added, we have recently received a pull request which parallelizes the shutdown process of the Tracking Event Processor.
It is pretty slow at the moment, as this happens sequentially, thus this PR should speed up things I’d assume.
This enhancement will be part of framework release 4.2, which should be release soon.

A part from breaking down the Integration Test’s environment into smaller chunks and the shutdown-parallelization pull request, I am out of ideas.
I will have a think about it though.

If something pops to mind, I will be sure to share it.

Cheers,
Steven

3

Hello, thanks for answer, the PR (as I checked it) could solve the performance issue with closing the processors, but does not aim to problem while Im required to run the tests with @DirtiesContext annotation.

The tests are still affected by the DB state from the tests run prior the one in question.

4

Hi Tomáš,

That’s indeed correct, you’re still required to do the dirties-context bit in your tests with this set up.
Clearing out the DB state of previous tests is not really an Axon specific thing of course, so I did a little googling for this specific context.

What I found is this blog quite interesting when it comes to his plan of attack.
Additionally, Baeldung has a fair article about how to deal with Spring (Boot) Tests.;
I think I like this approach best, where on the @Before all the caches, databases and Wiremock’s statuses are cleared.

Hope this helps you further Tomáš, let us/me know if it doesn’t.

Cheers,
Steven