From d1ff38853cf5c5a5549358ad2c1479f998c003eb Mon Sep 17 00:00:00 2001 From: TJKoury Date: Tue, 25 Oct 2016 11:01:25 -0400 Subject: [PATCH] Updated Architecture: Cluster Multi Process (markdown) --- Architecture:-Cluster---Multi-Process.md | 1 + 1 file changed, 1 insertion(+) diff --git a/Architecture:-Cluster---Multi-Process.md b/Architecture:-Cluster---Multi-Process.md index 782ad6c..8440ffd 100644 --- a/Architecture:-Cluster---Multi-Process.md +++ b/Architecture:-Cluster---Multi-Process.md @@ -23,6 +23,7 @@ Communication from the Worker processes to the Master is handled via IPC. |red/runtime/storage/localfilesystem.js|Modified to only allow Master to log.| |settings.js|Modified to expose the cluster module in function nodes, also provides the default setting for number of Workers.| ##Issues +- [ ] **Clustering Admin Interface**. To make it practical to keep the default behavior of using the admin httpServer as the primary interface for http / websocket nodes, the entire admin interface must be used in cluster mode. Running a server on the master process restricts the amount of data that can be serialized/deserialized in IPC as multiple workers are handling the requests that originate and end in the master process. **However**, running the admin interface in worker threads also poses it's own problems. As any worker process might be the one that a web client connects to, all messages headed to the browser must be serialized and sent to all workers. This will cause a massive increase (n * workers -1) in the amount of data handled to inform the admin interface, from node registry events to node status events, debugging, etc. - [ ] **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](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.