Hi, It would be nice if Mongrel would do multiapps in one Mongrel instance. For the moment, I have one Mongrel for each app of my server, each on a different port. For example: http://server:8080/app1 http://server:8080/app2 instead of: http://server:8080/ http://server:8081/ Is that planned? Thanks. -jec -- JeSC - Software et Consulting Jean-Eric Cuendet Ing?nieur HES en t?l?communications 1168 Villars-sous-Yens Web : http://jesc.ch Tel : +41 21 800 3343 Mobile : +41 76 222 3343 --------------------------------------------------------
On 8/25/06, Jean-Eric Cuendet (ML) <jec at ml1.jesc.ch> wrote:> Hi, > It would be nice if Mongrel would do multiapps in one Mongrel instance. > For the moment, I have one Mongrel for each app of my server, each on a > different port. > For example: > http://server:8080/app1 > http://server:8080/app2 > instead of: > http://server:8080/ > http://server:8081/ > Is that planned?Hello Jean-Eric, The prefixing of rails application is available, too many asked about that. Regarding running multiple Rails application from one Mongrel instance, is like playing with a *loaded* gun. Rails isn''t thread-safe, that range from two concurrent threads that try to access the CGI dispatcher or running two different application in the same context. Neither way is planned, or will be supported (AFAIK) because trying to debug simple concurrency problems is a real pain... imagine do that for 2 instances running concurrently. Hope this answer your question, the best I could write with my poor english. Regards, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
On 25.8.2006, at 16.45, Jean-Eric Cuendet (ML) wrote:> Hi, > It would be nice if Mongrel would do multiapps in one Mongrel > instance. > For the moment, I have one Mongrel for each app of my server, each > on a > different port. > For example: > http://server:8080/app1 > http://server:8080/app2 > instead of: > http://server:8080/ > http://server:8081/ > Is that planned?No offense, Jean-Eric, but you already asked this two weeks ago [1] and got 7 responses, including one from Zed himself [2]. The answer: You can''t do that as long as Rails is not thread-safe, in other words not any time soon. //jarkko [1] http://rubyforge.org/pipermail/mongrel-users/2006-August/000924.html [2] http://rubyforge.org/pipermail/mongrel-users/2006-August/000932.html -- Jarkko Laine http://jlaine.net http://odesign.fi
On 8/25/06, Jarkko Laine <jarkko at jlaine.net> wrote:> No offense, Jean-Eric, but you already asked this two weeks ago [1] > and got 7 responses, including one from Zed himself [2]. > > The answer: You can''t do that as long as Rails is not thread-safe, in > other words not any time soon.Some time ago on ruby-talk there was a little discussion about using fork() as a sort of crude mark and sweep heap manager. The basic idea is that on certain OSes, fork() can be very, very fast because a copy-on-write is done on the memory image. Disable GC as soon as the fork is completed, do your thing, and let the forked process die. The memory of this discussion jumped out at me the other day when someone was asking about Mongrel and multiple Rails requests. I''m not going to do the work because I have more than enough other work in progress right now, but here''s the idea: Change Mongrel and the Rails handler so that one has the option of forking instead of spawning a new thread to handle the request. It might be a usably fast way to get multiple Rails requests out of a single Mongrel. On my test server (a pretty modest AMD based box running a 2.4 Linux kernel), I can fork a little over 200 7Mb processes a second in a simple test. Kirk Haines
On Aug 25, 2006, at 9:22 AM, Kirk Haines wrote:> On 8/25/06, Jarkko Laine <jarkko at jlaine.net> wrote: > >> No offense, Jean-Eric, but you already asked this two weeks ago [1] >> and got 7 responses, including one from Zed himself [2]. >> >> The answer: You can''t do that as long as Rails is not thread-safe, in >> other words not any time soon. > > Some time ago on ruby-talk there was a little discussion about using > fork() as a sort of crude mark and sweep heap manager. > > The basic idea is that on certain OSes, fork() can be very, very fast > because a copy-on-write is done on the memory image. Disable GC as > soon as the fork is completed, do your thing, and let the forked > process die. > > The memory of this discussion jumped out at me the other day when > someone was asking about Mongrel and multiple Rails requests. > > I''m not going to do the work because I have more than enough other > work in progress right now, but here''s the idea: > > Change Mongrel and the Rails handler so that one has the option of > forking instead of spawning a new thread to handle the request. It > might be a usably fast way to get multiple Rails requests out of a > single Mongrel. On my test server (a pretty modest AMD based box > running a 2.4 Linux kernel), I can fork a little over 200 7Mb > processes a second in a simple test. > > > Kirk HainesThis is certainly an interesting idea but the problem I see with this is ActiveRecord''s database connection hates fork. Most of the time if you use fork in a rails app you will immediately get the "Mysql server has gone away" error. THere is a workaround you can use but its not pretty. fork do # whatever code you wanted to do in the fork # but make sure the last thing you dlo in the fork is this: Kernel.exec "echo -n" end The trick being Kernel.exec "echo -n" as the last thing you do in the fork. This keeps the database connection from being dropped on the floor for some odd reason. -Ezra
On 8/25/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:> > This is certainly an interesting idea but the problem I see with > this is ActiveRecord''s database connection hates fork. Most of the > time if you use fork in a rails app you will immediately get the > "Mysql server has gone away" error. THere is a workaround you can use > but its not pretty.Not that it would be worth the effort, but you could create a process pool and load rails in the children instead of the parent. Chris
On Fri, 2006-08-25 at 15:45 +0200, Jean-Eric Cuendet (ML) wrote:> Hi, > It would be nice if Mongrel would do multiapps in one Mongrel instance. > For the moment, I have one Mongrel for each app of my server, each on a > different port. > For example: > http://server:8080/app1 > http://server:8080/app2 > instead of: > http://server:8080/ > http://server:8081/ > Is that planned?Unfortunately Rails can''t do this. You can run multiple Camping apps in Mongrel no problem, but not Rails. Rails is the king of the world so it owns everything. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
On Fri, 2006-08-25 at 15:45 +0200, Jean-Eric Cuendet (ML) wrote:> Hi, > It would be nice if Mongrel would do multiapps in one Mongrel instance. > For the moment, I have one Mongrel for each app of my server, each on a > different port. > For example: > http://server:8080/app1 > http://server:8080/app2 > instead of: > http://server:8080/ > http://server:8081/ > Is that planned?Ah, but you can simulate this. I should mention that 0.3.13.4 pre-release has the --prefix options, which will mount a Rails application at a different path. You could then put apache in front of two different mongrel instances ran with: mongrel_rails start -e production --prefix=/app1 mongrel_rails start -e production --prefix=/app2 And it''d work about the same. You can install the pre-release with: gem install mongrel --source=http://mongrel.rubyforge.org/releases/ -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
On Fri, 2006-08-25 at 10:22 -0600, Kirk Haines wrote:> On 8/25/06, Jarkko Laine <jarkko at jlaine.net> wrote: > > > No offense, Jean-Eric, but you already asked this two weeks ago [1] > > and got 7 responses, including one from Zed himself [2]. > > > > The answer: You can''t do that as long as Rails is not thread-safe, in > > other words not any time soon.> Change Mongrel and the Rails handler so that one has the option of > forking instead of spawning a new thread to handle the request. It > might be a usably fast way to get multiple Rails requests out of a > single Mongrel. On my test server (a pretty modest AMD based box > running a 2.4 Linux kernel), I can fork a little over 200 7Mb > processes a second in a simple test.The problem with that Kirk is a large majority of people use VPS for their deployment, and the OS accounts for these forked processes as if they''re using up the shared ram. In Linux this bring the wrath of their dumb killer process and it kills them off. Now, what *I* want to investigate is getting a framework (any one) working on Ruby 1.9 and look at just creating a bunch of YARV VMs which are all handling each request sequentially. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
On Fri, 2006-08-25 at 14:30 -0700, snacktime wrote:> On 8/25/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote: > > > > > This is certainly an interesting idea but the problem I see with > > this is ActiveRecord''s database connection hates fork. Most of the > > time if you use fork in a rails app you will immediately get the > > "Mysql server has gone away" error. THere is a workaround you can use > > but its not pretty. > > Not that it would be worth the effort, but you could create a process > pool and load rails in the children instead of the parent.That was the original plan actually, and SCGI Rails Runner did that at first. Until I found out that Ruby''s IO seems to have problems with a socket being multiplexed. This was in the dark days of 1.8.0 ruby, but there''d be lost data in one process that''d show up in another (which is really not cool). Not to mention this don''t work on win32 (but what does really). -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.