Multitenant tracking event processor based on Hibernate multitenancy support

[Jakub_Krajewski]

Hi,
I’m experimenting with a PoC to set up an environment that works with hibernate multitenancy support end-to-end. It’s a spring-boot app with the latest axon-framework version without axon-server.
It was pretty straightforward to set it up with the Subscribing event processor because everything is handled in one thread so both the EventStore and readModel in event handlers have access to tenant identifiers and its also easy to keep a separate EventStore per tenant.

Now I’m trying to replace subscribing event processor with a tracking one. I found out that MultiStreamableMessageSource was designed to support multiple event sources and combine them into one.
Based on that I was able more or less to implement something like shown in the picture A bellow.
However, I see two disadvantages:

1. I need to keep the token in a shared “public” schema/DB. I would like to keep the token in a tenant-specific dataSource so it won’t grow too much and to have an easy way to remove it with all tenant-related stuff.
2. Too much workload generated by one tenant for a shared tracking processor could influence other tenants
   Instead of MultiStreamableMessageSource i would prefer to have a dedicated TrackingProcessor per tenant with dedicated TokenStore that operates only on one tenant EventStore.
   The concept is shown in picture B bellow.

I’m not sure if it’s possible and how to configure multiple TrackingProcessors to work with the same Class that implements @EventHandlers.
I can find a lot of information on how to connect multiple EventHandlers to one Tracking processor but not how to do it vice versa.

I see that there is a builder to create a TrackingEventProcessor that could potentially allow to set up handlers manually

TrackingEventProcessor.builder()

but config only allows to register a name, eventStore and config class:

config.registerTrackingEventProcessor(processorName, c -> EmbeddedEventStore.builder()

Any help would be appreciated.

[Steven_van_Beelen]

Hi Jakub,

You haven’t found this information as the general approach to registering Event Handling Components is that it belongs to a single Processing Group.
In turn, it is the Processing Groups which can be paired under a given Event Processor, creating a hierarchy where the TEP really is in charge of:

1. One to more Processing Groups, which

2. Have one or more Event Handling Components
   I don’t have a codified solution ready at hand here to make this work within a single application, although I am confident it can be achieved by going to the bare bones.

Key here is to look at the EventHandlerInvoker, which is the wrapper around 1…n Event Handlers.

It’s this EventHandlerInvoker which is configured on the AbstractEventProcessor (which the TEP implements).

Might it not be simpler to just provide several instances of the Event Handler, per tenant to service?
I understand that it increases the numbers of Event Handling Components quite some, depending on how many tenants you want to serve on this one application of course.

Note that the MultiStreamableMessageSource is there to combine several distinct event streams into one stream from the perspective of a TrackingEventProcessor.
It could thus be used to combine several contexts (when looking at multi-context, like supported by Axon Server), or to combine several tenant event streams to be handled by a single TEP.
From what you have been describing I don’t have the feeling the MultiStreamableMessageSource as what you need immediately right now, hence why I am pointing this out.

By the way, the multi-context support in Axon Server is pretty often used to allow for multi tenant support within your Axon applications.
Might be worth having a look at that, if this proves to be too big a configuration effort.

That’s my two cents, hope this helps!

Cheers,
Steven

PS. It is important to note that this mailing list will be discontinued as specified in this thread.
The thread also specifies where to look further for help when it comes to Axon.