All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog and this project adheres to Semantic Versioning.
- allow to override more redis options e.g. to connect to a remote redis-instance via SSH tunnel
multiInstanceProcessing
allows to process the same event type/subtype on multiple application instances- adding logs for shutdown handler of redis connections
- Addressed an orphaned usage of
isRunnerDeactivated
. - Resolved a memory leak in the distributed locking mechanism, which occurred when tracking existing locks for a large number of events.
- Different way of rollback transaction to avoid errors in open telemetry
- Added a suspended status for events. Events in this status won't be processed until changed back to open. Useful for delaying processing when the event isn't ready.
- Added an option to filter tenant lists when checking for open events. Published events are still processed for all tenants, but periodic events can be filtered. Distributed events via Redis that are not part of the current configuration to support DWC use cases where the same app might have different software states.
- replace
req.user.authInfo
withreq.user.tokenInfo
to following the standard of CAP Node.js
- long blocked event-loop could lead to stop processing of events
- Redis integration: PX values for keys require integer input. Values are longer automatically rounded.
- allow redis mode for single tenant applications
- error message if redis is not available during connection check
- add option
crashOnRedisUnavailable
to crash the app if redis is not available during the connection check
- calculation of changed cron patterns
- fix init event-queue if no config
- typo in useCronTimezone
- Added support for defining periodic event schedules using cron expressions, providing more flexible and precise scheduling options beyond simple intervals in seconds. See documentation.
triggerEventProcessingRedis
is a public api now. This can trigger the processing of multiple events via redis.- The central configuration property
publishEventBlockList
has been introduced, enabling the option to disable the publication of the event block list to all application instances. The default value is set totrue
to prevent immediate impact on existing functionality.
- do not initialize the event-queue during cds build/compile steps
- Enhanced the configuration options to specify not only the application name but also the instance index where the event should be processed. See documentation.
- Enable more event publish properties for CDS outboxed service. See documentation.
- In some cases the event broadcasting is delayed if a periodic event can't obtain the processing lock
- Introduced the
retryFailedAfter
configuration option, allowing you to specify the interval (in milliseconds) after which failed events should be retried, provided the retry limit has not been exceeded. - Increased test coverage for fetching authInfo with @sap/xssec
- [outbox] add option to use defined user for event-queue also for CAP outboxed services
- [openTelemetry] avoid empty traces for persist-event-status
- [openTelemetry] more resilient for finished spans
- pass correct tenant to fetch authInfo
- upgrade to @sap/xssec 4
- Testing with cds 8
- Export
WorkerQueue
for monitoring purposes to provide insights into the running load of the application. - JSDocs: added addEntryToProcessingMap for EventQueueProcessorBase
- Enhanced Event Processing: Events will continue to be processed even if the initial processing time is exceeded. Events are now broadcast, allowing different application instances to pick them up. The existing worker queue is used to ensure proper load balancing.
- Added an option to events to specify which application instance should process the event. See documentation.
- Avoid issues with not connected CAP service and open events
- fix clear timeout tenant unsubscribe
- single tenant performance improvements
- better test coverage for single tenant
- Added tracing to redis pub/sub
- Workaround for memory issues due to bug in node.js with timers: nodejs/node#53337
- Bug in CDS 7.9.2: Introduced a bug affecting the instant processing of events. This release includes a temporary workaround until the bug is fixed.
- Memory Leaks: Fixed memory leaks caused by setTimeout returning an object instead of a primitive value
- Telemetry instrumentation for processing events. This can be enabled with the
enableCAPTelemetry
setting. - Additional types.
- allow to use
skipInsertEventsBeforeCommit
inpublishEvent
function.
cds.build.register
may be undefined if@sap/cds-dk
is not installed locally or globally.- Double release of locks for periodic event processing.
- federate unsubscribe events via redis to all application instances and allow to register custom handler for unsubscribe events
- types for event-queue config
- upgrade dependencies
- add xssec authInfo to CDS user also for CAP outbox
insertEventsBeforeCommit
did not commit all events in certain scenarios.
- typescript types for the most common functions
- add subdomain for logging of broadcasting events via redis
- the getter of eventType cuts the periodic event suffix and returns the exact name of the event definition
- [cds-outboxed] Add eventQueue processor, key, queueEntries, and payload to req (can be accessed via req.context._eventQueue)
- Add option
insertEventsBeforeCommit
to improve performance forpublishEvent
. - Add cds shutdown handler to clear existing redis locks before shutdown of the instance.
- [cds-outboxed] Call cds.connect.to for open outboxed events
- Removed authInfo from context.http.req and moved to a full-fledged xssec/xsuaa authInfo attached to context.user.authInfo
- [cds-plugin] return promise for init for cds to wait until plugin is fully initialized
- add to supply custom redis options for create client.
- Reworked periodic processing of all events to be more efficient and to reduce the load on the database and use less database connections.
- Removed support for custom tables. The event-queue now uses always the provided tables.
- Redis reconnects
- In instances of overlapping intervals, periodic events may fall behind schedule.
- Trigger processing again if time is exceeded for event processing.
- removed CF check to enable redis to allow using redis even if process.env.USER is not vcap.
- Default for runInterval changed from 5 minutes to 25 minutes. This is to reduce the load on the database.
- The load of the internal periodic event DELETE_EVENTS is increased to 20 to only process 5 tenants in parallel. This is to reduce the load on the database.
- The max processing time for the event-queue is set to the runInterval.
- option for delayed events for cds outboxed services: documentation
- Delay registration of processors until the database connection is established.
- Log message for blocked events
- Reduce log severity for skip publish redis event as no lock is available to debug
- Only do etag checks after a processing time of 10 minutes to improve performance
- add option to block ad-hoc events. More information in documentation.
- Define priorities for event types. More information in documentation.
- In more cases the global cds.context was not set correctly because the async-chain could break in high load scenarios.
- In some cases the global cds.context was not set correctly because the async-chain could break in high load scenarios.
- The
cleanupLocksAndEventsForDev
parameter allows for the cleanup of all locks and events in progress during server start. This option is intended for development purposes.
- Allow to initialize event-queue without config.yml in case of usage as CAP outbox
- The parameter
runInterval
is checked during init. Only values greater than 10 seconds are allowed.
- Optimize promise handling
- update redis to 4.6.13
- improved logging
- better tenant subdomain caching
- fix registration of db-handler
- option to set user for all created cds contexts and with that the user for updating the managed database fields.
- rework initialization via cds-plugin.
- enable event-queue to work as CAP outbox. The flag
useAsCAPOutbox
replaces the CAP implementation by the event-queue.
- update tenant hash for newly onboarded tenants
- consider running periodic events during update of periodic events
- filter out not invalid tenant ids during processing
- introduced
thresholdLoggingEventProcessing
config variable to adjust logging threshold for event processing documentation
- block the run of periodic events via config documentation
- Add a label to the workerQueue. This will help in understanding which events were throttled in case of throttling.
- The
isEventQueueActive
configuration can now be used to deactivate the runtime processing of all events. - with the function
getLastSuccessfulRunTimestamp
the timestamp of the last successful run for a periodic event can be requested. documentation - Added a performance tracer for periodic events. This will log any processing that takes longer than 50ms.
- Added type and subtype to all performance traces.
- Catch exception during Redis channel subscription
- Endless running if event status open is returned and checkForNextChunk is activated
- Refactored the deletion process for completed events. The default setting for deleting processed events has now been updated to a 7-day timeframe. documentation
- the configuration variable
isRunnerDeactivated
is renamed toisEventQueueActive
. - Reduced the log severity to debug for "Selected event queue entries for processing" during periodic events.
- Removed the
instanceLoadLimit
parameter. The limit is now statically set to 100. The event load should henceforth be specified as a percentage. - Upgrade docs dependencies
- Adjusted workerQueue logging thresholds for waiting time
- fix transaction handling for periodic events
- set cds.context correctly for periodic runner
- logger get setter for better providing own logger
- new documentation
- improve logging
- small bug fixes and improvements for periodic events
- further improve periodic events
- rework of load management and concurrency control
- fixes and improvements for periodic events
- periodic events - use event-queue to process periodic jobs
- cds shutdown - close redis clients
- add redis cluster support
- implementation of delayed events, which allows to publish events that should be processed at a later point in time
- option to disable redis + refactoring of config
- improved HANA integration test setup
- update dependencies
- remove uuid dependency
- example project
- small bug fixes for local mode
- better documentation
- fix redis connect client
- allow to distribute config via redis to instances
- move loggers from top-level to functions because cds 7 has different require orders. This the event-queue to use the custom project loggers
- more resilient for small clock shifts in setInterval
- fix missing catch for isOutdatedAndKeepalive
- Delete event entries after defined number of days
- improve exceeded event handling
- fix model loading for cds-plugin
- fix setInterval clock drift
- new transaction modes
- register rollback of transaction in combination with returning successful event processing status
- first npm release after internal development