Axon Framework 5 suggestions

Axon Framework
21

With Java 19 Virtual Threads (JEP 425) are added as an experimental feature. As Axon Framewors deals a lot with threads, especially the Streaming Event Processors, it might be interesting to support Virtual Threads.

I am aware of the PooledSteamingEventProcessor which uses ThreadPools to reduce the number of concurrent threads. With Virtual Threads using a thread pool doesn’t make much sense as those threads are lightweight as they are not bound to an OS thread. Not sure, but maybe the good old TrackingEventProcessor could get some traction again.

I don’t not which JDK baseline you are targeting for with Axon Framework 5, but I guess it’s likely that it won’t be Java >= 19. As a consequence you can’t use the Virtual Thread API, but maybe you can provide a way / an API to configure it, so Java 19 applications can benefit from virtuals threads.

1 Like
22

Virtual threads are interesting indeed. It might be a small extension or something I think. Not sure that’s even needed since they should be rather compatible with normal Threads. But they are cheaper, so it might make since to prefer TEP over PSEP.

23

Hello @Oliver_Libutzki,

After some experimentation, I found that we are already compatible with Virtual Threads. The TEP uses a ThreadFactory, which you can configure, like so:

config.registerTrackingEventProcessorConfiguration(configuration ->
                TrackingEventProcessorConfiguration.forParallelProcessing(4)
                        .andInitialSegmentsCount(4)
                        .andThreadFactory(s -> Thread
                                        .ofVirtual()
                                        .allowSetThreadLocals(true)
                                        .inheritInheritableThreadLocals(false)
                                        .name(s + "-", 0).factory()
                                )
        );

Please let me know if you will use it and how it turns out! Locally it seems to work pretty well.

Kind regards,

Mitchell Herrijgers

1 Like
24

Based on my limited reading of virtual threads I foresee the following challenges in making use of them to their fullest with Axon:

  • Usage of synchronized within Axon and Spring

    • From this thread it is clear that it is technically possible to remove this barrier but not a priority for JDK developers at the moment:

      It requires rewriting monitors in Java, and moving any part of the runtime to Java is complicated (e.g. there are interesting interactions with JVMTI, that normally assumes that all Java code is user code). Also, it isn’t a very high priority, as library developers seem happy to remove pinning

    • So the solution is to either change from using synchronized to using locks in every place in Axon and Spring or just wait until they implement the feature - otherwise the virtual thread will just pin anyway when it comes across synchronized.

  • Usage of thread locals
    • The way they seem to be going is to use “extent-local” variables instead.
    • See JEP 429 Extent-local variables
    • Essentially the data is immutable so easily shareable.
  • Extremely large stacks may cause problems
    • The trick here would be to spawn the virtual thread near the top of the stack for a logical task rather than having it create a huge call stack. Spring probably has some cleaning up to do here.

Those are my observations as a casual user. You could probably get further than the current state by using the config given by @Morlack :slight_smile:

3 Likes
25

Removal of Xstream dependency from axon framework as it has too many vulnerabilities.
Use of google protocol buffers for serialization

26

@Ashwini_Kumar We actually thinking of leaving XStream as the default for serialisation. Not sure what would be a good other default, or maybe it would be good not to have a default. I do like Protobuf, but it has some downsides too. Please note that the Framework is open enough to use Protobuf currently.

27

this works fine for events, but query handlers are still run on platform threads, is there a similar way to set thread factory for query processing?

28

I would like to see Avro as serialization format for messages. Especially, the serialization of the metadata and message body should be not two unrelated invocations, but I want to be able to use metadata during deserialization of the message payload.

2 Likes
29

Can we get a Saga serialization store based on Axon Server?

Having support for snapshots by just serializing the aggregate I see no qualitative difference to storage of Sagas by serializing them too.

This would make it easier to build applications which already have Axon Server, since no additional database is required, just for storage of serialization of Sagas. Sometimes the DB is already at place, but if not (especially for the command side) it seems silly to maintain a DB (and backup and management, and ops) of a DB just to store saga state.

1 Like