Kubernetes Support Configuration Properties

Description

How many times should attempt to make the request if the request is failed? If you have configured multiple admin urls, the attempts will be distributed evenly among them.

The Constant delay (defined in milliseconds) before every retry attempt.

The maximum limit for the delay between retries (To prevent excessive delays).

The factor by which the delay increases in the exponential policy.

The host name for communicate internally. If the service name is not same as the ${spring.application.name} value, mentioning the serviceHost is required.

The namespace that the application is deployed.

In StackSaga it is necessary to be aware of the location the instance is deployed in the cluster for some reason lime transaction indexing in the event store, retrying etc. therefore stackSaga-kubernetes-support access the kubernetes Api internally to fetch the topology related data. By default the zone data is added under the label topology.kubernetes.io/zone in kubernetes nodes. read more…​

In StackSaga it is necessary to be aware of the location the instance is deployed in the cluster for some reason lime transaction indexing in the event store, retrying etc. therefore stackSaga-kubernetes-support access the kubernetes Api internally to fetch the topology related data. By default the region data is added under the Well-Known label topology.kubernetes.io/region in kubernetes nodes. read more…​

This parameter defines the duration for which a leader lease is held. A leader lease is essentially a lease that grants a node the authority to act as the leader for a specific period. During this lease duration, the leader node is responsible for handling requests and coordinating the actions of other nodes in the cluster. If the leader fails to renew its lease within the specified duration, the leadership is relinquished, and another node can take over as the leader. Setting an appropriate lease duration is crucial to balancing the trade-off between resilience and responsiveness in the system. read more about lease in k8s

The renewal deadline is the deadline by which the current leader must renew its lease to maintain its leadership status. If the leader fails to renew its lease before this deadline, it forfeits its leadership status, and a new leader may be elected. This parameter helps ensure that leadership transitions occur promptly in the event of leader failures or network partitions. read more about lease in k8s

This parameter specifies the interval at which nodes attempt to acquire or renew leadership leases if they are not currently the leader. If a node fails to acquire or renew the lease, it will retry after the retry period has elapsed. The retry period helps prevent excessive contention for leadership and provides a mechanism for nodes to recover from transient failures or network issues. read more about lease in k8s

how much time should be retried when connection is failed?. if the connection is failed continuously for given times, the application will be terminated.

There are two profiles available as eureka and k8s. You can choose one of them based on the deployment environment.

The name of the agent application. It is recommended to use this format: target-service-name-agent. For instance if deploying s agent service for order-service the agent service name will be order-service-agent.

The port of the agent service.

The keyspace(Database) name of the event-store.

The host name of the target service that retry tasks should be submitted to.

The name of the target service. (The transactions are fetched based on this name from the event-store)

Whether the master service acts as the slave or not. If the cluster is small, you can run one instance and run as the master and as well as the slave.

core number of threads in the IOPool.

maximum number of threads in the IOPool.

the time limit for which threads may remain idle before being terminated.

the capacity of the queue.

the maximum time the executor is supposed to block on shutdown.

core number of threads in the IOPool.

the time limit for which threads may remain idle before being terminated.

the capacity of the queue.

the maximum time the executor is supposed to block on shutdown.

how long to wait before retrying the transaction at the beginning of the application.

the fixed rate for retrying the transaction. As per the default value, the transaction retry process is repeated every 60 seconds. The executions are not overlapped even the old execution exceeds the interval

The name of the target service. The number of transactions that should be fetched from the event-store for each batch.