Rebuild projection with subscribing event processor


Is there a way to rebuild a projection which is based on subscribing event processors?

All the events are persisted, so the data to rebuild the projection is available.

With a tracking event processor one can just delete the projection and the tracking token in order to force a rebuild.

How is this possible with subscribing event processors?



I’d say, that a replay as requirement should be part of the projection. The token table of a tracking event processor should be part of the projection too.

For subscribing event processors e.g. a timestamp could be used in the projection table to store the states per timestamp. So you could query per date or rebuild the contents based on all old states.

It is much easier to do this using tracking event processor, as you said.

If it is meant for technical reasons (fixed broken projection), than it would totally make sense to have a „give me all events“. In that case I guess it needs to be implemented to read all events and trigger the handler somehow.

These are just my thoughts about it…

Best regards. JohT.

Thanks for answering.

So there is a “give me all events” API in Axon Framework which can be used to notify a certain event handler which is used to build the projection?


Subscribing event processors are executed in the same thread as the command component. This implies that the projection will be updated in the same transaction as your aggregate state update (event applied). It is important to note that the projection/view you are maintaining with this subscribing event processors will be immediately consistent with your command aggregate model. There are some scenarios where this is very valuable, for example set based validation: Sharing the same thread with the command side implies that these projections are belonging to the command side, and you can not separately deploy this event handler/processor. So, it does not scale as the Tracking processor can. Rebuilding/replaying the subscribing projections is usually not a good idea, as these 'immediate` projections are usually used to validate command decisions.

If you really need to do that, you can easily turn your subscribing processor to tracking. It is just a matter of configuration at the end:

        # mode: subscribing
        mode: tracking

Once you are done, you can set it back to subscribing.
Please note that all processors are tracking by default, and you should consider not changing that, except in some cases where you need immediate consistency as described earlier.


1 Like

Thanks, seems to be the best solution.

Im general we prefer tracking event processors, but if you stay in a single module subscribing event processors are an option as you do not have to struggle with eventual consistency which impacts the usability from time to time.

1 Like