eclipse-vertx/vert.x · critical · VertxException

Timed out waiting for redeploy on failover

Error message

Timed out waiting for redeploy on failover

What it means

processFailover blocks on a CountDownLatch until the failed verticle is redeployed on this node, with a 120-second timeout. If the redeploy future does not complete in time, VertxException('Timed out waiting for redeploy on failover') is thrown.

Source

Thrown at vertx-core/src/main/java/io/vertx/core/impl/HAManager.java:538

    ((VertxImpl)vertx).executeIsolated(v -> {
      JsonObject options = failedVerticle.getJsonObject("options");
      doDeployVerticle(verticleName, new DeploymentOptions(options)).onComplete(result -> {
        if (result.succeeded()) {
          log.info("Successfully redeployed verticle " + verticleName + " after failover");
        } else {
          log.error("Failed to redeploy verticle after failover", result.cause());
          err.set(result.cause());
        }
        latch.countDown();
        Throwable t = err.get();
        if (t != null) {
          throw new VertxException(t);
        }
      });
    });
    try {
      if (!latch.await(120, TimeUnit.SECONDS)) {
        throw new VertxException("Timed out waiting for redeploy on failover");
      }
    } catch (InterruptedException e) {
      throw new IllegalStateException(e);
    }
  }

  // Compute the failover node
  private String chooseHashedNode(String group, int hashCode) {
    List<String> nodes = clusterManager.getNodes();
    ArrayList<String> matchingMembers = new ArrayList<>();
    for (String node: nodes) {
      String sclusterInfo = clusterMap.get(node);
      if (sclusterInfo != null) {
        JsonObject clusterInfo = new JsonObject(sclusterInfo);
        String memberGroup = clusterInfo.getString("group");
        if (group == null || group.equals(memberGroup)) {
          matchingMembers.add(node);
        }

View on GitHub (pinned to fb308bd8c3)

Solutions

  1. Inspect why the redeploy never finished: check cluster manager logs/health and quorum settings
  2. Fix the verticle's start() so it completes its startPromise promptly; remove blocking calls
  3. Verify cluster connectivity and increase stability of the network between HA nodes
  4. Ensure the haGroup/quorum configuration matches across nodes

Example fix

// before
public void start(Promise<Void> p) {
  connectBlocking(); // blocks event loop, redeploy future stalls
  p.complete();
}
// after
public void start(Promise<Void> p) {
  client.connect().onSuccess(ok -> p.complete()).onFailure(p::fail);
}
Defensive patterns

Strategy: retry

Validate before calling

// pre-check cluster health before enabling HA failover
if (!clusterManager.isActive()) log.warn("Cluster manager inactive; failover may time out");

Try / catch

try { deployWithHa(); } catch (VertxException e) { if (e.getMessage().contains("Timed out waiting for redeploy")) { alertOps(); scheduleRetry(); } }

Prevention

When it happens

Trigger: HA failover where clusterManager.deployVerticle (redeploy) never completes within 120s — cluster is degraded, quorum lost, or the deployment future failed to resolve while latch.await(120s) expired.

Common situations: Slow or partitioned cluster managers (ZooKeeper/Hazelcast/InfiniGrid) during failover; the redeployed verticle's start future never completing due to missing resources or blocked event loop; oversized deployment with slow initialization.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors


AI-assisted analysis of eclipse-vertx/vert.x@fb308bd8c3 (2026-09-06). Data as JSON: /api/errors/5da1d3fa95729610. Report an issue: GitHub.