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?