eventProcessor in lib - conflict when multiple apps receive events?

Imported from Google Groups
#1

While setting up axon in our microservice project, we want to hide complexity from other services. So basically apps will start to use axon, but the api will suggest “normal” behavior.

We came up with a library that provides a database projection and an eventhandler that deals with receiving events and persiting entities. This library will be included in multiple applications.

Now I wonder … the eventProcessor name of all usages of the eventHandler will be the same … either the package name of the lib or a constant I set arbitrary … I suppose multiple apps using the lib will conflict then, because they form an imlicit eventProcessor group? How can I deal with this? What I would need (supposing I am right with my first assumption) is to have the application name of the app using the lib as part of the eventProcessor name …

Any ideas?

Thanks
Jan

#2

Hi Jan,

The scope of an event processing group is determined by the token store used. So, if each of your applications has its own token store there will be no conflict, even if they are using the same event processor name.

Marc

#3

Hi Jan,
A bit more on the previous answer. When using Axon Server it is quite easy to have each application using its own token store (as this is part of the application’s responsibility).

When using an RDBMS based event store it is slightly more work as you want to have a shared event store, but separate token store tables per application.
The cleanest way to probably do this is to have each application use its own database schema. All tables in this schema are created normally except for the DOMAIN_EVENT_ENTRY (and possibly the SNAPSHOT_EVENT_ENTRY), which is created in one schema only and the other schemas use a view or synonym for this table.

Regards,
Marc

#4

Thanks Marc. The only valid use case for us currently is, that we have the ilb included in an app and persist the projection in the database … so from what I got, this won’t be a problem. I have 2 nodes of of my app running, both connected to the same db, sharing the projection table and the token store. So they form a group and an incoming event will go to either node, be processed and update the projection.

I had concurrent seqment change warnings yesterday and got nervous, but it seems they where a result of my dev setup (axon server dev mode, regularly clean eventStore) and h2-inmemory dbs for the application …

Your advanced answer seems only to be necessary, when I explicitly want my nodes to have separate tokens on an event stream and build non-shared projections … which we will not do (at least for now). So good to know I will not run into trouble.