Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Support for multiple instances of nsm #16

Open
awolden opened this issue Mar 24, 2016 · 0 comments
Open

Add Support for multiple instances of nsm #16

awolden opened this issue Mar 24, 2016 · 0 comments

Comments

@awolden
Copy link
Collaborator

awolden commented Mar 24, 2016

Currently, if you run nsm app.js more than once, nsolid-manager will try to launch new instances of all the nsolid apps and dependencies listening on the same ports. This leads to some strange and broken behavior between the two nsm instances. It should be a high priority to clean-up this issue. There are two ways that we can solve this problem:

Piggybacking
In this solution, nsm instance 1 starts all dependencies, and sets a global flag in the package that indicates an instance is already running. When nsm instance 2 is started it checks for that flag and doesn't try to start any dependencies. This will cause nsm instance 2 to use the dependencies being run by nsm instance 1.

Pros:

  • Easy to implement
    Cons:
  • nsm instance 2 won't receive any console output
  • nsm instance 2 won't know when the proc running the dependencies is closed.

Central Service
This solution is a little more sophisticated and little more theoretical. When any nsm instance is started, it will check for an existing dependency service. If one doesn't exist it will spawn all the dependencies in a separate. It will then detach that process so it is an independent process. If a second nsm instance is started, it will check for the existing dependency service, find it, and attach itself to it. When each nsm instance is closed it will check to see if it is the only nsm instance using the service, and it if it is, it will shut down the service

Pros:

  • Scalable for n nsm instances
  • Less opportunity for nsm instances to collide and interfere with each other

Cons:

  • More difficult to implement
  • Not sure if it is practically possible for processes to detach/reattach themselves.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant