[16:11:46] <skullcrasher> how is it possible to get a TimeoutException on sending a message (in clustered vertx) when there is no handler/consumer registered on that address
[16:12:10] <skullcrasher> I would expect the ExecutionException with message “No handler for address …”
[16:22:12] <temporal_> skullcrasher it could be possible if there is an unregistration
[16:22:48] <temporal_> i.e the sender node send the message
[16:23:02] <temporal_> but the receiver has no address to fwd because it has unregistered
[16:37:22] <skullcrasher> actually we have the scenario that a verticle is deployed and it has a send() on an other verticle that is not deployed. (so I would assume it should throw the NoHandlerException)
[16:39:10] <skullcrasher> the handler should never be registered imo
[16:47:38] <temporal_> what is your cluster manager ?
[16:48:21] <skullcrasher> default, hazelcast
[22:02:57] <testn> @temporal_ I think I found another potential bug.. I cannot create a consistent repro yet
[22:03:33] <testn> This happens during the undeployment.
[22:04:23] <testn> Basically undeploy() should be able to be called from any thread. However, vertx.undeploy() will use vertx.getOrCreateContext() as a context to execute under DeploymentManager.undeploy()
[22:05:05] <testn> This could race with other httpclient requests since it may not be in the same context as the context which is used to undeploy the verticle
[22:05:44] <temporal_> testn yes, that would be a bug, however this is not the kind of stuff we advocate to do
[22:06:01] <temporal_> testn that being said we should fix anything that is a bug
[22:06:21] <testn> How am I supposed to force the undeploy() to be done on the right thread?
[22:07:04] <testn> I think the threading model of vert.x is trying to follow event loop model of netty. However, by allowing things to be executed from another thread, it creates a lot of unexpected bugs
[22:09:59] <testn> I think “verticleHolder.verticle.stop(stopFuture);” should have been called from “VerticleHolder.context
[22:12:03] <testn> Vertx.deployVerticle does not give back “Context” that the verticle is used so it's impossible to call undeploy() from the right context either
[22:52:10] <testn> @temporal_ ah the problem is actually with HttpServer.close() that it uses “ContextImpl context = vertx.getOrCreateContext();”
[23:34:24] *** ChanServ sets mode: +o temporalfox