Missing events issue when tracking events from multiple aggregates in a single read projection

Imported from Google Groups
#1

I’ve stumbled upon an issue when tracking events from multiple aggregates in a single read projection.

My config (mostly defaults, running on single node):

  • Spring Boot 2.0.3

  • Axon 3.3.2

  • MongoEventStorageEngine

  • MongoTokenStore

  • TrackingEventProcessor

The scenario:

  1. Aggregate A receives a command and applies an event E(A) at time T0. However, before returning from the command handler a delay is introduced (Thread.sleep).
  2. While the above thread is still sleeping, aggregate B receives a command and applies event E(B) at time T1.
  3. The command handler in aggregate B returns.
  4. The read projection P event handler method for E(B) is called.
  5. The command handler in aggregate A returns.
  6. The read projection P event handler method for E(A) is never called.

The order of the events stored in mongo is:

  1. E(B), timestamp = T1
  2. E(A), timestamp = T0

If I delete the tracking token and restart the application the event handlers in P are called in the timestamp order:

  1. P: E(A)
  2. P: E(B)

Any help or guidance would be greatly appreciated.

Thanks,
Faik

#2

Hi Faik,

MongoDB doesn’t have an auto-increment kind of value. To make sure all events are processed, Axon uses a trackingToken for mongo that keeps track of the events that occurred in the last second (by default). If you sleep is longer than one second, it’s possible that the Tracking Processor doesn’t see your event, as it doesn’t look back that far, by default.

You can change this setting by configuring a StorageStrategy for your MongoEventStorageEngine. Basically, you have a DocumentPerCommitStorageStrategy and a DocumentPerEventStorageStrategy. Both allow you to provide a “lookBackTime”.

Note that, when starting new Axon based projects, we highly recommend using a relational database as Event Storage Engine. Their overall performance (not only measured in time) has proven to be the best for this usecase. But of course nothing so far beats AxonDB…

Cheers,

Allard

#3

Hi Allard,

Thank you, that made things much clearer!

On a side note, I actually switched over to mongo after reading this in the Axon docs:

MongoDB is a document based NoSQL store. Its scalability characteristics make it suitable for use as an Event Store.

Perhaps you could expand a little on in which circumstances MongoDB as event store may be preferable to a relational db (if ever)?

Cheers,
Faik

#4

Hi,

in general, we recommend using a relational database for an event store, for the best overall experience. MongoDB may be faster for appending events, but the tracking processor has some drawbacks, as there is no notion of general order between documents. That’s why the tracking tokens for MongoDB backed event stores use this lookbacktime concept.

Hope this helps.
Cheers,

Allard