Vert.x Event Bus request-response timeout behavior in clustered environments

Timeout and Eviction Behavior

In Vert.x 4.x, the Event Bus generally waits for the defined request timeout to expire before triggering the failure handler, even if the cluster manager detects a node failure. The system does not typically provide an immediate, guaranteed trigger to the sender's failure handler the moment a remote node is evicted from the cluster.

Likely Explanation of Behavior

The request-response pattern relies on a sender-side timer. When a request is dispatched, the sending node stores the pending reply state (associated with a unique message ID) and starts a countdown based on the provided timeout. While the cluster manager (e.g., Hazelcast or Infinispan) tracks node membership, the Event Bus transport layer does not always propagate a "node-lost" event directly into the specific pending request's lifecycle.

Consequently, the sender usually cannot distinguish between a handler that is processing slowly and a node that has crashed; both scenarios result in the sender waiting until the timeout is reached, at which point the failure handler is invoked with a timeout error.

Pending Reply Cleanup

Pending reply state is cleaned up in two primary ways:

• Successful Reply: The arrival of a response cancels the timer and removes the state.
• Timeout Expiration: Once the sender-side timer expires, the failure handler is called, and the pending reply entry is purged from the sender's memory.

If a node fails before the timeout, the memory on the sender remains occupied by the pending request until that timer expires. This is why excessively long timeouts in high-throughput clustered environments can lead to increased memory pressure.

Verification Steps

To confirm the specific behavior of your cluster manager and Vert.x version, perform the following test:

1. Deploy a clustered Vert.x application with a known request timeout (e.g., 5000ms).
2. Send a request from Node A to Node B.
3. Forcefully terminate the JVM of Node B (kill -9) immediately after the request is sent.
4. Log the exact timestamp of the node-eviction event (via cluster manager logs) and the timestamp when Node A's failure handler is triggered.

If the failure handler fires significantly after the eviction, the system is relying solely on the sender-side timeout.

Diagnostic Detail Needed

To provide a more precise answer regarding early failure triggers, please specify which Cluster Manager (e.g., Hazelcast, Infinispan, Ignite) and Vert.x version you are using, as transport-layer integration varies between providers.