Federico Valeri

Thanks. I'll look into that. Do you get the "Failure in stopping Vertx" error message with the stack trace? Can you post here?

@scholzj I think that the delay is due to the `ClusterOperator.stop()` that never completes or is very slow under this circumstances. As a consequence, this consumes all the hard coded...

> I don't think the configurability solves it. I didn't say that configurability solves the issue, it is just an enhancement. > Why not setup the hook only after a...

So [Vertx should timeout if the verticle stop takes too long](https://github.com/eclipse-vertx/vert.x/blob/master/src/main/java/io/vertx/core/impl/DeploymentManager.java#L95), but we should guarantee to always call `stop.complete()` in `ClusterOperator.stop()`. We can simply comment the stop logic to see...

I did a quick test commenting out all CO stop logic except `stop.complete()` and now I don't have the following blocked thread: ``` "SIGTERM handler" #28 daemon prio=9 os_prio=0 cpu=0.71ms...

@scholzj the bug could be in `Vertx.close()`, because `CO.stop()` is never called when the CO verticle fails at startup. One ugly workaround to make it fail fast is to replace...

@scholzj the issue should be fixed now. It is actually due to a Vertx bug, which hangs when you call close with no Verticle deployed. This is exactly the state...

I don't think this is a bug, but we may need to clarify the expected behavior in the documentation. What is happening here is that you are probably creating the...

It's the same reason we need verticle stop. This is simply to ensure these methods are called on a clean shutdown and execute whatever cleanup logic is in there (e.g....

@scholzj I see your point that the operators are stateless, so it's not a big deal if the verticle stop methods are not called, but I think it's still important...