passenger should identify applications by app_dir+RailsEnv instead of just app_dir

[FooBarWidget]

From martin.sarsale on April 15, 2009 17:24:10

There have been reports of people trying to run the same application with different RailsEnv (ie, production and development).

Since currently passenger identifies the application using it's app directory a new app is not spawned if a previous one was running (even if the Rails Environment was different).

You can bypass this restriction now by doing a bind mount (mount --bind app development) but it would be great that passenger used app_dir + RailsEnv to identify each running application.

just my 2 cents :)

Original issue: http://code.google.com/p/phusion-passenger/issues/detail?id=246

[FooBarWidget]

From honglilai on April 15, 2009 10:37:04

Labels: -Type-Defect Type-Enhancement

[FooBarWidget]

From rhsweet on April 17, 2009 11:09:31

I was actually getting ready to submit a patch to add just this capability. I'm building the AppKey as RAILS_ENVPATH (i.e. development/home/someuser/some_project/public). It seemed to work well with the testing that I'd done so far. And just a disclaimer - I'm not a C/C++ guy at all so there may be ways to clean this up. It'll need some tests around it, of course, and as it requires the environment instead of just the AppRoot, the tests that just pass a path into the get() would probably need to be rewritten. Anyway, I hope this helps. :)

Attachment: passenger-2.1.3_with_rails_env.diff

[FooBarWidget]

From honglilai on April 17, 2009 13:37:47

Thanks, but there are a few issues:

• doc/ApplicationPool algorithm.txt needs to be updated as well.
• If the key consists of both the application pool and the environment then the terminology needs to be updated. Right now the data structure which contains the list of backend processes is called the "Domain", which is uniquely identified by its application root. It should probably be renamed to "Group" or something, which is more appropriate.
• StandardApplicationPool::toString should be updated to show the environment in the output as well, otherwise it will be confusing to the sysadmin.
• You don't have to use stringstream to concatenate strings. Using std::string will do: return string(app_key) + "__" + environment
• Some indenting is messed up. We use tabs but it seems your editor changed some lines to two-spaces.

[FooBarWidget]

From rhsweet on April 17, 2009 14:01:36

Thanks for the feedback but honestly, I'm not qualified to add this functionality properly - just look at my use of stringstream! :) I actually get the functionality that I needed from the 2.2.0 change to not dereference symlinks and was just posting my patch in the hope that it would help someone else add this functionality a little bit easier. FWIW, calling them 'domains' seemed a little misleading to me too. Is there a reason not to just call them 'pools'? I mean, that's really what they are - pools of application instances.

Something else that I was thinking about on the way in to the office today - I wonder, rather than hacking things up to add a second factor to the pool key, if it would be easier to just have an optional VHost-level parameter than can be used to explicity name a pool. It's my application and my Apache config so I know what code is shared where and how different my environments are. Having Passenger guess at what pools I need is great for a basic 'start using Passenger' setup but for a complex application with several (Dev, BA, SQA, IQA, UAT, etc.) environments, it would be easier if I could just tell Passenger how to effectively pool my VHosts.

One example of this is to run my view test suite. We use Selenium Grid to run a number of browser-based tests in parallel and because the tests need to run in isolation, I really need each vhost to be pooled independently. With 2.2.0, I can do that by making a bunch of symlinks for the codebase for each Apache VHost but that feels kind of hacky to me. I'm just taking advantage of how Passenger happens to work. It would be even easier, not to mention more explicit, if I could just put a pool name for each VHost in the httpd.conf and call it a day.

Anyway, if people are interested in this idea I can try to hack it together but like I said, I'm probably not the best person to do this work.

While I'm here, thanks for building Passenger! Apache -> HA Proxy -> a bunch of individually-spawned and managed mongrels is for the birds. :)

[FooBarWidget]

From honglilai on April 17, 2009 14:29:33

No specific reason. I just chose a random name that doesn't sound too bad because I couldn't think of anything better. :) Though "pools" is potentially misleading, but the entire thing is already a pool. Having pools within a pool is just weird. :) So how about "Group"?

VHost-level parameter for naming the pool: I've thought of this too. I'm unsure whether this is a good idea. It sounds too much like an implementation detail. I want Phusion Passenger to be as automatic as possible, and I want it to do things in a way that surprises the user least. Allowing them to configure the identity key is like telling them to learn how Phusion Passenger works internally, something which I want to avoid.

Though, in the absence of a better alternative, I guess there's no other choice.

[FooBarWidget]

From honglilai on November 15, 2010 05:24:50

Issue 443 has been merged into this issue.

[FooBarWidget]

Merging this into issue #664.