The Tracking Event Processor, on the point where it tries to peek for events on the Event Stream, has hard coded to wait for new events for at least 1 second.
If this doesn’t happen, it tries to extend it’s claim on the token.
The peek and extend operations conclude to the shared queries you’ve pointed out.
As pointed out, the 1 second peek interval is not configurable at this moment.
However, your statement that adding multiple TEPs automatically includes multiple occurrences of these queries is also incorrect.
The EmbeddedEventStore, which I am certain you’re using giving the JpaEventStorageEngine, uses the notion of an EventProducer (to append events) and EventConsumers (to provide the Event Stream).
The EmbeddedEventStore is also an implementation of the StreamableMessageSource which is required by a Tracking Event Processor as the source of the Event Stream.
Lastly, it will ensure that, as soon as a Tracking Event Processor reaches the head of the stream, that it will initialize an optimized event consumption process.
In essence, this means that several Tracking Event Processor will retrieve events from the same EventConsumer.
This ensure that the one query which might be heavy wait, the select on the
domain_event_entry, is optimized for you.
Given the above description I hope the concern is alleviated.
If you’re searching for an ever faster way of handling events, I highly suggest you take a look at Axon Server.
It’s characteristics when dealing with event append and event stream publication is definitely more ideal in the long run then a regular RDBMS solution.
Concluding, if your situation proofs to be more technical, a face-to-face call might also be in place.
To that end, I’d suggest to fill in a form on the AxonIQ website for example.
Hope this helps you out Prashanth!