Axon Framework 4.8.0 release

Axon Framework 4.8.0 contains many new interoperability options with other libraries, such as new caching solutions (EhCache3) and more scheduler implementations (JobRunr Pro and db-scheduler) for deadlines and scheduled events. In addition, the usability of the dead-letter queue feature is improved by providing a JDBC and multi-tenant implementation, as well as making it easier to configure.

These updates allow developers to finetune their applications, improve reliability, and leverage advanced caching capabilities.
This blog post will explore the new features, including the DeadLetterQueueProvider, db-scheduler implementations, and the EhCache3Adapter.

Note that this is not an exhaustive list of all adjustments made in 4.8.0. For those, we refer to the release notes.

Improved Dead-Letter Queue configuration with DeadLetterQueueProvider

Axon Framework 4.8.0 introduces the ability to register a DeadLetterQueueProvider on the EventProcessingConfigurer.
It’s a function that, depending on a processing group, can either return null or create a new sequenced dead-letter queue.
For example, you can build a collection with the processing groups you want to use the dead-letter queue with and use that with this function.
This way, you have the configuration of the dead-letter queue in one place, as opposed to setting a dead-letter queue for each processing group separately.

Note that it’s still possible to register a dead-letter queue for a specific processing group that will have prevalence over the provider.
When you use Spring Boot, we will set a default provider, making it possible to configure using a dead-letter queue with a single property.
For example, for a processing group called transactions, the property to enable the dead-letter queue would axon.eventhandling.processors.transactions.dlq.enabled.
If set to true, it will configure the provided dead-letter queue for the transactions processing group. 

Although this allows you to enable a dead-letter queue for any processing group with ease, we advise you to only do so for specific groups, as dead-letter queues may introduce a lot of overhead to a system.
A fair candidate to enable dead lettering behavior is on processing groups, for which stopping to process events can have serious consequences for your business.
Concluding, make sure you have proper monitoring in place when introducing the dead-letter queue so that you can validate whether the impact merits the tool.

If you don’t use Spring Boot or want to change the default provider, you can do so with the following configuration:

    processingConfigurer.registerDeadLetterQueueProvider( processingGroup -> { 
        //dlqEnabledGroups is a collection with the groups that should have a dlq
        if (dlqEnabledGroups.contains(processingGroup)) { return
          config -> JpaSequencedDeadLetterQueue .builder()
          .processingGroup(processingGroup)
          .entityManagerProvider(config.getComponent(EntityManagerProvider.class))
          .transactionManager(config.getComponent(TransactionManager.class))
          .serializer(config.serializer()) .build(); } else { return null; } } );

As you can see, it becomes much easier to configure the dead-letter queue. You could also always return the function, enabling the dead-letter queue for all processing groups.

Dead-Letter Queue implementations

To persist failed events in the dead-letter queue, Axon Framework now offers a JDBC implementation, the JdbcSequencedDeadLetterQueue.
Like the existing JPA variant, it stores the letters in the database.
Compared to the JpaSequencedDeadLetterQueue, it offers fine-grained customization options for the column names, executed PreparedStatements, and how to convert a ResultSet, to name a few.

Next to the JdbcSequencedDeadLetterQueue, we added a MultiTenantDeadLetterQueue to the multi-tenancy extension. 
The multi-tenant version delegates operations to specific dead-letter queue instances per tenant automatically by carrying tenant information in the UnitOfWork and messages.
As such, it works similarly to all other multi-tenant infrastructure components in the multi-tenancy extension.

Deadline Manager and Event Schedulers

Axon Framework offers an EventScheduler and DeadlineManager abstraction to schedule events and tasks for the future.
Both need a central component for production use to ensure that when an event is scheduled by an application instance, it will still be published when the instance goes down. 

In the 4.8.0 release, we added a DbSchedulerEventScheduler, which can be used to schedule events.
db-scheduler is easy to set up, but note that it (currently) only works with SQL databases.
On top of that, db-scheduler also offers a Spring Boot starter.
As such, we added our Spring Boot auto-configuration in the mix, which automatically constructs a DbSchedulerEventScheduler when db-scheduler is detected on the classpath.

We added two options in this release to further manage deadlines. Axon Framework 4.7.0 saw the introduction of a JobRunr implementation. However, the methods to cancel all deadlines with the same name or with the same name and scope were impossible to implement without JobRunr Pro.
If you use JobRunr pro, you can use the new JobRunr extension that has a performant implementation of those methods.

Integration of EhCache 3 

Axon Framework 4.8.0 introduces the EhCache3Adapter, enabling seamless integration with EhCache 3, a popular caching solution.
The EhCache3Adapter is an AbstractCacheAdapter implementation, providing a usable solution for Axon.
With the ability to leverage EhCache 3's advanced features, you can now incorporate efficient and high-performance caching into your event-driven microservices.
Please note that the EhCache3Adapter is only compatible with EhCache 3 and has a different group name than the previous EhCacheAdapter!
At the same time, we deprecated the previous version since support for EhCache 2 will be dropped later this year.

Conclusion

Axon Framework 4.8.0 introduces implementations to manage deadlines and eases dead-letter queue configuration.
Furthermore, the integration of the EhCache3Adapter provides a seamless way to leverage EhCache 3's advanced caching features, boosting the performance of event-driven applications.
Upgrade to Axon Framework 4.8.0 to leverage these enhancements and take your event-driven architecture to the next level.

Note that not all the improvements and fixes are mentioned here, so please see the release notes for all the changes!

Moving forward, the Axon Framework team will focus their efforts on Axon Framework 5.
Although our focus may shift, we will still provide bug fixes when necessary. Regardless of the above, we still welcome any pull requests to improve Axon Framework 4!
We may be moving most of our development time to Axon Framework 5, but we are not abandoning 4.