wst.listener.events.
Note:
By default, the Terracotta cache will be used to store event data and hence, the listed below parameters will be absent in the CloudStreams properties file. Use the parameters in the CloudStreams properties file if you want to use a database to store event data.
Important:
Before starting the Integration Server, ensure that the external database to which CloudStreams connects to, is correctly configured with the expected schema objects and other elements in place. Improper database configurations could impact event storing and processing.
wst.listener.events.useDB=true
Indicates that a database is being used to store event data. In the absence of this parameter in the CloudStreams properties file, the Terracotta cache will be used to store event data by default.
If you prefer to use a database to store event data, specify the wst.listener.events.useDB=true property in the CloudStreams properties file:
Integration Server_directory\instances\instance_name\packages\WmCloudStreams\config\resources\wst-config.properties
Retry logic for database connection failures
Applications or services connecting to a database are liable to connection failures due to several reasons like timeouts, incorrect configurations, connection throttling, overloaded resources, or intermittent network errors. Scenarios like these can be easily handled by implementing the retry logic in the CloudStreams properties file.
The following properties can be configured in the CloudStreams properties file to automatically handle transient database connection errors.
wst.listener.events.DB.retryCount
Specifies how many times CloudStreams should retry executing database operations on the event data after the initial connection to the database breaks.
For example, a retry count of 2 indicates that CloudStreams will make two retry attempts to establish a broken connection with the database after the initial failure. The default is 3.
wst.listener.events.DB.retryGap
CloudStreams implements the increasing backoff technique, which means that CloudStreams retries executing database operations on the event data, with an increasing wait time after every consecutive retry attempt. This property can only be used in conjunction with the wst.listener.events.DB.retryCount property.
CloudStreams calculates the wait time after each retry attempt using the following formula: (i)(ms), where
i is the retry count specified in the
wst.listener.events.DB.retryCount property
ms is the retry gap (in milliseconds) specified in the
wst.listener.events.DB.retryCount property
The following table explains how exponential growth is calculated in the CloudStreams error handling framework:
Retry Count (i) | Retry Gap (ms) | Wait time (Exponential backoff formula = (i)(ms) ) |
1 | 2000 | (1*2000) = 2000 milliseconds |
2 | 2000 | (2*2000) = 4000 milliseconds |
3 | 2000 | (3*2000) = 6000 milliseconds |
For example, let's say you have set the value for the wst.listener.events.DB.retryCount property to 3 and the value for the wst.listener.events.DB.retryGap property to 2000, and the database connection breaks for some reason. In such a scenario, CloudStreams will make a total of three retry attempts and wait for 2000 milliseconds, 4000 milliseconds, and 6000 milliseconds between attempts. The default is 1000 milliseconds.