[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