3

We have a parent that holds information about many nodes. Each node is separate VM instance, that performs different tasks. parent is like a dashboard for all the nodes.

The parent needs to:

  • send some occasional configuration changes to some node
  • monitor the heartbeat i.e. the health of the node
  • get some statistic data from the node

I would like that node is unaware of the outside world as much as possible. Each node works as a web server, they can have big traffic sometimes.

How to communicate in the best way between the parent and the node?

I was thinking into using files for communication, so parent can set a file with a command on a node file-system, and then to have a dir watcher that reads for such files.

Or to have some event-bus/message-queue in the background, but they are using sockets, so a node may become un-responsive for parents message in case of high-traffic. Or maybe I worry too much?

EDIT

Is there any event/message-bus that offers direct communication between channels, to save the time for broadcasting? In my example, the communication between is always between a parent and single child, there is no need to broadcast. So we could have some messaging like email ;)

EDIT #2 - about communication and traffic

There is one parent (or a cluster that represents one instance of a parent). Number of childs is not determined, it may be any; the goal is to have as much as possible, as long the system works fine. The communication is:

  1. Commands (parent -> child) Low-frequent commands, usually initiated by admin (e.g. "restart", "upload", "reload config"). It goes directly to specific child.

  2. Runtime stats (each child -> parent) Each child notifies the parent about its health (heartbeat) and some minor stats. This does not have to be a real-time communication, as long as the message is transferred under e.g. 10 seconds.

  3. Runtime logs (each child -> parent) Important logs about the traffic and usage. This may be high-volume data as it is important to measure each node, if the computation gets over certain limit we need to be aware of that etc. Again, not real-time, but we need a promptly alert on high computation.

There is no much need of general broadcasting (since childs are not aware of other childs), this is more direct messaging.

igr
  • 10,199
  • 13
  • 65
  • 111
  • how many nodes do you have? what kind of data you are sending from the parent node? – alex Mar 17 '15 at 09:00

2 Answers2

1

I would recommend you to use RMI, since you can implement the methods you're needing to communicate between nodes, making the class you want to comunicate extends the Remote interface.

You'll have to use the rmiregistry at the beginning of the comunication, but then it won't be needed again if you have a "central" node to distribute the references/messages (like in a chat (server/clients) model).

Update: I'm not that advanced to answer your last question, but maybe this links can help you to find out if that's what you need:

1.- Overview

2.- How fast RMI?

Community
  • 1
  • 1
Btc Sources
  • 1,912
  • 2
  • 30
  • 58
  • How robust is RMI in every-day usage with many nodes? How light are the messages? – igr Mar 17 '15 at 08:50
  • for example, I know the mean response time of JMS application increases is far lower than that of RMI application – igr Mar 17 '15 at 08:53
  • Updated with some links @игор, hope the second one can clarify what you need. – Btc Sources Mar 17 '15 at 09:01
1

Perhaps the simplest solution would be to send an http POST to the node to change configuration (especially if it already is a web-server). A heartbeat could just be HEAD request. A statistics gathering request might be a get.

You could use servlet security mechanisms to ensure that the configuration was only changed by the parent.

If you have performance issues, a solution like RMI or ZeroMQ, might be good, but it introduces extra complexity.

A good http client library like this one https://code.google.com/p/google-http-java-client/ would get you a long way.

L. Blanc
  • 2,150
  • 2
  • 21
  • 31