Feature Request: Running multiple instances of the same Meteor app in development?

[ghost]

Problem
I'm building a couple of 3rd party packages that relies on mutiple instances of the same application running against the same database. I'm currently unable to run multiple instances of the same source, unless I copy the entire source and run my second instance from it. I think there's a number of scenarios where it would be valuable to easily run the same app on different ports.

From my perspective, this would be pretty cool:

D:\> cd documents\projects\someMeteorProject
D:\documents\projects\someMeteorProject> meteor --port 3000
D:\documents\projects\someMeteorProject> meteor --port 4000

If I try this right now, my second instance gets the following output:

[[[[[ ~\D:\documents\projects\someMeteorProject ]]]]]

=> Started proxy.

<runJavaScript-77>:168
      throw error;
            ^
Error: EBUSY, rmdir 'D:\documents\projects\someMeteorProject\.meteor\local\build\programs\server'
PS D:\documents\projects\someMeteorProject>

I imagine this is because it's trying to rebuild on top of the code that has already been built and is executing?...

[clayne11]

Could you provide a use case where this would be beneficial?

[ghost]

I think I've made my use case pretty clear - I'm doing a cross instance package which is explicitly easier to develop running two instances of the same codebase whilst developing. Is that clearer, or should I be more specific?

[rozzzly]

No @Goatic. Can you be more specific? Can you make that more clear?

[ghost]

I'm doing 3 meteor packages - one of them, which the other two relies on, is polling the database to let other server-instances know it's online. When an instance goes down, other instances will clean up the data the dead instance left behind. My other two packages sprinkle some user presence on top of this functionality, allowing server-instances to set users as online, and marks them with a unique instance ID, so that other instances can take them offline in case that instance goes down.

Developing this package, I'm trying out different ways of doing this efficiently, and it's really hard to develop when I can't have multiple copies of the same codebase running at the same time.

Scaling out applications horizontally, if you're developing packages that allow this, it's beneficial to be able to run multiple copies in development as well. Having to make copies of the codebase, bump version number with every minor change to have them reflected across apps with the local package installed, is tiring - and it would be really nice to just have multiple copies of the same thing running at the same time! 👍

This is really easy to do in Node, and I hope that's the case (or will be) with Meteor as well!

Is that descriptive enough, or is there anything I could add to this to make my use case clearer?

[stubailo]

I think the easiest way to achieve this would be to have Meteor use some other directory as the .meteor/local directory. So you could say something like:

METEOR_LOCAL_DIR=/tmp/app-number-two meteor -p 4000

Note, this doesn't work right now - I'm just presenting an idea for how it could work if it were implemented.

[ghost]

Thanks @stubailo! This was exactly the kind of solution I was looking for 👍 I'll just add it as a package.json script, and it will be easy to automate the setup!

Should I keep the issue open for the sake of a potential pull request?

[stubailo]

@Goatic yeah the thing I wrote isn't an actual thing you can do today, it would be a new feature to be added. I'm hoping someone can do this via a pull request.

Basically you would need to modify this line:

meteor/tools/project-context.js

Line 91 in 88d43a0

self.projectLocalDir = options.projectLocalDir ||

And have it read from process.env.METEOR_LOCAL_DIR if that variable exists. Then you should be able to run many copies of Meteor from the same app.

[ghost]

no problem... If I actually manage to submit the request correctly, lol. Thanks for the guidance 👍

[laosb]

@stubailo Meteor should have read it from process.env.METEOR_LOCAL_DIR, I think? Else the workaround you provided shouldn't work?

So what we need to do is detect if we already have one instance running, and generate another local path?

[stubailo]

Else the workaround you provided shouldn't work?

Yes the workaround I provided doesn't work. It's an idea for how someone could file a PR to fulfill this feature request.

[stubailo]

Thanks to @laosb this is now fixed on devel! Next Meteor release you can run multiple instances of the same app!

[ghost]

export MONGO_URL=mongodb://localhost:3001/meteor
meteor --port 4000

[aadamsx]

On Meteor 1.5 I get an error when trying to run two instances of Meteor, on two different ports, out of the same directory.

// package.json:

{
  "name": "dev",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "admin": "meteor --settings .config/development/settings.json --port 8080",
    "client": "meteor --settings .config/development/settings.json --port 8081",
...

The mondo server is run from localhost:3001 as usual.

I run the command npm run admin and then npm run client in two different shells.

They both need to talk to the same DB.

[abernix]

@aadamsx I see two problems given the configuration you've shown here, though you've excluded the actual error message and indication of whether you have MONGO_URL or METEOR_LOCAL_DIR environment variables set so that will skew the accuracy of my answer.

That being said: First, Meteor doesn't just always use port 3001 for Mongo but instead uses port (default 3000) and port+1 (default 3001), your npm run admin will immediately occupy 8080 and 8081. Then, when you run npm run client the port 8081 will be occupied already and the command will fail. Second, both admin and client need different ".meteor"-type directories – for example, on the client app you could set METEOR_APP_DIR=/full/path/to/app-dir/.meteor-client and leave the server as the default (.meteor).

More clarity here would be helpful to assist you!

[aadamsx]

I figured it out. I didn't have a local mongo instance running, I always just used the instance supplied with Meteor. I did a brew install of Mongo 3.2, started it up, pointed to mongodb://localhost:27017/meteor and it connected.