Hi Team,
Our Setup details:
Axon version: 4.1.1
Event store: SQL Server 2012
Event storage engine: JPAEventStorageEngine
In case of no events, TEP goes in blocking mode and keeps polling event store every 1 seconds and extending token claim. This statement is inferred from below code snippet, correct me if I’m wrong:
if (eventStream.hasNextAvailable(1, SECONDS)) {
}
else{
tokenStore.extendClaim(name, segmentId)
}
Though functionality works fine, we are bit worried about the performance in long run. This count will multiply if we instantiate multiple TEP(s). Below queries are frequently happening,
select … from domain_event_entry where global_index>? order by global_index ASC offset 0 rows fetch next ? rows only
update token_entry set timestamp=? where processor_name=? and segment=? and owner=?
Is there any way to control this querying interval?
Thanks,
Prashanth
Hi Prashanth,
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!
Cheers,
Steven
Thanks Stevan for the reply. I wasn’t aware of the optimised event consumption in TEP. Frequent peek and extend queries in the log made me wrongly think that Axon makes frequent connection with underlying event store for event consumption. I think this will resolve my concern. Thanks.