From a4e7256786eb0690361868f0d71c832169ba47a3 Mon Sep 17 00:00:00 2001 From: TJKoury Date: Thu, 20 Oct 2016 17:38:28 -0400 Subject: [PATCH] Updated Architecture: Cluster Multi Process (markdown) --- Architecture:-Cluster---Multi-Process.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Architecture:-Cluster---Multi-Process.md b/Architecture:-Cluster---Multi-Process.md index 45d5c1b..f1f7cd2 100644 --- a/Architecture:-Cluster---Multi-Process.md +++ b/Architecture:-Cluster---Multi-Process.md @@ -11,7 +11,9 @@ Communication from the worker processes to the master is handled via IPC. |red.js| Controls instantiation of admin server, api , core admin UI, and static server.| ##Issues -- [ ] **Config node capabilities**. +- [ ] **Modified nodes**. As nodes are capable of binding ports, listening to file-system events, spawning other processes, etc., simply clustering by forking can lead to serious issues. There appear to be two options: modifying the nodes to play nice, or build in strict limitations on what nodes can do. + +- [ ] **Config node capabilities**. Currently, config nodes (and certain nodes like TCP) are allowed to bind ports, meaning that if flows are loaded equally in the master and child processes, the master process will listen on that port, and then block the port from being [bound specifically to distribute incoming to workers](https://github.com/nodejs/node/blob/master/lib/cluster.js#L116). Some nodes might be run only in the master (inject) and [serve events to workers based on a round-robin approach](https://github.com/TJKoury/node-red/blob/cluster/clusterRED.js#L88). Limiting config nodes to run only on worker processes, then moving any code that could cause issues into a config node, could be a standardization solution to this issue. - [ ] **Static server**. Run single-processed on master, or instantiate new static path on each clustered http-server instance? Does this option reside in the http-server config node menu, along with a static path?