The maximum number of old events to delete with a single SQL DELETE statement. If more old events need to be deleted, multiple statements will be used.

The cron specification for when old events get deleted. For the supported format, see the Javadoc of Spring method org.springframework.scheduling.support.CronExpression#parse(java.lang.String).

Whether this application deletes old events from the database, when they are no longer needed according to the configured time-to-live (TTL). For cleaning up old events, it is sufficient to enable this option for only one application like the 'User Changes App'.

The time to live for events, after which they are considered old, no longer needed, and become subject to deletion.

The time to wait between fetching events from the database.

The maximum delay between fetching an event from the database, and publishing it to listeners. An event is delayed, if another event with smaller ID could not be fetched from the database yet. This may happen if there's a gap in the auto-incremented IDs of already fetched events. If the missing event is received within this maximum delay, then events can still be published to listeners in the order of their event IDs.

The maximum number of fetched events, after which an event with smaller missing ID will not be fetched anymore, even if the time in 'caplist.event.max-wait-missing-id' has not yet elapsed. This limit is used to avoid repeated fetching of large amounts of events.

The maximum time to wait for a missing event to still appear and to retry fetching it, after events with higher event ID have already been published to listeners. Such a gap in the auto-incremented IDs of fetched events can be temporary if stored events become visible in different order, or it can be permanent if IDs are skipped by the database. A gap is considered permanent after this configured time, or if the number of fetched events with higher ID has exceeded the value configured in 'caplist.event.max-lag-missing-id'.