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.
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.
After some experimentation, I found that we are already compatible with Virtual Threads. The TEP uses a
ThreadFactory, which you can configure, like so:
.andThreadFactory(s -> Thread
.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.
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
- 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
Removal of Xstream dependency from axon framework as it has too many vulnerabilities.
Use of google protocol buffers for serialization
@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.