On Sat, 12 May 2007, Rick DeNatale wrote:

> On 5/12/07, khaines / enigo.com <khaines / enigo.com> wrote:
>
> This looks promising, but I don't seem to see a way to use
> mongrel_cluster instead of just plain mongrel[_rails]
>
> Currently I use pen in front of a mongrel cluster. I'd love to see an
> easy way to host multiple back-end clusters for multiple apps under
> different virtual hosts or root url's.
>
> This looks like it nicely handles the multiple apps case but, unless I
> miss it, not multiple instances per app.

By multiple instances per app, I assume that you mean multiple backend 
processes, right?

That's the whole point.  They all connect to the SAME address/port, 
because the instances are clients of swiftiply instead of being standalone 
servers.

So, for example, if you have the following config section:

map:
   - incoming: planner.walrusinc.com
     outgoing: frontend.walrusinc.com:11111
   - incoming: blog.walrusinc.com
     outgoing: frontend.walrusinc.com:11112

Then Swiftiply proxies requests for planner.walrusinc.com to the backends 
connected to frontend.walrusinc.com:11111, and blog.walrusinc.com to the 
backends connected to frontend.walrusinc.com:11112.

Because the backends are clients of Swiftiply, you have have however many 
of them that you need all connected to the same point.  So 
blog.walrusinc.com is running with 2 backends, but walrusinc's thoughts 
become popular, so they spin up a second machine with a couple more 
backends on it.  All of the backends connect to 
frontend.walrusinc.com:11112.

swiftiply_mongrel_rails will start N mongrel_rails processes, all on the 
same address/port, with a pid file for each (since the default pid file is 
named by port with mongrel_rails, that won't work when all of the 
processes are connected to the same port).

However, I am sure that better integration with mongrel_cluster is needed. 
More complete support for all Ruby frameworks is my primary goal for the 
next release.



Kirk Haines