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
- Inspect why the redeploy never finished: check cluster manager logs/health and quorum settings
- Fix the verticle's start() so it completes its startPromise promptly; remove blocking calls
- Verify cluster connectivity and increase stability of the network between HA nodes
- 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
- Keep verticle start() non-blocking; complete startPromise promptly
- Monitor cluster manager health/quorum between HA nodes
- Size deployments so redeploy finishes well under 120s
- Check network partitions and GC pauses on HA nodes
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.
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
Related errors
- quorumSize should be >= 1
- Oops!
- Result is already complete
- Class not allowed:
- This Java runtime does not support virtual threads
AI-assisted analysis of eclipse-vertx/vert.x@fb308bd8c3 (2026-09-06).
Data as JSON: /api/errors/5da1d3fa95729610.
Report an issue: GitHub.