Hi ,
I am working on a flow on DB2 which uses ui control node in multiple places to show/hide groups.
Periodically, i find that the dashboard becomes unresponsive .
And i see below error in the console.log of NR run.
21 Mar 04:44:28 - [info] [ui-base:XXXX] Disconnected 17FeqNVHwXGEK5CRAAAB due to transport close
(node:46476) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 disconnect listeners added to [Socket]. Use emitter.setMaxListeners() to increase limit
(node:46476) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ui-control listeners added to [Socket]. Use emitter.setMaxListeners() to increase limit
21 Mar 04:45:39 - [info] Stopping modified nodes
While it says - what to do - not clear where this needs to be set.
Any help appreciated.
@SandeepA
That warning is a known issue for both the ui-control an and ui-event nodes. They keep adding listeners to the socket.io websocket for every node, instead of reusing a single listener. Socket.io gives that warning if more than 10 listeners are added.
To ged rid of that there are 2 options:
- Refactor the code to use one listener.
- Analyze whether all listeners are cleaned up correctly and increase the maximum allowed listener count
So it 'might' be a leak, but we don't know that yet.
It might in your case also be caused by other root causes, e.g. by pushing too much data to the ui-chart node.
Bart
Let me try that.
Where can increase max allowed listener count ?
Don't do this, just use link nodes to send the output of one ui-control to wherever you need it.
I assume it should be done once in a central code snippet, e.g. in the ui-base code. The setMaxListener function is documented here.
Indeed like @smcgann99 mentions, imho you won't achieve much with this. You can use it in your local copy of the dashboard code. But I 'assume' it won't be accepted via a PR in the dashboard repo, unless you analyze in depth first whether all listeners are being cleaned up correctly. Otherwise you are allowing the system to keep on adding new listeners, but they 'might' not be cleaned up afterwards. In that case you would indeed introduce a leaking system. The result of the analysis might also be that all listeners are cleaned up correcly already by the dashboard code, and then there is no problem in increasing the max listener count.
But of course I might be completely mistaken...
It looks to me, after a very brief look at the code, that the Socket.IO handling should be centralised under a single entity - perhaps a singleton class as I do it in UIBUILDER or maybe a runtime plugin instead? Then any D2 node could use the same Socket.IO instance.
PS: Just noting that I think there is an outstanding bug in Node-RED's palette handling which doesn't like having a plugin and nodes in the same package. It all works but does not show the nodes in the palette manager, only the plugin. Only the palette manager is visually affected. But it is still annoying.
