Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1466719200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[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