Problems with JDBC TrackingProcessor when reading from SequencedEventStore?


we have recently switched our application to use JDBC EventStore and TrackingTokens and it seems, we are getting strange behavior that i just don’t understand fully. The caveat is, that we are actually using two event stores and combine them with a SequencedEventStorageEngine. Only some of the services in our architecture read from both Stores and some only read from the one they are attached to.

Now I think this may cause problems with the GapAwareTrackingTokens, which to my understanding store the progress of the globalIndex, but since there are two event stores, there are two global indexes. It may be that on new applied events the sequenced event store combines both global indexes to write a new entry to avoid the indexes to clash, but since some services read only from one store they are not aware of another event store and conflicting indexes. We had the behavior, that inserts into the event store were creating large gaps, and the tracking processors were unable to catch up, but we are not sure if this behavior is related. We also still use 3.0.5, and there is an improvement in 3.0.6 to deal with gaps in the event store - i just wanted to make sure first, that our setup is feasible.

Now my questions are:

  • is it possible to use SequencedEventStore with TrackingProcessors and GapAwareTrackingToken?
  • do all services applying events to one store need also use the SequencedEventStore?
  • do globalIndexes get spread between both stores, or would this mean TrackingProcessors reading from one store could only process from one index, other Processors only from the other? (we do have multiple TrackingProcessors per service)
  • If any of the above create serious issues, what would be the best practise to solve it?

Kind regards,
Lars Karschen

On thing to add - the original conception of SequencedEventStore seems to be a historic Stream of events, and a current one. But in our case, both Stores receive new Events all the time…

Hi Lars,

sorry for the late reply. For some reason, this mail fell off the radar.

The SequenceEventStore is meant for use in scenarios where events are migrated from an operational database to an archiving one, where the tracking tokens are staying the same. If you have two distinct event stores, and would like to read from both, the SequenceEventStore is not the component you’d be looking for.
If you want to track events from two sources, then you’d need a TrackingMessageSource that delegates to two other sources, and creates a token that combines the two underlying tokens. Such a component currently isn’t part of Axon itself, but we are considering including it at some point. Demands for it seem to surface more frequently, nowadays.

Hope this answers your questions.