When debugging some strange complaints from our query-side models, I noticed that during replay there were some events missing. For example, for one particular aggregate the sequence identifiers of the replayed events would go 1, 2, 3, 4, 5, 6, 7, 135, 136, 137, 138…
(Note: we currently do not use snapshotting)
Perhaps I’m not understanding the code correctly, but it looks like the problem is in JpaEventStore.doVisitEvents(): when fetching from the EventEntryStore, it specifies a batchSize which – I think – actually works as a limit for the total number of rows returned by the underlying JPA query, not the number of rows per batch. In fact it looks like there can only be one batch: given the query it uses, there’s no way for the (JPA) DefaultEventEntryStore.BatchingIterator to get a second batch which continues from where the first batch ended.
So, if the replay should involve more events than the batchSize set on the JpaEventStore, some events will be missing from the replay. Depending on the database platform, chunks of each aggregate’s event sequence could be missing from anywhere in the sequence.
Is this actually a problem or have I missed something?
Obviously the workaround is to set the JpaEventStore batchSize to a very large number. But I think the way the batchSize affects visitEvents() is not expected behaviour: the description for EventStoreManagement.visitEvents() says “loads all events”.
(Allard, if you’re reading this, many thanks for Axon, it is amazing!)