Axon 4.x.x upgrade -> Single Event processor for all events

Hi,

We are in the process of updating our application from Axon 3.4.1 to Axon 4.0.3. In our application we have a single Subscribing event processor that handles all events (except for saga’s). This works fine but we can’t seem to reproduce this behaviour in Axon 4.

As far as we can see, Axon 4 creates a separate processor for each module/package instead of using the one we provide to it. We use the method: ‘registerEventProcessor’ for this.

In the documentation it states: “The Configuration API allows you to configure other strategies for assigning classes to processors, or even assign specific instances to specific processors.”. There are however no examples of how to achieve the scenario we are looking for.

Does anyone have any pointers/ideas how we can achieve the same behaviour in Axon 4 as we had in Axon 3?

Thanks!

Kind regards,

Bob

Can you post your code from what you were doing in Axon 3.3 and what you are trying in Axon 4?

Hi,

In version 3.4.1 we have following part of the configuration. We use our custom extension of the SubscribingEventProcessor an we register it and assign all handlers to this processor.

@Autowired
public void configure(EventProcessingConfiguration processingConfiguration, EventHandlingConfiguration handlingConfiguration,
                      ViewModelCleaner viewModelCleaner) {
    processingConfiguration.registerTokenStore("JpaTokenStore",
                                               configuration -> new JpaTokenStore(configuration.getComponent(EntityManagerProvider.class),
                                                                                  configuration.serializer()));

    processingConfiguration.registerHandlerInterceptor(REPLAYABLE_PROCESSOR_NAME, configuration -> new RunAsSystemMessageHandlerInterceptor());

    processingConfiguration.registerEventProcessor(
            REPLAYABLE_PROCESSOR_NAME,
            (name, configuration, eventHandlerInvoker) -> createReplayAbleSubscribingEventProcessor(configuration, name, eventHandlerInvoker,
                                                                                                    viewModelCleaner)
    );
    handlingConfiguration.assignHandlersMatching(REPLAYABLE_PROCESSOR_NAME, NORMAL_PROCESSOR_PRIORITY, SELECT_ALL_EVENT_HANDLERS_PREDICATE);
}

Looks like in Axon 4 EventHandlingConfiguration class was removed and instead of EventProcessingConfiguration we can use now
During upgrade process we first of all tried to keep this behaviour. New configuration looks like

@Autowired
public void configure(EventProcessingConfigurer eventProcessingConfigurer,ViewModelCleaner viewModelCleaner) {
    eventProcessingConfigurer.usingSubscribingEventProcessors();
    eventProcessingConfigurer.registerTokenStore("JpaTokenStore",
                                                 configuration -> JpaTokenStore.builder()
                                                         .entityManagerProvider(configuration.getComponent(EntityManagerProvider.class))
                                                         .serializer(configuration.serializer())
                                                         .build());

    eventProcessingConfigurer.registerHandlerInterceptor(REPLAYABLE_PROCESSOR_NAME, configuration -> new RunAsSystemMessageHandlerInterceptor());
    eventProcessingConfigurer.registerEventProcessor(
            REPLAYABLE_PROCESSOR_NAME,
            (name, configuration, eventHandlerInvoker) -> createReplayAbleSubscribingEventProcessor(configuration, name, eventHandlerInvoker,
                                                                                                    viewModelCleaner)
    );

    // Part of assignment of handlers. We are not sure if it makes sense
    eventProcessingConfigurer.assignProcessingGroup("caple-processing-group", REPLAYABLE_PROCESSOR_NAME);
    eventProcessingConfigurer.assignHandlerTypesMatching("caple-processing-group", NORMAL_PROCESSOR_PRIORITY, SELECT_ALL_EVENT_HANDLERS_PREDICATE);

}

Please look at it and let us know what do you think about it.

Thanks in advance
Anna

Hey folks,

Your usage is quite interesting and made us think about our current approach. I’ve created a ticket in which is explained how the current assigning works and how it might be changed. Take a look and please comment on it!

Regarding your current problem, the easiest way to solve it is to use assignHandlerInstancesMatching method of EventProcessingConfigurer.

Hope this helps!

Cheers,
Milan

Hi Milan,

Thanks for the proposed solution, in the end we solved it in a slightly different way using the following method:

eventProcessingConfigurer.byDefaultAssignHandlerInstancesTo((o) -> PROCESSING_GROUP);

This also causes the correct behaviour.

We will have a look at the ticket you created.

Kind regards,
Bob

Hi Bob,

I’m glad you managed to resolve your issue. Please take a look at the ticket to see how the ordering of matchers is organized and it will give you an idea how to use them.

Cheers,
Milan

Hi Milan,

I don’t know if it’s planned but adding this kind of information to the documentation would be very helpful ! What do you think ?

Cheers,
Jerome

Hi Jerome,

You’re right! Just added a ticket. Thanks for pointing out!

Cheers,
Milan