StackSaga Cassandra-Agent Configuration Properties
Stacksaga Cassandra agent does support both eureka based and kubernetes based environments. There is a list of common configuration properties for both and as well as there are some configuration properties specific to eureka and kubernetes.
Common Configuration Properties
| Property Name | Default Value | Type | Description |
|---|---|---|---|
|
|
|
There are two profiles available as |
|
|
|
The name of the agent application. |
|
|
|
The port of the agent service. |
NOTE: Due to Agent service internally uses default {data_source} for managing connection, It can be configured the datasource properties in the same way that spring boot provides. |
|||
|
- |
|
The name of the target service. (The transactions are fetched based on this name from the event-store) |
|
- |
|
The host name of the target service that retry tasks should be submitted to. |
Thread-Pool of Parallel Processing: Agent service uses a thread-pool to process the retry tasks in parallel. Each thread is responsible for processing one or more partitions (virtual nodes). |
|||
|
|
|
how many local partitions (virtual nodes) should be created to process the retry in parallel. by default, it is set to the number of available processors. the entire token range is divided into these partitions, and each partition is assigned to one thread. |
|
|
|
how many records should be fetched in one batch from the event-store when retrying the failed transactions. |
|
|
|
how often the retry task should be executed. every 2 minutes triggers the retry task based on UTC time. |
|
|
|
the delay between each retry attempt for internal service communication failures. |
|
|
|
the maximum number of retry attempts for internal service communication failures. |
Eureka profile Based Configuration Properties
If you are in the Eureka environment, then you have to configure the following configuration properties.
Property Name |
Default Value |
Type |
Description |
|
- |
|
What is the type of this agent? Whether this agent is leader or follower. As per the architecture, one |
If the instance is deployed as leader, the following configuration properties should be provided. |
|||
|
- |
If the instance is a leader one, the instance-id should be a static value. The recommended pattern is |
|
|
|
int |
what is the core size of the thread-pool for communicating with other followers. |
|
|
int |
what is the maximum size of the thread-pool for communicating with other followers. |
|
|
long |
Time limit for which threads may remain idle before being terminated. |
|
|
long |
how long time the token range should be updated based on the available instance data by the leader. the default value is 10 minutes. |
|
|
long |
How long time the token range should be remains valid. This valid time is sent to the follower instance along with the token range, and their executions will be based on this time. The default value is |
If the instance is deployed as follower, the following configuration properties should be provided. |
|||
|
- |
If the instance is a slave instance, it should be provided the master’s stick-id to identify their leader. |
|
Kubernetes profile’s Configuration Properties
Property Name |
Default Value |
Type |
Description |
|
|
|
the namespace that the application is deployed in the kubernetes cluster. |
|
|
|
the topology name of the zone in the kubernetes cluster. |
|
|
|
the topology name of the region in the kubernetes cluster. |