Read the statement by Michael Teeuw here.
Does node_helper know if all module instances are already started?
I created a module that displays some specific information. Multiple instances of it are configured. After each instance starts it sends its config to node_helper in its start function. Then node_helper is responsible to handle display and sending notifications to the instances. My question is if node_helper is aware that all module instances have been started? I would like to know when node_helper can “move” to “ready to display” state. This will be achieved after I am sure that all module instances are started and they have already sent their specific configs to node_helper script. As there may be multiple instances of module and their number may vary I cannot simply wait for a specific number of configs because this may change. Is it possible to know in node_helper that all instances are started? Of course I can wait for some time and then assume that every instance had time to start but this is not a nice solution.
@Adam-2 you shouldn’t design it that way
node_helper is a ‘helper’, display is done by each module
each instance calling for service should pass it’s identifier as part of the message
and the helper should send that back on response to THAT modules request.
node that the sendSocketNotification from the helper goes to ALL module instances at the same time. each instance should check if the response is for them.
@sdetweil I know that helper sends notification to all modules. However, my question is if knows that all modules are already started? Modules can send some notification after they are started but still as their number can differ node_helper cannot know if all of them are started. My only idea is to wait for first notification from first started module and then wait for for example 5s and assume that other instances have also been started.
@Adam-2 what difference does it make?
I have one module that does graphing of data from a csv file, retrieved from an internet source.
the first request starts the get
and all others queue up behind it.
when the file is retrieved the node helper threads are woken up and each processes the file uniquely and sends that modules data back.
but the answer to your question is No
the node helper doesn’t know anything about the timing of the modules. some could be local, and some could be on remote machines, on the same network or across the internet.
treat each notification as a request/response
@sdetweil So node_helper would never know if all possible module instances are loaded. If it can be assumed that module instances are started in the order defined in config file I could set some config parameter for the first instance with number of modules that will be setup. This can be send to node_helper and then node_helper can wait until it counts proper number of started modules because each of them will notify. After that it can assume that the display is in “stable” state and it is possible to send some new data to display and know that it will be displayed for sure because proper module is already started. The drawback is that I have to count all module instances and introduce some specific config parameter for first of them.
@Adam-2 I still think that design is bad.
I can open another browser to mm tomorrow, and you will have another config.js count of modules firing requests.
why do you think that you need to know about the state of the viewers?
- node_helper cannot know other module’s status directly. It lies on another layer of the architecture.
- It sounds somewhat weird
node_helperhas to interact with other
A modulehas to interact with other
node_helperis a helper for a specific module to handle things out of MM/browser front level.
- Module notification
DOM_OBJECTS_CREATEDis regarded as a signal of ‘all modules are displayed’. You can deliver
socketNotificationto your node_helper to start your job when this notification is caught.
@MMRIZE My node_helper does not interact with other modules. It interacts only with many instances of my module, because there is only one node_helper even if module has multiple instances. It looks that DOM_OBJECTS_CREATED notification is a good way to know that each module instance is already started. However, as it is received by the module, in fact each instance will pass that info to node_helper while only one is enough. However, this is not a huge issue. After this is passed to node_helper I can be sure that module instances are ready to display data through API provided by the node_helper. Moreover, I can be sure that all individual configs for each module are already loaded.
You can assign and deliver some
instanceIDto distinguish which instance of your module transfers this notification.
Or you can use
Promise.race()(to confirm first socketNotification coming from any instance) or
Promise.allSettled()(to confirm entire socketNotifications delivered from all instances even though fail or not) in node_helper to check socketNotifications receiving. (Anyway, you need to check how many instances there exist before promise racing)
@MMRIZE and config. is accessible in node_helper, so one could count the module instances