Migrating From 3.4.3 to 4.9.0, JUnit Failure, TEP, and Threads

Axon Framework
1

Hello, we’re in the middle of upgrading from AF 3.4.3 to 4.9.0 and have come across a change in behavior of how the TEP handles events that’s causing our tests to fail.
When our tests ran in 3.4.3, the TEP would handle an event in the same thread as the unit test so:

  1. our projection annotated with @EventSourcingHandler would call .save() on a JpaRepository and would persist a record to the database
  2. a query that followed in the test would be able to retrieve the object persisted in 1.

In 4.9.0, the message is being handled in a separate thread (the EventProcessor thread) and so the insertion doesn’t happen before the query is made causing the test failures (because the test expected to find the persisted object). If a Thread.sleep is put in the unit test before the query is made, then the object manages to get persisted, the query finds the object, and there is no error.

Is there any way to get the single threaded behavior back for the purposes of running our unit tests or are there any other suggestions? No other changes were made to the configuration.

2

My apologies, it turns out that all that was needed was to add the following to our application.yml configuration to make our Projection a SubscribingEventProcessor (I take it that the default changed):

axon:
  eventhandling:
    processors:
      MyProjections:
        mode: subscribing
        source: eventBus
3

Between Axon Framework 3 and 4, we have indeed switched the default EventProcessor from the SubscribingEventProcessor to the TracingEventProcessor, @ed.park.

Although it’s a little tucked away, the Axon Framework repository contains an API changes file that describes some of the differences between AF 3 and 4. You can find said file here.

By the way, we switched from subscribing to streaming (the TrackingEventProcessor is an implementation of the StreamingEventProcessor) as we see benefit in decoupling the event publishing from the event handling process. Essentially since event publishing/decision making and event processing are typically separate concerns. From a theoretical stance, it’s closer to CQRS as well, in our opinion.

Nonetheless, if your application expects the subscribing format, switching to the SubscribingEventProcessor is reasonable. :+1:

4

Understood, thank you!