Vert.x 4 Cluster Manager transition to modular discovery mechanisms

Modular Discovery and Heartbeat Behavior

The transition to modular discovery in Vert.x 4 does not introduce a new core Vert.x timeout for node heartbeat detection. Instead, the Vert.x runtime delegates all failure detection and heartbeat timing to the specific ClusterManager implementation being used.

Implementation-Specific Timeouts

Because the ClusterManager is now a pluggable component via VertxOptions.setClusterManager, any change in heartbeat behavior when moving away from Hazelcast is a result of the new manager's internal defaults, not a change in the Vert.x core. For example, if you switch from Hazelcast to Infinispan or a custom implementation, you must configure the timeouts within that specific provider's configuration object.

Custom Cluster Manager Constraints

To maintain the Event Bus's request-response delivery guarantees when implementing a custom cluster manager, the implementation must satisfy these constraints:

• Consistent Membership View: The manager must ensure that node join and leave events are propagated reliably across all JVMs to prevent messages from being routed to dead nodes.
• Distributed State Visibility: The manager must provide the necessary distributed data structures (maps/sets) required by the Event Bus to track address ownership.
• Deterministic Failure Detection: In high-latency environments, the manager must distinguish between a slow network and a crashed node to avoid premature member eviction, which triggers expensive cluster re-balancing.

Delivery Guarantees and Network Latency

It is important to note that a ClusterManager alone cannot enforce strict end-to-end request-response delivery guarantees. The manager handles membership; the Event Bus handles routing. In high-latency or partitioned (split-brain) scenarios, delivery guarantees must be managed at the application level using timeouts, retries, and idempotency keys.

Verification Steps

To verify the behavior of a new discovery mechanism, use the following approach:

1. Deploy a small cluster and simulate network latency using a tool like tc (traffic control) on Linux.
2. Log membership events to observe the exact duration between a node failure and the cluster's detection of that failure.
3. Compare these timings against the previous Hazelcast configuration to identify the delta in detection latency.

Diagnostic Detail Required: To provide a more specific configuration recommendation, please specify the target ClusterManager implementation (e.g., Infinispan, Zookeeper, or a proprietary custom build) and the specific Vert.x 4.x minor version in use.