How much the EventBus takes away from the server, in terms of resources.

[Igor Spasić]

Let's say that I have few independent VertX nodes, each one for different purpose. We need to be able to control the nodes (start, stop, configuration-ready...) from a central vertx app.

Should we use EventBus for connecting the server with all the nodes? Would that be possible scenario?

How much EventBus uses for itself - i guess, it uses socket for communication between vertx instances. If I have a huge traffic on one node, can I still access it via EventBus?

Did I get this correctly :)?

Thank you!

[Jordan Halterman]

If you want a pure Vert.x solution, you could do that. Just start a Vert.x verticle on each node that listens for messages from the coordinator node and deploys/undeploys verticles. If you do this, you'll have to be sure to keep track of addresses in the master node (assuming you want to be able to deploy a specific application to a specific node) and deployment IDs in each slave node's supervisor (or whatever you want to call it).

Really, though, depending on your use case (scalability, fault tolerance) it could require a lot of development to get right. The Vert.x event bus and the nodes on which you're deploying your applications are unreliable, and you have to build your cluster manager with those limitations in mind. Vert.x handles some of these types of concerns, but there may also be an easier way. If you're looking for anything more than a simplistic solution then I'd recommend looking at a well tested and maintained cluster manager like Mesos:

http://mesos.apache.org

To answer your second question: while it may impact latency, high load on a node should not block you from communicating with that node over the event bus.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.