Ring-Coordinator Connector
Overview
The Ring-Coordinator Connector is the supporting module that turns a standard Orchestrator service into a Retry Node in the retry ring architecture.
It connects to the configured Master Ring-Coordinator, looks up an available Slave Ring-Coordinator, connects to that Slave, and keeps the connection alive to receive the ring-partition information needed to execute retry tasks.
Read more in the Retry-Node section for a better understanding.
To turn a standard Orchestrator service into a Retry Node, add the stacksaga-ring-coordinator-connector dependency to the Orchestrator service and configure the connection details of the Master Ring-Coordinator.
The Orchestrator service then connects to the Master Ring-Coordinator automatically and starts receiving the ring-partition information to execute retry tasks.
Dependency Management
<dependencyManagement>
<dependencies>
<dependency> <!--Only for stacksaga dependencies version management-->
<groupId>org.stacksaga</groupId>
<artifactId>stacksaga-bom</artifactId>
<version>1.0.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.stacksaga</groupId>
<artifactId>stacksaga-ring-coordinator-connector</artifactId>
</dependency>
</dependencies>After adding the dependency, configure the connection details of the Master Ring-Coordinator in your application configuration file (application.yml or application.properties).
Configuration Properties
Configure the following properties in your application configuration file (application.yml or application.properties) so the Connector can reach the Master Ring-Coordinator and receive ring-partition information.
Properties shown with a dash (-) in the Default column are mandatory and have no default — you must set them explicitly.
|
| Property Name | Default | Type | Description |
|---|---|---|---|
General |
|||
|
|
|
Whether the Ring-Coordinator Connector module is enabled. Set it to |
Master connection — initial lookup of an available Slave |
|||
|
- |
|
The host of the Master Ring-Coordinator that the Connector contacts to look up an available Slave Ring-Coordinator. |
|
- |
|
The port of the Master Ring-Coordinator that the Connector contacts to look up an available Slave Ring-Coordinator. |
|
|
|
How long the client waits to establish the TCP connection to the Master before failing. |
|
|
|
Maximum number of reconnection attempts on the current connection to the Master after a connection loss. Once this limit is reached, the Connector discards that connection and establishes a brand-new one from the configured host and port — it does not shut down. Building a new connection re-resolves the host, so even though there is a single Master in the cluster, the Connector can pick up a new IP address (working around JVM DNS caching) if the Master was restarted or rescheduled, instead of retrying a stale address indefinitely. |
|
|
|
Initial backoff before the first reconnection attempt after a connection loss. A short delay lets transient issues resolve without causing excessive downtime. |
|
|
|
Upper bound on the reconnection backoff. The growing backoff between attempts never exceeds this value. |
Master connection — retry when no Slave is available in the registry |
|||
|
|
|
Maximum number of retry attempts when the connection to the Master is already successful but its cache currently holds no Slave to serve the request. Here the Master connection stays up — there is nothing to reconnect — so the Connector simply re-requests Slave details from the Master on each attempt until one becomes available, and only then connects to that Slave (governed by the |
|
|
|
Initial backoff before the first retry when no Slave is available. A short delay lets transient issues resolve without causing excessive downtime. |
|
|
|
Upper bound on the no-Slave retry backoff. The growing backoff between attempts never exceeds this value. |
Slave connection — once an available Slave has been looked up |
|||
|
|
|
How long the client waits to establish the TCP connection to the looked-up Slave before failing. |
|
|
|
Maximum number of reconnection attempts on the current Slave connection after a connection loss. Once this limit is reached, the Connector stops retrying that Slave and goes back to the Master to look up a different Slave — the Master itself is healthy; only this Slave connection has failed. If the Slave is down or unhealthy it has very likely already been dropped from the Master’s registry too, since the Master keeps that registry updated as Slave connections come and go, so the lookup returns a fresh, healthy Slave. |
|
|
|
Initial backoff before the first reconnection attempt after a connection loss. A short delay lets transient issues resolve without causing excessive downtime. |
|
|
|
Upper bound on the reconnection backoff. The growing backoff between attempts never exceeds this value. |