How are events distributed to TEPs?

Imported from Google Groups
#1

Given:
We have multiple TEPs. Some are created over Aggregates, other are simply @Component with @EventHandlers, and finally others still are @Componenet with a name @ProcessingGroup which maps to a kafkatracking event processor with our own segmentation policy.
Some of the detail above is not entirely relevant to the question but may be. The point being is how differently some of the TEPs are defined.

Problem:
We observed a strange behavior where when the application first reboots (but not the first time ever) it will for some period of time not properly dispatch events to the desired TEP.
After debugging things further we have the following question:

If you have multiple TEPs on a single processor instance where each operates in its own thread; does each TEP get a copy of each event/message to try and match against its event handlers? Or does only one TEP consume the event? If each gets a copy how and/or where are the events popped off the buffer?

#2

Hi Michael,

When it comes to receiving a stream of events for a TrackingEventProcessor, we need to have a look at the StreamableMessageSource implementation being used.

The StreamableMessageSource is the source of the events for the TEP, which as the name suggests provides a stream.

When it comes to streaming events from an Axon EventStore implementation, for which I assume you are using the EmbeddedEventStore with some configured EventStorageEngine, the streaming is resolved by an EventConsumer.
By default, the EmbeddedEventStore tries to be smart with the set of EventConsumers it creats to service TEP’s.
As such it will signal when a TEP is at the head of the Event Stream, in which case it will group the given TEP’s EventConsumer with a global EventConsumer to optimize connection to your database.

Although the concept is sound in itself, we have sometimes marked scenarios where particular application set ups did not play to nicely with this idea at all.
To that end we have introduced a boolean called optimizeEventConsumption to the EmbeddedEventStore, which by default is set to true.

For your scenario, I would like you to try and switch the optimizeEventConsumption to false and see if the strange behaviour keeps occurring.
By the way, to switch it off, you can either use the Builder pattern of the EmbeddedEventStore to set it to false, or you can provide a system property called “optimize-event-consumption” upon start up.

Let us know if switching off this optimization resolves the problem at hand.

Cheers,
Steven

#3

This was very helpful!