From singhi.surendra at gmail.com  Tue Jan  1 00:22:27 2008
From: singhi.surendra at gmail.com (Surendra)
Date: Tue, 1 Jan 2008 10:52:27 +0530
Subject: [Mongrel] copying uploaded file
Message-ID: <aebc58490712312122w272d3e65l6602080bd4c4eb51@mail.gmail.com>

Hi,
 We are using mongrel_upload_progress to upload pictures. All fine and good.

But after the file is uploaded by the user we are currently using
FileUtils.copy_stream to copy the uploaded file data into our WebDav.
I think this process is probably inefficient and results in
unnecessary allocation/deallocation of memory as ruby has to first
read and then write the file data.

I think a better alternative will be using FileUtils.copy, and copy
the temp file on to the WebDav. But it seems  if the upload is less
than  12 KB mongrel doesn't creates a TempFile object.
Is there any way to force mongrel to always create temp files?
Or should we check if the temp file is there or not and based on that
use copy_stream or copy?

What is your experience with handling above scenario? Any tips?

Thanks a lot!

-- 
Surendra Singhi

From evan at cloudbur.st  Tue Jan  1 01:50:34 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Tue, 1 Jan 2008 01:50:34 -0500
Subject: [Mongrel] "mongrel_rails --version" reporting 1.1.2 instead of
	1.1.3
In-Reply-To: <71166b3b0712311935p6f220d63we8de1a148acfaf8b@mail.gmail.com>
References: <5b5090780712311543qf190722v6daad385b313eeea@mail.gmail.com>
	<71166b3b0712311935p6f220d63we8de1a148acfaf8b@mail.gmail.com>
Message-ID: <b6f68fc60712312250o6a0099efwa3dc86c8b7502050@mail.gmail.com>

I can reproduce. Can you file a ticket?

Evan

On Dec 31, 2007 10:35 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Dec 31, 2007 8:43 PM, Brian Gupta <brian.gupta at gmail.com> wrote:
> > FYI.
> >
>
> >From your signature I guess is OpenSolaris.
>
> - Did you install it from rubygems or downloaded the tgz package?
>
> The http11 set the platform correctly, so I honestly don't know why
> are you getting it (the tgz, the mongrel-1.1.1.gem and the
> mongrel-1.1.3-i386-mswin32.gem display it correctly).
>
> Could I just answer to this: "Works for me"? :-D
>
> Happy New Year!
>
> --
> Luis Lavena
> Multimedia systems
> -
> A common mistake that people make when trying to design
> something completely foolproof is to underestimate
> the ingenuity of complete fools.
> Douglas Adams
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From brian.gupta at gmail.com  Tue Jan  1 18:17:39 2008
From: brian.gupta at gmail.com (Brian Gupta)
Date: Tue, 1 Jan 2008 18:17:39 -0500
Subject: [Mongrel] "mongrel_rails --version" reporting 1.1.2 instead of
	1.1.3
In-Reply-To: <71166b3b0712311935p6f220d63we8de1a148acfaf8b@mail.gmail.com>
References: <5b5090780712311543qf190722v6daad385b313eeea@mail.gmail.com>
	<71166b3b0712311935p6f220d63we8de1a148acfaf8b@mail.gmail.com>
Message-ID: <5b5090780801011517w20cdb34cx17974760d1455642@mail.gmail.com>

Rubygems... The "gem list" command show the updated version number
(1.1.3), but "mongrel_rails --version" shows 1.1.2, which was never
isntalled on my system.

-Brian

On Dec 31, 2007 10:35 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Dec 31, 2007 8:43 PM, Brian Gupta <brian.gupta at gmail.com> wrote:
> > FYI.
> >
>
> >From your signature I guess is OpenSolaris.
>
> - Did you install it from rubygems or downloaded the tgz package?
>
> The http11 set the platform correctly, so I honestly don't know why
> are you getting it (the tgz, the mongrel-1.1.1.gem and the
> mongrel-1.1.3-i386-mswin32.gem display it correctly).
>
> Could I just answer to this: "Works for me"? :-D
>
> Happy New Year!
>
> --
> Luis Lavena
> Multimedia systems
> -
> A common mistake that people make when trying to design
> something completely foolproof is to underestimate
> the ingenuity of complete fools.
> Douglas Adams
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
- Brian Gupta

http://opensolaris.org/os/project/nycosug/

From kevwil at gmail.com  Tue Jan  1 19:26:38 2008
From: kevwil at gmail.com (Kevin Williams)
Date: Tue, 1 Jan 2008 17:26:38 -0700
Subject: [Mongrel] fastthread no longer needed?
Message-ID: <683a886f0801011626i183255d6oaee045138860d2eb@mail.gmail.com>

I'm confused. Wasn't threading fixed in 1.8.6, negating the need for
fastthread? Why is fastthread still a requirement of Mongrel? Just
curious. :)

From luislavena at gmail.com  Tue Jan  1 20:05:16 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 1 Jan 2008 23:05:16 -0200
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <683a886f0801011626i183255d6oaee045138860d2eb@mail.gmail.com>
References: <683a886f0801011626i183255d6oaee045138860d2eb@mail.gmail.com>
Message-ID: <71166b3b0801011705i35ec82dfk119b78cfbe526da7@mail.gmail.com>

On Jan 1, 2008 10:26 PM, Kevin Williams <kevwil at gmail.com> wrote:
> I'm confused. Wasn't threading fixed in 1.8.6, negating the need for
> fastthread? Why is fastthread still a requirement of Mongrel? Just
> curious. :)

1.8.6 ships with fastthread enabled by default, but some distro
maintainers build with --disable-fastthread (I don't remember the
exact configure command right now).

Also, mongrel is compatible with 1.8.4 and 1.8.5, and that is the
standard version that is currently powering a lot of servers.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From luislavena at gmail.com  Tue Jan  1 20:46:07 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 1 Jan 2008 23:46:07 -0200
Subject: [Mongrel] "mongrel_rails --version" reporting 1.1.2 instead of
	1.1.3
In-Reply-To: <b6f68fc60712312250o6a0099efwa3dc86c8b7502050@mail.gmail.com>
References: <5b5090780712311543qf190722v6daad385b313eeea@mail.gmail.com>
	<71166b3b0712311935p6f220d63we8de1a148acfaf8b@mail.gmail.com>
	<b6f68fc60712312250o6a0099efwa3dc86c8b7502050@mail.gmail.com>
Message-ID: <71166b3b0801011746j5ed8c41di11ac9b210e00eb42@mail.gmail.com>

On Jan 1, 2008 4:50 AM, Evan Weaver <evan at cloudbur.st> wrote:
> I can reproduce. Can you file a ticket?
>

Then that means rubyforge picked the older file before we replaced
with the correct one.

That means Tom Copeland is lying! ;-)
(about how gems the replicated into the mirrors) :-)

Maybe we should fill a ticket on Rubyforge support?

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From evan at cloudbur.st  Tue Jan  1 23:34:09 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Tue, 1 Jan 2008 23:34:09 -0500
Subject: [Mongrel] "mongrel_rails --version" reporting 1.1.2 instead of
	1.1.3
In-Reply-To: <71166b3b0801011746j5ed8c41di11ac9b210e00eb42@mail.gmail.com>
References: <5b5090780712311543qf190722v6daad385b313eeea@mail.gmail.com>
	<71166b3b0712311935p6f220d63we8de1a148acfaf8b@mail.gmail.com>
	<b6f68fc60712312250o6a0099efwa3dc86c8b7502050@mail.gmail.com>
	<71166b3b0801011746j5ed8c41di11ac9b210e00eb42@mail.gmail.com>
Message-ID: <b6f68fc60801012034x64697800gbb000703401f3e85@mail.gmail.com>

Not necessarily...

mongrel/branches/stable_1-1 eweaver$ ack 1.1.2
ext/http11_java/org/jruby/mongrel/Http11.java
218:
req.aset(runtime.newString("SERVER_SOFTWARE"),runtime.newString("Mongrel
1.1.2"));

lib/mongrel/const.rb
68:    MONGREL_VERSION="1.1.2".freeze

I think someone (you?) forgot to commit the version change. I had to
re-release the gem to fix the daemons dependency problem (due to the
FORCE_PURE thing you added, which I committed a fix for).

Either that or somehow I accidentally reversed your change. I'll patch
things up regardless.

Evan

On Jan 1, 2008 8:46 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Jan 1, 2008 4:50 AM, Evan Weaver <evan at cloudbur.st> wrote:
> > I can reproduce. Can you file a ticket?
> >
>
> Then that means rubyforge picked the older file before we replaced
> with the correct one.
>
> That means Tom Copeland is lying! ;-)
> (about how gems the replicated into the mirrors) :-)
>
> Maybe we should fill a ticket on Rubyforge support?
>
> --
>
> Luis Lavena
> Multimedia systems
> -
> A common mistake that people make when trying to design
> something completely foolproof is to underestimate
> the ingenuity of complete fools.
> Douglas Adams
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From kevwil at gmail.com  Tue Jan  1 23:35:22 2008
From: kevwil at gmail.com (Kevin Williams)
Date: Tue, 1 Jan 2008 21:35:22 -0700
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <71166b3b0801011705i35ec82dfk119b78cfbe526da7@mail.gmail.com>
References: <683a886f0801011626i183255d6oaee045138860d2eb@mail.gmail.com>
	<71166b3b0801011705i35ec82dfk119b78cfbe526da7@mail.gmail.com>
Message-ID: <683a886f0801012035y780354b9rd4a8106891289c24@mail.gmail.com>

Thank you.

On Jan 1, 2008 6:05 PM, Luis Lavena <luislavena at gmail.com> wrote:
>
> On Jan 1, 2008 10:26 PM, Kevin Williams <kevwil at gmail.com> wrote:
> > I'm confused. Wasn't threading fixed in 1.8.6, negating the need for
> > fastthread? Why is fastthread still a requirement of Mongrel? Just
> > curious. :)
>
> 1.8.6 ships with fastthread enabled by default, but some distro
> maintainers build with --disable-fastthread (I don't remember the
> exact configure command right now).
>
> Also, mongrel is compatible with 1.8.4 and 1.8.5, and that is the
> standard version that is currently powering a lot of servers.
>
> --
> Luis Lavena
> Multimedia systems
> -
> A common mistake that people make when trying to design
> something completely foolproof is to underestimate
> the ingenuity of complete fools.
> Douglas Adams
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From evan at cloudbur.st  Tue Jan  1 23:37:17 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Tue, 1 Jan 2008 23:37:17 -0500
Subject: [Mongrel] "mongrel_rails --version" reporting 1.1.2 instead of
	1.1.3
In-Reply-To: <b6f68fc60801012034x64697800gbb000703401f3e85@mail.gmail.com>
References: <5b5090780712311543qf190722v6daad385b313eeea@mail.gmail.com>
	<71166b3b0712311935p6f220d63we8de1a148acfaf8b@mail.gmail.com>
	<b6f68fc60712312250o6a0099efwa3dc86c8b7502050@mail.gmail.com>
	<71166b3b0801011746j5ed8c41di11ac9b210e00eb42@mail.gmail.com>
	<b6f68fc60801012034x64697800gbb000703401f3e85@mail.gmail.com>
Message-ID: <b6f68fc60801012037k6fe96152m527c6d86268db3ac@mail.gmail.com>

Either way, if someone can figure out why the C/Java extensions
don't/can't refer to the same constant in the first place, that would
be sweet. I haven't had time to investigate that in detail.

Evan

On Jan 1, 2008 11:34 PM, Evan Weaver <evan at cloudbur.st> wrote:
> Not necessarily...
>
> mongrel/branches/stable_1-1 eweaver$ ack 1.1.2
> ext/http11_java/org/jruby/mongrel/Http11.java
> 218:
> req.aset(runtime.newString("SERVER_SOFTWARE"),runtime.newString("Mongrel
> 1.1.2"));
>
> lib/mongrel/const.rb
> 68:    MONGREL_VERSION="1.1.2".freeze
>
> I think someone (you?) forgot to commit the version change. I had to
> re-release the gem to fix the daemons dependency problem (due to the
> FORCE_PURE thing you added, which I committed a fix for).
>
> Either that or somehow I accidentally reversed your change. I'll patch
> things up regardless.
>
> Evan
>
>
> On Jan 1, 2008 8:46 PM, Luis Lavena <luislavena at gmail.com> wrote:
> > On Jan 1, 2008 4:50 AM, Evan Weaver <evan at cloudbur.st> wrote:
> > > I can reproduce. Can you file a ticket?
> > >
> >
> > Then that means rubyforge picked the older file before we replaced
> > with the correct one.
> >
> > That means Tom Copeland is lying! ;-)
> > (about how gems the replicated into the mirrors) :-)
> >
> > Maybe we should fill a ticket on Rubyforge support?
> >
> > --
> >
> > Luis Lavena
> > Multimedia systems
> > -
> > A common mistake that people make when trying to design
> > something completely foolproof is to underestimate
> > the ingenuity of complete fools.
> > Douglas Adams
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
>
>
> --
> Evan Weaver
> Cloudburst, LLC
>



-- 
Evan Weaver
Cloudburst, LLC

From luislavena at gmail.com  Wed Jan  2 00:05:07 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 2 Jan 2008 03:05:07 -0200
Subject: [Mongrel] "mongrel_rails --version" reporting 1.1.2 instead of
	1.1.3
In-Reply-To: <b6f68fc60801012034x64697800gbb000703401f3e85@mail.gmail.com>
References: <5b5090780712311543qf190722v6daad385b313eeea@mail.gmail.com>
	<71166b3b0712311935p6f220d63we8de1a148acfaf8b@mail.gmail.com>
	<b6f68fc60712312250o6a0099efwa3dc86c8b7502050@mail.gmail.com>
	<71166b3b0801011746j5ed8c41di11ac9b210e00eb42@mail.gmail.com>
	<b6f68fc60801012034x64697800gbb000703401f3e85@mail.gmail.com>
Message-ID: <71166b3b0801012105g4e9e85blb3afa5ad87ed280f@mail.gmail.com>

On Jan 2, 2008 2:34 AM, Evan Weaver <evan at cloudbur.st> wrote:
> Not necessarily...
>
> mongrel/branches/stable_1-1 eweaver$ ack 1.1.2
> ext/http11_java/org/jruby/mongrel/Http11.java
> 218:
> req.aset(runtime.newString("SERVER_SOFTWARE"),runtime.newString("Mongrel
> 1.1.2"));
>
> lib/mongrel/const.rb
> 68:    MONGREL_VERSION="1.1.2".freeze
>
> I think someone (you?) forgot to commit the version change.

Damn, I did it, but as you said, forgot the commit (maybe is in my WC
at office).

> I had to re-release the gem to fix the daemons dependency problem (due to the
> FORCE_PURE thing you added, which I committed a fix for).

Please excuse Evan this took you time away from your life (since is
January 1st of a new year!).

I think part of the problem was the urgent need to release a new
version with the proper fix, neglecting things like that.

For what matters, we could alter the extconf.rb to use a define and
get the proper version build inside the http11 extension.

Currently I'm doing something like that for mongrel_service.

> Either that or somehow I accidentally reversed your change. I'll patch
> things up regardless.
>

Again, thank you Evan.

Have a nice week and talk soon.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From mental at rydia.net  Wed Jan  2 10:18:36 2008
From: mental at rydia.net (MenTaLguY)
Date: Wed, 2 Jan 2008 7:18:36 -0800
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <683a886f0801011626i183255d6oaee045138860d2eb@mail.gmail.com>
References: <683a886f0801011626i183255d6oaee045138860d2eb@mail.gmail.com>
Message-ID: <f536a74700afa5c06f4d90c1ab2ee6fb@localhost>

On Tue, 1 Jan 2008 17:26:38 -0700, "Kevin Williams" <kevwil at gmail.com> wrote:
> I'm confused. Wasn't threading fixed in 1.8.6, negating the need for
> fastthread? Why is fastthread still a requirement of Mongrel? Just
> curious. :)

Welll.. it greatly depends which patchlevel of 1.8.6 you have.  The earlier
patchlevels are actually kind of broken; using fastthread in that case
works around the problems.

-mental


From evan at cloudbur.st  Wed Jan  2 13:11:02 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Wed, 2 Jan 2008 13:11:02 -0500
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <f536a74700afa5c06f4d90c1ab2ee6fb@localhost>
References: <683a886f0801011626i183255d6oaee045138860d2eb@mail.gmail.com>
	<f536a74700afa5c06f4d90c1ab2ee6fb@localhost>
Message-ID: <b6f68fc60801021011o41737f56q2d83fa0b8d81b0bf@mail.gmail.com>

I think we will probably remove the Fastthread and
cgi_multipart_eof_fix dependencies at the same time we get 1.9
compatibility. Seems appropriate to me at least.

Evan

On Jan 2, 2008 10:18 AM, MenTaLguY <mental at rydia.net> wrote:
> On Tue, 1 Jan 2008 17:26:38 -0700, "Kevin Williams" <kevwil at gmail.com> wrote:
> > I'm confused. Wasn't threading fixed in 1.8.6, negating the need for
> > fastthread? Why is fastthread still a requirement of Mongrel? Just
> > curious. :)
>
> Welll.. it greatly depends which patchlevel of 1.8.6 you have.  The earlier
> patchlevels are actually kind of broken; using fastthread in that case
> works around the problems.
>
> -mental
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From david at vrensk.com  Wed Jan  2 14:05:13 2008
From: david at vrensk.com (David Vrensk)
Date: Wed, 2 Jan 2008 20:05:13 +0100
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <b6f68fc60801021011o41737f56q2d83fa0b8d81b0bf@mail.gmail.com>
References: <683a886f0801011626i183255d6oaee045138860d2eb@mail.gmail.com>
	<f536a74700afa5c06f4d90c1ab2ee6fb@localhost>
	<b6f68fc60801021011o41737f56q2d83fa0b8d81b0bf@mail.gmail.com>
Message-ID: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>

On 1/2/08, Evan Weaver <evan at cloudbur.st> wrote:
>
> I think we will probably remove the Fastthread and
> cgi_multipart_eof_fix dependencies at the same time we get 1.9
> compatibility. Seems appropriate to me at least.


Evan,

I hope I'm wrong here, but the way I understand what you're saying is that
Mongrel will stop patching Ruby once Mongrel is ready to run on Ruby 1.9.
Wouldn't that mean that you at the same time removed support for all Ruby
versions below 1.8.6 p36?

I'm happy to play with Ruby 1.9, but afaik it's not meant for production use
until it's called 2.0.

Happy new year, all!

/David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080102/ae36c87a/attachment.html 

From mental at rydia.net  Wed Jan  2 14:57:47 2008
From: mental at rydia.net (MenTaLguY)
Date: Wed, 2 Jan 2008 11:57:47 -0800
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
Message-ID: <7fd922c3dab8b7f00f272fcb9c94b09e@localhost>

On Wed, 2 Jan 2008 20:05:13 +0100, "David Vrensk" <david at vrensk.com> wrote:
> I hope I'm wrong here, but the way I understand what you're saying is that
> Mongrel will stop patching Ruby once Mongrel is ready to run on Ruby 1.9.
> Wouldn't that mean that you at the same time removed support for all Ruby
> versions below 1.8.6 p36?

Well, I'd hope what he meant was that Mongrel would still use fastthread if
it was installed, but it would no longer be a dependency of the Mongrel gem.

Which would be as it ought to be -- my intent was for fastthread to fill the
gap between 1.8 and 1.9, and then eventually go away once people stopped
needing/installing it.  But the folks on 1.8.x aren't going away for a while,
so I think it's important that Mongrel uses it if it is installed/supported.

-mental


From evan at cloudbur.st  Wed Jan  2 15:17:48 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Wed, 2 Jan 2008 15:17:48 -0500
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
References: <683a886f0801011626i183255d6oaee045138860d2eb@mail.gmail.com>
	<f536a74700afa5c06f4d90c1ab2ee6fb@localhost>
	<b6f68fc60801021011o41737f56q2d83fa0b8d81b0bf@mail.gmail.com>
	<81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
Message-ID: <b6f68fc60801021217n37900dddy8060f775ea673691@mail.gmail.com>

Yeah, it would.

That's why we need to talk about it.

I know people complained when the idea was broached last time, so we
need to see if p110 is stable and widespread enough now.

Of course everyone is free to continue using older Mongrel versions.

Evan


On Jan 2, 2008 2:05 PM, David Vrensk <david at vrensk.com> wrote:
> On 1/2/08, Evan Weaver <evan at cloudbur.st> wrote:
>
> > I think we will probably remove the Fastthread and
> > cgi_multipart_eof_fix dependencies at the same time we get 1.9
> > compatibility. Seems appropriate to me at least.
>
> Evan,
>
> I hope I'm wrong here, but the way I understand what you're saying is that
> Mongrel will stop patching Ruby once Mongrel is ready to run on Ruby 1.9.
> Wouldn't that mean that you at the same time removed support for all Ruby
> versions below 1.8.6 p36?
>
> I'm happy to play with Ruby 1.9, but afaik it's not meant for production use
> until it's called 2.0.
>
> Happy new year, all!
>
> /David
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From evan at cloudbur.st  Wed Jan  2 15:55:19 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Wed, 2 Jan 2008 15:55:19 -0500
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
Message-ID: <b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>

That's what I should have meant. It could stop being a gem dependency
but still be a rescued require.

Who is still deployed on 1.8.5 or 1.8.4?

Evan

On Jan 2, 2008 2:57 PM, MenTaLguY <mental at rydia.net> wrote:
> On Wed, 2 Jan 2008 20:05:13 +0100, "David Vrensk" <david at vrensk.com> wrote:
> > I hope I'm wrong here, but the way I understand what you're saying is that
> > Mongrel will stop patching Ruby once Mongrel is ready to run on Ruby 1.9.
> > Wouldn't that mean that you at the same time removed support for all Ruby
> > versions below 1.8.6 p36?
>
> Well, I'd hope what he meant was that Mongrel would still use fastthread if
> it was installed, but it would no longer be a dependency of the Mongrel gem.
>
> Which would be as it ought to be -- my intent was for fastthread to fill the
> gap between 1.8 and 1.9, and then eventually go away once people stopped
> needing/installing it.  But the folks on 1.8.x aren't going away for a while,
> so I think it's important that Mongrel uses it if it is installed/supported.
>
> -mental
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From mental at rydia.net  Wed Jan  2 15:59:54 2008
From: mental at rydia.net (MenTaLguY)
Date: Wed, 2 Jan 2008 12:59:54 -0800
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <b6f68fc60801021217n37900dddy8060f775ea673691@mail.gmail.com>
References: <b6f68fc60801021217n37900dddy8060f775ea673691@mail.gmail.com>
Message-ID: <7f9c04bdabe2d20018e607a7b2d43c11@localhost>

On Wed, 2 Jan 2008 15:17:48 -0500, "Evan Weaver" <evan at cloudbur.st> wrote:
> I know people complained when the idea was broached last time, so we
> need to see if p110 is stable and widespread enough now.
> 
> Of course everyone is free to continue using older Mongrel versions.

I think the best option is to make it a "soft dependency".  That way
people who need fastthread can install it and benefit from it, but
we can stop forcing it to install with the gem.

-mental


From luislavena at gmail.com  Wed Jan  2 16:25:22 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 2 Jan 2008 19:25:22 -0200
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
Message-ID: <71166b3b0801021325m1130dc0ve77b4287d640a644@mail.gmail.com>

On Jan 2, 2008 6:55 PM, Evan Weaver <evan at cloudbur.st> wrote:
> That's what I should have meant. It could stop being a gem dependency
> but still be a rescued require.
>
> Who is still deployed on 1.8.5 or 1.8.4?

EngineYard uses 1.8.5 in most of their servers (AFAIK).

Other VPS/Xen hosts that have ruby pre-installed have 1.8.4 or 1.8.5,
but most of them allow you build ruby from sources.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From wyhaines at gmail.com  Wed Jan  2 16:52:04 2008
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 2 Jan 2008 14:52:04 -0700
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
Message-ID: <f4cd26df0801021352r576c38e9wfc53f4acb5bdc917@mail.gmail.com>

On Jan 2, 2008 1:55 PM, Evan Weaver <evan at cloudbur.st> wrote:
> That's what I should have meant. It could stop being a gem dependency
> but still be a rescued require.
>
> Who is still deployed on 1.8.5 or 1.8.4?

I'm still using 1.8.5 on my production servers.


Kirk Haines

From ezmobius at gmail.com  Wed Jan  2 17:05:51 2008
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Wed, 2 Jan 2008 14:05:51 -0800
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <71166b3b0801021325m1130dc0ve77b4287d640a644@mail.gmail.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
	<71166b3b0801021325m1130dc0ve77b4287d640a644@mail.gmail.com>
Message-ID: <7182DFB0-71AA-4F9A-AF3E-4A0E61E65071@gmail.com>


On Jan 2, 2008, at 1:25 PM, Luis Lavena wrote:

> On Jan 2, 2008 6:55 PM, Evan Weaver <evan at cloudbur.st> wrote:
>> That's what I should have meant. It could stop being a gem dependency
>> but still be a rescued require.
>>
>> Who is still deployed on 1.8.5 or 1.8.4?
>
> EngineYard uses 1.8.5 in most of their servers (AFAIK).
>
> Other VPS/Xen hosts that have ruby pre-installed have 1.8.4 or 1.8.5,
> but most of them allow you build ruby from sources.
>
> --  
> Luis Lavena
> Multimedia systems



We have been updating to 1.8.6 p111 but we do still have a lot of ruby  
1.8.5's out there. But I am in favor of making it an optional  
dependency.

Cheers-
- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ezra at engineyard.com
-- EngineYard.com


From njvack at wisc.edu  Wed Jan  2 17:13:10 2008
From: njvack at wisc.edu (Nathan Vack)
Date: Wed, 2 Jan 2008 16:13:10 -0600
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
Message-ID: <D45B8EAA-6480-4828-A9D5-1DCD992BCC19@wisc.edu>

On Jan 2, 2008, at 2:55 PM, Evan Weaver wrote:

> Who is still deployed on 1.8.5 or 1.8.4?

Debian etch ships 1.8.5.

-Nate

From luislavena at gmail.com  Wed Jan  2 17:16:31 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 2 Jan 2008 20:16:31 -0200
Subject: [Mongrel] [ANN] mongrel_service 0.3.4 released.
Message-ID: <71166b3b0801021416g47b58e1oc4360b22f2922ace@mail.gmail.com>

Hello Guys,

A quick and not so dirty release of mongrel_service.

Main issues got fixed:

    * Strict Gem dependencies for mongrel_service. This version is compatible
      only with mongrel 1.0.x, 1.1.x and with win32-service 0.5.x.

    * Fixed issues realted to Win32::Service and gem_plugin being
registered with
      different names due win32-service changes.

Also this gem is build with 0.9.4 and proper gem platform, so is
compatible with RubyGems 0.9.4 and newer.

I guess will no longer update mongrel_service, mostly since 1.9 need a
few changes in code implementation which need more time that I
currently have available for it.

That doesn't meant is dead, but I'll focus my free time on the
replacement utility.

Regards and everybody have a nice week!

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From barjunk at attglobal.net  Wed Jan  2 19:32:11 2008
From: barjunk at attglobal.net (barsalou)
Date: Wed, 02 Jan 2008 15:32:11 -0900
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <7182DFB0-71AA-4F9A-AF3E-4A0E61E65071@gmail.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
	<71166b3b0801021325m1130dc0ve77b4287d640a644@mail.gmail.com>
	<7182DFB0-71AA-4F9A-AF3E-4A0E61E65071@gmail.com>
Message-ID: <20080102153211.er24653pf4sw04k4@lcgalaska.com>

Quoting Ezra Zygmuntowicz <ezmobius at gmail.com>:

>
> On Jan 2, 2008, at 1:25 PM, Luis Lavena wrote:
>
>> On Jan 2, 2008 6:55 PM, Evan Weaver <evan at cloudbur.st> wrote:
>>> That's what I should have meant. It could stop being a gem dependency
>>> but still be a rescued require.
>>>
>>> Who is still deployed on 1.8.5 or 1.8.4?
>>
>> EngineYard uses 1.8.5 in most of their servers (AFAIK).
>>
>> Other VPS/Xen hosts that have ruby pre-installed have 1.8.4 or 1.8.5,
>> but most of them allow you build ruby from sources.
>>
>> --
>> Luis Lavena
>> Multimedia systems
>
>
>
> We have been updating to 1.8.6 p111 but we do still have a lot of ruby
> 1.8.5's out there. But I am in favor of making it an optional
> dependency.
>

I know of quite a few 1.8.4 deployments out there as well.  Please 
don't exclude these.  We are also working towards getting these 
upgraded.  Release of Ruby 1.9 should help this.

Mike B.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From will at hotgazpacho.com  Thu Jan  3 08:04:04 2008
From: will at hotgazpacho.com (Will Green)
Date: Thu, 03 Jan 2008 08:04:04 -0500
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
Message-ID: <477CDD44.80809@hotgazpacho.com>

CentOS 5 still ships with 1.8.5...

Evan Weaver wrote:
> That's what I should have meant. It could stop being a gem dependency
> but still be a rescued require.
>
> Who is still deployed on 1.8.5 or 1.8.4?
>
> Evan
>
> On Jan 2, 2008 2:57 PM, MenTaLguY <mental at rydia.net> wrote:
>   
>> On Wed, 2 Jan 2008 20:05:13 +0100, "David Vrensk" <david at vrensk.com> wrote:
>>     
>>> I hope I'm wrong here, but the way I understand what you're saying is that
>>> Mongrel will stop patching Ruby once Mongrel is ready to run on Ruby 1.9.
>>> Wouldn't that mean that you at the same time removed support for all Ruby
>>> versions below 1.8.6 p36?
>>>       
>> Well, I'd hope what he meant was that Mongrel would still use fastthread if
>> it was installed, but it would no longer be a dependency of the Mongrel gem.
>>
>> Which would be as it ought to be -- my intent was for fastthread to fill the
>> gap between 1.8 and 1.9, and then eventually go away once people stopped
>> needing/installing it.  But the folks on 1.8.x aren't going away for a while,
>> so I think it's important that Mongrel uses it if it is installed/supported.
>>
>> -mental
>>
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>>     
>
>
>
>   


From lists at ruby-forum.com  Thu Jan  3 09:15:57 2008
From: lists at ruby-forum.com (Chris Armstrong)
Date: Thu, 3 Jan 2008 15:15:57 +0100
Subject: [Mongrel] Mongrel stops to loading the page in browser
Message-ID: <c8dd3eb5cbad19ad2787168d1b2f1444@ruby-forum.com>

Hi all,

I have a problem with mongrel-1.1.2 running with Apache Apache/2.0.61
and MySQL 5.0.45 on FreeBSD 6.1.

I'm developing my application with InstantRails that uses Mongrel and
everything is working great. I have about 30 shops in a table. I also
store the logo images (png files) in the table for each shop. Under
Windows/InstantRails everything is working correct.

When i however copy the application to the Unix Box, start Mongrel and
load the page i get an error in the mongrel.log file with following
text:


** Changing group to "www".
** Changing user to "www".
** Installing debugging prefixed filters. Look in log/mongrel_debug for
the files.
** Starting Rails with development environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no
restart).
** Rails signals registered.  HUP => reload (without restart).  It might
not work well.
** Mongrel 1.1.2 available at 0.0.0.0:3000
** Writing PID file to tmp/pids/mongrel.pid



127.0.0.1 - [Thu, 03 Jan 2008 10:22:49 GMT] "GET /de/page HTTP/1.1"
Thu Jan 03 11:22:51 +0100 2008: Read error: #<Errno::EPERM: Operation
not permitted>
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/http_response.rb:137:in
`write'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/http_response.rb:137:in
`write'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/http_response.rb:103:in
`send_body'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/http_response.rb:147:in
`finished'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel.rb:165:in
`process_client'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel.rb:285:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel.rb:285:in
`initialize'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel.rb:285:in
`new'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel.rb:285:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel.rb:268:in
`initialize'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel.rb:268:in
`new'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel.rb:268:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/configurator.rb:282:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/configurator.rb:281:in
`each'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/configurator.rb:281:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/mongrel_rails:128:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/command.rb:212:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/mongrel_rails:281
/usr/local/bin/mongrel_rails:16:in `load'
/usr/local/bin/mongrel_rails:16

This error message tells me that there is an error in the
http_response.rb file happening at the method send_data. But i could not
determine what the problem is exactly. As everything is working with
InstantRails i really don't know where to start searching the problem as
the code in my eyes should be working.

When i remove the "image_tag" line from the rhtml file so that the
images are not loading, then the browser is loading everything. If the
"image_tag" line is present, then the browser will stop after 2 thirds
of displaying the html.

So it seems an image can not be loaded or displayed.

<% @topshops.each do |shop| %>
          <table width="100%"  border="0" cellspacing="0"
cellpadding="0">
            <tr>
              <td class="shops"><table width="100%"  border="0"
cellspacing="0" cellpadding="5">
                  <tr valign="top">
                    <td width="150"><%=
image_tag("/#{@params[:locale]}/page/show_picture_of_partner/#{shop.id}",
:alt => shop.name) %></td>
                    <td><strong><%= shop.name %></strong><br>
                        <br>
                         <%= shop.shop_description %>
                    </td>
                  </tr>
                  <tr>
                    <td class="details" width="150"><img
src="/images/pagedesign/arrow.gif" width="13" height="13"
align="absmiddle"> <%= link_to "Registrieren", :controller => 'page',
:action => 'register' %></td>
                    <td class="points"><img
src="/images/pagedesign/logo_points.gif" width="13" height="13"
align="absmiddle"> <%= shop.points_text %> <img
src="/images/pagedesign/arrow.gif" width="13" height="13"
align="absmiddle"> <%= link_to "Details", :action => shop.symbol %></td>
                  </tr>
              </table></td>
            </tr>
          </table>
          <br>
<% end %>


show_picture_of_partner:
def show_picture_of_partner
       partner = Partner.find(params[:id])
       send_data(partner.picture_data, :type =>
partner.picture_content_type, :filename => partner.picture_name,
:dispositon => 'inline')
    end

Can anybody tell me what the problem could be? Or what to do better to
get around this problem?

Thanks,
Chris
-- 
Posted via http://www.ruby-forum.com/.

From will at hotgazpacho.com  Thu Jan  3 11:38:44 2008
From: will at hotgazpacho.com (Will Green)
Date: Thu, 03 Jan 2008 11:38:44 -0500 (EST)
Subject: [Mongrel] Interresting Changeset for Rails Trunk...
Message-ID: <1199378324.12566@hotgazpacho.com>

>From http://blog.codefront.net/2008/01/02/whats-new-on-edge-rails-the-pilot/

A native Mongrel handler has been introduced. This is so that it can be worked on independent of Mongrel?s release cycle (the Rails handler is currently in the Mongrel codebase). Jeremy Kemper (bitsweat) has already made a minor performance improvement by moving the mutex from the handler itself into the dispatcher. This means that as Rails gets more threadsafe, the Rails team can push the mutex further down so that it?s not a (scary) giant lock (the existing Mongrel Rails handler has a synchronized block around Rails? dispatcher).

Here's the relevant Changeset URL: http://dev.rubyonrails.org/changeset/8488

From will at hotgazpacho.com  Thu Jan  3 11:41:17 2008
From: will at hotgazpacho.com (Will Green)
Date: Thu, 03 Jan 2008 11:41:17 -0500 (EST)
Subject: [Mongrel] Mongrel stops to loading the page in browser
Message-ID: <1199378477.12850@hotgazpacho.com>

Looks like the user Mongrel is running as (www) does not have permission to access the files:

> Thu Jan 03 11:22:51 +0100 2008: Read error: #<Errno::EPERM: Operation not permitted>

From evan at cloudbur.st  Thu Jan  3 12:45:28 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Thu, 3 Jan 2008 12:45:28 -0500
Subject: [Mongrel] deployment survey
Message-ID: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>

Hello Mongrels,

Building on the last messages about Fastthread, can we get a detailed
survey of the different ways people are deploying their applications?
It will help with near-future Mongrel development.

Please include the following things:

* Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)
* Mongrel version
* Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)
* How many mongrel routes and handlers per route registered (if you
don't know, it's probably <= 2)
* Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
mongrel_cow_cluster, mongrel_experimental...)
* Mongrel runners used (mongrel_rails, mongrel::cluster,
mongrel_service, RV, others... please be *very specific* about which
options of the runner you use. For example, some people use
mongrel::cluster but only for the --clean functionality, not for the
clustering).
* Number of mongrels per server per app
* Monitoring system (runit, monit, god...)
* Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
nginx, pen...)
* HW loadbalancer, if any (Netscaler...)
* Caching strategy (memcached fragments, memcached object, squid,
rails page cache, rails page fragments, ESI)
* Whether you serve media assets via mongrel itself, as opposed to
through a webserver
* Operating system including distribution or version (OS X 10.4.10,
Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)
* Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
Arm (ha), JRuby)
* CPU count
* Ruby version including custom distribution patches,
(1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
note where you got it, in case it isn't clear, for example, OS X 10.5
built-in, Ubuntu apt, Instant Rails, direct compile from source)
* Rubygems (yes/no, version)

Please mention anything else about your system that's kind of weird,
and anything that's been particularly troublesome regarding mongrel
deployment.

Evan

PS. You can get some of the Ruby information via the 'tattle' gem:

$ gem install tattle --ignore-dependencies
$ tattle report


-- 
Evan Weaver
Cloudburst, LLC

From jeremy at bitsweat.net  Thu Jan  3 14:12:24 2008
From: jeremy at bitsweat.net (Jeremy Kemper)
Date: Thu, 3 Jan 2008 11:12:24 -0800
Subject: [Mongrel] Interresting Changeset for Rails Trunk...
In-Reply-To: <1199378324.12566@hotgazpacho.com>
References: <1199378324.12566@hotgazpacho.com>
Message-ID: <69a2885c0801031112n3daab46fn85bcb943badc861d@mail.gmail.com>

On 1/3/08, Will Green <will at hotgazpacho.com> wrote:
> >From http://blog.codefront.net/2008/01/02/whats-new-on-edge-rails-the-pilot/
>
> A native Mongrel handler has been introduced. This is so that it can be worked on independent of Mongrel's release cycle (the Rails handler is currently in the Mongrel codebase). Jeremy Kemper (bitsweat) has already made a minor performance improvement by moving the mutex from the handler itself into the dispatcher. This means that as Rails gets more threadsafe, the Rails team can push the mutex further down so that it's not a (scary) giant lock (the existing Mongrel Rails handler has a synchronized block around Rails' dispatcher).
>
> Here's the relevant Changeset URL: http://dev.rubyonrails.org/changeset/8488

Note, this is still an experiment, not the default. You can use the
native handler on Rails trunk using script/server new_mongrel.

For starters, I imported a pared-down Rails handler and mongrel_rails'
GemPlugin commands so they'll work with script/server directly. I
mount a DirHandler before the Rails handler and pass through missing
files rather than handling both in the Rails handler. This needs a
small DirHandler change to pass through missing files instead of
sending 404.

I think importing the GemPlugins may be overkill, but I couldn't see
how to massage Start#run into setting up the listener how I'd like,
otherwise. I think a lot of the goodies in there, like pidfile
management and debug handling, could be extracted. It'd make building
your own mongrel runner easier.

Next steps. On the Mongrel handler side: wean Rails off the CGI
wrapper. On the Rails side: work directly with Mongrel request +
response; use a wrapper to cajole CGI::Session into compatibility;
move route recognition and sending response body out of the mutex.

jeremy

From seanmichaelbrown at gmail.com  Thu Jan  3 14:52:21 2008
From: seanmichaelbrown at gmail.com (Sean Brown)
Date: Thu, 3 Jan 2008 14:52:21 -0500
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <1086fb5f0801031152k44d8c069ld7280891480163b4@mail.gmail.com>

On Jan 3, 2008 12:45 PM, Evan Weaver <evan at cloudbur.st> wrote:
> Hello Mongrels,
>
> Building on the last messages about Fastthread, can we get a detailed
> survey of the different ways people are deploying their applications?
> It will help with near-future Mongrel development.


Evan,

How would you like us to report this?  To the whole mongrel list, or
just to you?  Any particular format helpful?

-- 

Sean Brown
seanmichaelbrown at gmail.com

From alexey.verkhovsky at gmail.com  Thu Jan  3 15:00:09 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Thu, 3 Jan 2008 13:00:09 -0700
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <3945c4270801031200u5212c160me37db47136d9f508@mail.gmail.com>

For cruisecontrolrb.thoughtworks.com (which basically runs on
RubyWorks 1.1 RPMs with somewhat modified configuration):

> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)
Rails

> * Mongrel version
1.0.1

> * Mongrel handlers used
rails, dirhandler

> * How many mongrel routes and handlers per route registered
mongrel_rails defaults

> * Any Mongrel plugins used
none

> * Mongrel runners used
mongrel_rails, non-detached (i.e., no --daemon option), launched from runit

> * Number of mongrels per server per app
4. No reason other than it's a sensible default number (i.e., never
needed to optimize it).

> * Monitoring system
monit and runit
technically, runit is not a monitoring system

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer, nginx, pen...)
HAProxy

> * Caching strategy
Rails page cache

> * Whether you serve media assets via mongrel itself, as opposed to through a webserver.
Apache via mod_rewrite URL matching

> * Operating system including distribution or version
Linux (CentOS 5)

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC, Arm (ha), JRuby)
x86_64

> * CPU count
4 dual core CPUs on a VM host running several virtual machines.

> * Ruby version including custom distribution patches
1.8.6 p36, from RubyWorks RPM repo. Upgrade to p111 is planned soon-ish.

Lots of people are running 1.8.5 p35 with patches, as that is what
mainstream Linux distros (RedHat, Debian, Ubuntu) provide.

> * Rubygems (yes/no, version)
yes, 0.9.4

> anything weird
Nothing that you don't already know about.

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

From jftucker at gmail.com  Thu Jan  3 15:00:46 2008
From: jftucker at gmail.com (James Tucker)
Date: Thu, 3 Jan 2008 16:00:46 -0400
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <39304571-4DD4-4284-99FE-ABF04315E304@gmail.com>


On 3 Jan 2008, at 13:45, Evan Weaver wrote:

> Hello Mongrels,
>
> Building on the last messages about Fastthread, can we get a detailed
> survey of the different ways people are deploying their applications?
> It will help with near-future Mongrel development.
>
> Please include the following things:
>
> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA,  
> Rack...)

Rails mostly, some camping, some ramaze in the works.

> * Mongrel version

Latest, after security release.

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

Standard framework handlers, and a couple of nice Racks.

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

Indeed.

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

None to date.

> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

Standard development runners (script/server) are used by most of our  
devs. One server uses mongrel_rails + the Swiftiply patches for  
evented mongrel.

> * Number of mongrels per server per app

Windows 2003 Server we setup via Apache on a quad core, with 10  
mongrels for the best performance. I had numbers somewhere, but IIRC  
it reached 4-8k req/s.
On FreeBSD and Debian, we're running nginx (and it's great), I don't  
have performance numbers for these configurations, as we're more  
focused on static file handling direct out of nginx there.

> * Monitoring system (runit, monit, god...)

Windows Services + a custom service wrapper.
djbs daemontools.

God is no good for us as it's not cross platform, same goes for monit.  
daemontools falls in the same category, but it manages far more than  
just webservers for us, and has been around for quite some time.

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

mod_proxy and nginx for the respective platforms, as noted above.

> * HW loadbalancer, if any (Netscaler...)

None required to date.

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

Memcached, large disk caches.

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

We've been doing very large numbers of small assets (think tiny  
images), and nginx performs wonderfully at that.

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

Production: Windows 2003 Server, FreeBSD, Debian, Solaris very briefly  
(and no more).
Development: Debian, OS X, Windows XP SP2.

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

To date, x86 across the board, although many of the machines are x64/ 
IA64 capable.

> * CPU count

In production, we have 7 CPUs out there. Largest is a quad core.

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)

Mostly 1.8.6p110 as far as I know. Windows devs run the OCI.

> * Rubygems (yes/no, version)

yes, 0.9.4+

> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.

Honestly, Mongrel has been *the* easy bit, and you can quote me on  
that should you so desire.

>
>
> Evan
>
> PS. You can get some of the Ruby information via the 'tattle' gem:
>
> $ gem install tattle --ignore-dependencies
> $ tattle report
>
>
> -- 
> Evan Weaver
> Cloudburst, LLC
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From alexey.verkhovsky at gmail.com  Thu Jan  3 15:52:23 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Thu, 3 Jan 2008 13:52:23 -0700
Subject: [Mongrel] deployment survey
In-Reply-To: <1086fb5f0801031152k44d8c069ld7280891480163b4@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
	<1086fb5f0801031152k44d8c069ld7280891480163b4@mail.gmail.com>
Message-ID: <3945c4270801031252y7b322968hae6b7b54462e793e@mail.gmail.com>

On Jan 3, 2008 12:52 PM, Sean Brown <seanmichaelbrown at gmail.com> wrote:
> How would you like us to report this?  To the whole mongrel list, or
> just to you?

I'm not Evan, but would still love to see the responses.

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

From evan at cloudbur.st  Thu Jan  3 16:11:04 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Thu, 3 Jan 2008 16:11:04 -0500
Subject: [Mongrel] deployment survey
In-Reply-To: <1086fb5f0801031152k44d8c069ld7280891480163b4@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
	<1086fb5f0801031152k44d8c069ld7280891480163b4@mail.gmail.com>
Message-ID: <b6f68fc60801031311l391300a7o2581a9213ee0b295@mail.gmail.com>

Either is fine. If you're not comfortable sending it to the list, then
just send it to me.

Just an email reply is enough.

Evan

On Jan 3, 2008 2:52 PM, Sean Brown <seanmichaelbrown at gmail.com> wrote:
> On Jan 3, 2008 12:45 PM, Evan Weaver <evan at cloudbur.st> wrote:
> > Hello Mongrels,
> >
> > Building on the last messages about Fastthread, can we get a detailed
> > survey of the different ways people are deploying their applications?
> > It will help with near-future Mongrel development.
>
>
> Evan,
>
> How would you like us to report this?  To the whole mongrel list, or
> just to you?  Any particular format helpful?
>
> --
>
> Sean Brown
> seanmichaelbrown at gmail.com
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From dave at cheney.net  Thu Jan  3 16:11:06 2008
From: dave at cheney.net (Dave Cheney)
Date: Fri, 4 Jan 2008 08:11:06 +1100
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <552B73FE-8151-4290-B3C5-C67CE2139D74@cheney.net>


On 04/01/2008, at 4:45 AM, Evan Weaver wrote:

> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA,  
> Rack...)

RoR 2.0.2
> * Mongrel version

1.0.1

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

Rails

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

I guess that means <= 2

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

mongrel_cluster

> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

custom scripts to allow monit to restart failed mongrels with the  
correct environment

> * Number of mongrels per server per app

14, split into 3 groups, handling different URL patterns

> * Monitoring system (runit, monit, god...)

Monit + cacti

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

nginx

> * HW loadbalancer, if any (Netscaler...)

Dunno, we rent time on our hosting centers LB

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

Memcache for the app, Varnish in front of asset hosts

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

Hell no, nginx + varnish

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

OS X Tiger Server, moving to Leopard server ASAP

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

x86_64, but under OS X ruby has 32bit bindings only

> * CPU count

8 cores in the app server cluster ATM

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)

1.8.6p110+threadhooks from macports

> * Rubygems (yes/no, version)

Dunno, latest, pretty habitual about gem update --system

From casey at ravelry.com  Thu Jan  3 16:48:23 2008
From: casey at ravelry.com (casey at ravelry.com)
Date: Thu, 3 Jan 2008 16:48:23 -0500 (EST)
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801031311l391300a7o2581a9213ee0b295@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
	<1086fb5f0801031152k44d8c069ld7280891480163b4@mail.gmail.com>
	<b6f68fc60801031311l391300a7o2581a9213ee0b295@mail.gmail.com>
Message-ID: <Pine.OSX.4.64.0801031634360.419@dozer.local>

(I don't have Evan's original message, hopefully this gets threaded 
into the right spot)

* Framework       : Rails (2.0)
* Mongrel version : 1.1.3
* Handlers        : just rails
* Plugins         : Swiftiply evented Mongrel (not a plugin, per se)
* Runners         : mongrel_rails cluster::start/stop/restart --clean
* Number          : 70 mongrels (4 virtual servers, 1 app)
* Monitoring      : nagios
* Proxy           : nginx w/ fair module [1]
* HW balancer     : none
* Caching         : memcached fragments, memcached objects
* Assets/mongrel  : no
* OS              : Gentoo Linux Xen kernel 2.6.20-xen-r2
* arch            : x86_64 with 32 bit userland (64 bit kernel only)
* CPU count       : varies by VM, but ~8 cores total for mongrels
* Ruby            : ruby 1.8.6 (2007-06-07 patchlevel 36)
* Rubygems        : 0.9.4

I'm also using mongrel_proctitle, which I had to hack to get it to 
work with Swiftcore's evented Mongrel. It's pretty cool and definitely 
comes in handy since I am using the fair proxy balancer nginx module.

http://purefiction.net/mongrel_proctitle/

[1] http://brainspl.at/articles/2007/11/09/a-fair-proxy-balancer-for-nginx-and-mongrel


Casey

From dave at cheney.net  Thu Jan  3 17:25:27 2008
From: dave at cheney.net (Dave Cheney)
Date: Fri, 4 Jan 2008 09:25:27 +1100
Subject: [Mongrel] Interresting Changeset for Rails Trunk...
In-Reply-To: <69a2885c0801031112n3daab46fn85bcb943badc861d@mail.gmail.com>
References: <1199378324.12566@hotgazpacho.com>
	<69a2885c0801031112n3daab46fn85bcb943badc861d@mail.gmail.com>
Message-ID: <58D235D8-F4D9-4E28-B9E1-EB372D3C784D@cheney.net>

Awesome work Jeremy. Let me know if you need beta testers.

Cheers

Dave

On 04/01/2008, at 6:12 AM, Jeremy Kemper wrote:

>
> Next steps. On the Mongrel handler side: wean Rails off the CGI
> wrapper. On the Rails side: work directly with Mongrel request +
> response; use a wrapper to cajole CGI::Session into compatibility;
> move route recognition and sending response body out of the mutex.


From jason.young at ncsu.edu  Thu Jan  3 17:20:21 2008
From: jason.young at ncsu.edu (Jason Young)
Date: Thu, 3 Jan 2008 17:20:21 -0500
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <477CDD44.80809@hotgazpacho.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
	<477CDD44.80809@hotgazpacho.com>
Message-ID: <EDCE0344-32F0-4D86-A6A1-588AEFA42A93@ncsu.edu>


On Jan 3, 2008, at 8:04 AM, Will Green wrote:

> CentOS 5 still ships with 1.8.5...

And by extension (or perhaps pretension) so does Red Hat Enterprise  
Linux version 5 - which is the licensed linux at NC State University  
(and which I use for most of extension.org's servers).   I've been  
hand replacing the RHELv5 RPM's with a configure/make/make install  
version of Ruby 1.8.6 - but until RHELv6 comes out, I seriously doubt  
many of the RHEL customers are going to have a 1.8.6 version of Ruby -  
except for the crazy ones like me.

We are going to be using LogicWorks for hosting portions of  
extension.org and they are also apparently a RHEL shop.

I doubt 1.8.5 is going away anytime soon.

Jason

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason Young --  Systems Manager, eXtension
http://about.extension.org/wiki/Jason_Young
______________________________________




From wyhaines at gmail.com  Thu Jan  3 17:52:55 2008
From: wyhaines at gmail.com (Kirk Haines)
Date: Thu, 3 Jan 2008 15:52:55 -0700
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <f4cd26df0801031452o659a521q37d60cd64cf4bd35@mail.gmail.com>

On Jan 3, 2008 10:45 AM, Evan Weaver <evan at cloudbur.st> wrote:

For what it's worth, though I am definitely a statistical outlier:

> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)

IOWA for production.  Dabble with all of them, though, for testing things.

> * Mongrel version

1.1.3

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

Just whatever is appropriate for the framework.  The mongrel support
is built into IOWA.

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

Precious few.

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

No

> * Mongrel runners used (mongrel_rails, mongrel::cluster,

None

> * Number of mongrels per server per app

Where I use it, 1.

> * Monitoring system (runit, monit, god...)

They never crash; never fail.  So I don't bother to monitor them specifically.

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

Swiftiply.

> * HW loadbalancer, if any (Netscaler...)

None.

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

Static page caching handled by Swiftiply, or no caching.

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

No.

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

RHEL 4, Ubuntu Server 6.10, CentOS 4

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

Linux server2.enigo.com 2.6.9-55.0.9.ELlargesmp #1 SMP & some Linux
2.4.x kernel boxes.

> * CPU count

1, 2, and 4 cpu boxes right now.

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)

Primarily 1.8.5 in production, though I have the most recent 1.8.6
patch level, 1.9.0 and jruby around for testing.

> * Rubygems (yes/no, version)

Yes.  I have not upgraded to the newest release yet.  Still on 0.9.4.

As for weird stuff....honestly, I don't really run all of Mongrel in
production except on one or two older sites.  Most of my production
apps only use the Mongrel HTTP parser.  So most of my mongrel usage
these days involves testing it on various versions of Ruby and in
various deployments and contortions.


Kirk Haines

From ezmobius at gmail.com  Thu Jan  3 18:48:45 2008
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Thu, 3 Jan 2008 15:48:45 -0800
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <983569BA-CD34-4B95-9FD6-9DB1668A904F@gmail.com>


On Jan 3, 2008, at 9:45 AM, Evan Weaver wrote:
>
> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA,  
> Rack...)

merb, rails, camping, nitro, rack
>
> * Mongrel version

1.0.1 thru 1.1.3

>
> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

rails, dirhandler,upload_progress_handler,secure_download, many more  
custoemr handlers


> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

up to 15 max. usually 2-4


>
> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

mongrel_upload_progress, mongrel_gzip
>
> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

mongrel_cluster but only for the --clean option. woudl love to see -- 
clean in mongrel itself so i no longer need mongrel cluster.

>
> * Number of mongrels per server per app

3-25 per server, usually closer to 3-5 per cpu core

> * Monitoring system (runit, monit, god...)

monit, god , nagios

>
> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

Nginx, swiftiply, apache, haproxy


> * HW loadbalancer, if any (Netscaler...)

coyote point equalizers, Linux LVS load balancers.

>
> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

page caching, fragment caching on GFS filesystem . memcached fragments  
and sessions and caches.

>
> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

via nginx


> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

custom variant of Gentoo linux

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

Linux ey00-s00141 2.6.18-xenU #1 SMP Fri Jun 15 17:50:34 PDT 2007  
x86_64 Dual Core AMD Opteron(tm) Processor 265 AuthenticAMD GNU/Linux

  and

Linux ey01-s00141 2.6.18-xenU #1 SMP Fri Jun 15 17:50:34 PDT 2007  
x86_64 Intel(R) Xeon(R) CPU E5345 @ 2.33GHz GenuineIntel GNU/Linux

> * CPU count

Hmm...  lets see here. somewhere around  400 ?


>
> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)
> * Rubygems (yes/no, version)

1.8.5 from gentoo's portage
1.8.6p111 from portage

> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.

Please let's add --clean to mongrel itself.  Other then that the only  
thing might be to add some additional logic to the gracefull shutdown  
of a mongrel server. Say if it tries to reap old threads for more then  
30 seconds, just have it terminate violently.


> Cheers-

- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ezra at engineyard.com
-- EngineYard.com


From luislavena at gmail.com  Thu Jan  3 19:49:36 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 3 Jan 2008 22:49:36 -0200
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <71166b3b0801031649u79f2eca4l1fc83e87f9362915@mail.gmail.com>

On Jan 3, 2008 3:45 PM, Evan Weaver <evan at cloudbur.st> wrote:
> Hello Mongrels,
>
> Building on the last messages about Fastthread, can we get a detailed
> survey of the different ways people are deploying their applications?
> It will help with near-future Mongrel development.
>
> Please include the following things:
>
> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)

Rails, Merb, Small little MVC proof of concept :-)

> * Mongrel version

1.0.2 mostly.

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

Rails, DirHandler and custom made.

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

<= 2

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

none

> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

mongrel_rails (development) mongrel_service (deployment)

> * Number of mongrels per server per app

3

> * Monitoring system (runit, monit, god...)

Custom made

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

Custom made TCP balancer, no proxy.

> * HW loadbalancer, if any (Netscaler...)

None

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

No caching

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

Via Mongrel

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

Windows XP SP2 Professional
Windows 2003 Server
Windows XP SP2 Professional x64 Edition

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

x86 and x86_64

> * CPU count

1, 2 and 4 cores, single CPU
2 cores in dual-cpu installations

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)
> * Rubygems (yes/no, version)
>

1.8.5-p114, i386-mswin32 build (VC6)
1.8.6-p111, i386-mingw32 build (GCC)

Both version build from scratch.

> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.

Well, it's Windows, what more weird than that could be added? ;-)

But seriously, no IIS on these installations.

All the deployment process is being distributed by Windows Installer
packages and rubygems. The distribution or deployment of updates for
the application is done through rubygems.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From evan at cloudbur.st  Thu Jan  3 20:15:53 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Thu, 3 Jan 2008 20:15:53 -0500
Subject: [Mongrel] deployment survey
In-Reply-To: <983569BA-CD34-4B95-9FD6-9DB1668A904F@gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
	<983569BA-CD34-4B95-9FD6-9DB1668A904F@gmail.com>
Message-ID: <b6f68fc60801031715i383b1669k8a4bc0203f339638@mail.gmail.com>

> Please let's add --clean to mongrel itself.  Other then that the only
> thing might be to add some additional logic to the gracefull shutdown
> of a mongrel server. Say if it tries to reap old threads for more then
> 30 seconds, just have it terminate violently.

Those are some of our goals for an eventual new runner.

Evan

On Jan 3, 2008 6:48 PM, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> On Jan 3, 2008, at 9:45 AM, Evan Weaver wrote:
> >
> > * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA,
> > Rack...)
>
> merb, rails, camping, nitro, rack
> >
> > * Mongrel version
>
> 1.0.1 thru 1.1.3
>
> >
> > * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)
>
> rails, dirhandler,upload_progress_handler,secure_download, many more
> custoemr handlers
>
>
> > * How many mongrel routes and handlers per route registered (if you
> > don't know, it's probably <= 2)
>
> up to 15 max. usually 2-4
>
>
> >
> > * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> > mongrel_cow_cluster, mongrel_experimental...)
>
> mongrel_upload_progress, mongrel_gzip
> >
> > * Mongrel runners used (mongrel_rails, mongrel::cluster,
> > mongrel_service, RV, others... please be *very specific* about which
> > options of the runner you use. For example, some people use
> > mongrel::cluster but only for the --clean functionality, not for the
> > clustering).
>
> mongrel_cluster but only for the --clean option. woudl love to see --
> clean in mongrel itself so i no longer need mongrel cluster.
>
> >
> > * Number of mongrels per server per app
>
> 3-25 per server, usually closer to 3-5 per cpu core
>
> > * Monitoring system (runit, monit, god...)
>
> monit, god , nagios
>
> >
> > * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> > nginx, pen...)
>
> Nginx, swiftiply, apache, haproxy
>
>
> > * HW loadbalancer, if any (Netscaler...)
>
> coyote point equalizers, Linux LVS load balancers.
>
> >
> > * Caching strategy (memcached fragments, memcached object, squid,
> > rails page cache, rails page fragments, ESI)
>
> page caching, fragment caching on GFS filesystem . memcached fragments
> and sessions and caches.
>
> >
> > * Whether you serve media assets via mongrel itself, as opposed to
> > through a webserver
>
> via nginx
>
>
> > * Operating system including distribution or version (OS X 10.4.10,
> > Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)
>
> custom variant of Gentoo linux
>
> > * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> > Arm (ha), JRuby)
>
> Linux ey00-s00141 2.6.18-xenU #1 SMP Fri Jun 15 17:50:34 PDT 2007
> x86_64 Dual Core AMD Opteron(tm) Processor 265 AuthenticAMD GNU/Linux
>
>   and
>
> Linux ey01-s00141 2.6.18-xenU #1 SMP Fri Jun 15 17:50:34 PDT 2007
> x86_64 Intel(R) Xeon(R) CPU E5345 @ 2.33GHz GenuineIntel GNU/Linux
>
> > * CPU count
>
> Hmm...  lets see here. somewhere around  400 ?
>
>
> >
> > * Ruby version including custom distribution patches,
> > (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> > note where you got it, in case it isn't clear, for example, OS X 10.5
> > built-in, Ubuntu apt, Instant Rails, direct compile from source)
> > * Rubygems (yes/no, version)
>
> 1.8.5 from gentoo's portage
> 1.8.6p111 from portage
>
> > Please mention anything else about your system that's kind of weird,
> > and anything that's been particularly troublesome regarding mongrel
> > deployment.
>
> Please let's add --clean to mongrel itself.  Other then that the only
> thing might be to add some additional logic to the gracefull shutdown
> of a mongrel server. Say if it tries to reap old threads for more then
> 30 seconds, just have it terminate violently.
>
>
> > Cheers-
>
> - Ezra Zygmuntowicz
> -- Founder & Software Architect
> -- ezra at engineyard.com
> -- EngineYard.com
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From jw at innerewut.de  Thu Jan  3 15:10:48 2008
From: jw at innerewut.de (Jonathan Weiss)
Date: Thu, 03 Jan 2008 21:10:48 +0100
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <477D4148.8050005@innerewut.de>

Evan Weaver schrieb:
> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)

Rails

> * Mongrel version

1.1.3

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

rails

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

no extra handlers

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

mongrel_cluster

> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

On all servers we are using:

mongrel_rails cluster::start -C /path/to/config --clean

> * Number of mongrels per server per app

~8

> * Monitoring system (runit, monit, god...)

monit

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

mod_proxy_balancer

> * HW loadbalancer, if any (Netscaler...)

OpenBSD 4.2 PF + CARP boxes

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

most of the time memcached fragments.

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

Always through Apache

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

FreeBSD 7, OpenBSD 4.2, and Debian

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

i368 and AMD64

> * CPU count

Typically 2

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)

1.8.6p110

> * Rubygems (yes/no, version)

1.0.1

Jonathan


-- 
Jonathan Weiss
http://blog.innerewut.de

From simon at rozet.name  Fri Jan  4 03:23:44 2008
From: simon at rozet.name (Simon Rozet)
Date: Fri, 4 Jan 2008 09:23:44 +0100
Subject: [Mongrel] Howto write a mongrel handler for a CGI app using
	CGIWrapper
Message-ID: <8878c9770801040023m7ca73d0cn41cfb55b45fc02db@mail.gmail.com>

Hello,

Just for further reference in case of someone else want to do the same :

I wanted to write a mongrel for a CGI app :
[[[
require 'cgi'
require 'foo'

cgi = CGI.new

if !cgi['uri'] || (cgi['uri'] == '')
  Foo.error "URI argument is required"
end

uri = cgi['uri']
user = cgi['username']
pass = cgi['password']

foo = Foo.new(:output => 'html')

if user == ''
  foo.check(uri)
else
  foo.check(uri, user, pass)
end
foo.report
]]]

Here is the mongrel version, using Mongrel::CGIWrapper :
[[[
require 'mongrel'
require 'cgi'
require 'foo'

class AppHandler < Mongrel::HttpHandler
  def process(request, response)
    cgi = Mongrel::CGIWrapper.new(request, response)

    if !cgi['uri'] || (cgi['uri'] == '')
      response.start(200, true) do |header, body|

        Foo.error("URI argument is required", output=body)
      end
    end

    format = request.params['HTTP_ACCEPT'] == 'text/plain' ? 'text' : 'html'
    ape = Ape.new({ :crumbs => true, :output => format })

    if cgi['user'] && cgi['pass']
      ape.check(cgi['uri'], cgi['user'], cgi['pass'])
    else
      ape.check(cgi['uri'])
    end

    response.start(200, true) do |head, body|
      ape.report(output=body)
    end
  end
end

h = Mongrel::HttpServer.new('0.0.0.0', 4000)
h.register('/', Mongrel::RedirectHandler.new('/ape/index.html'))
h.register('/ape', Mongrel::DirHandler.new(File.dirname(__FILE__) +
'/layout', true))
h.register('/atompub/go', ApeHandler.new)
h.run.join
]]]

-- 
Simon Rozet <simon at rozet.name>

From simon at rozet.name  Fri Jan  4 03:31:46 2008
From: simon at rozet.name (Simon Rozet)
Date: Fri, 4 Jan 2008 09:31:46 +0100
Subject: [Mongrel] Howto write a mongrel handler for a CGI app using
	CGIWrapper
In-Reply-To: <8878c9770801040023m7ca73d0cn41cfb55b45fc02db@mail.gmail.com>
References: <8878c9770801040023m7ca73d0cn41cfb55b45fc02db@mail.gmail.com>
Message-ID: <8878c9770801040031ta2967f8t374cc9d46f7fdcc2@mail.gmail.com>

On 1/4/08, Simon Rozet <simon at rozet.name> wrote:
> Hello,
>
> Just for further reference in case of someone else want to do the same :

Err, sorry. I unwittingly hit <tab> <return> ... so here is the
correct message :

> I wanted to write a mongrel handler for a CGI app :
> [[[
> require 'cgi'
> require 'foo'
>
> cgi = CGI.new
>
> if !cgi['uri'] || (cgi['uri'] == '')
>   Foo.error "URI argument is required"
> end
>
> uri = cgi['uri']
> user = cgi['username']
> pass = cgi['password']
>
> foo = Foo.new(:output => 'html')
>
> if user == ''
>   foo.check(uri)
> else
>   foo.check(uri, user, pass)
> end
> foo.report
> ]]]

Here is the mongrel version, using Mongrel::CGIWrapper :
[[[
require 'mongrel'
require 'cgi'
require 'foo'

class FooHandler < Mongrel::HttpHandler
 def process(request, response)
   cgi = Mongrel::CGIWrapper.new(request, response)

   if !cgi['uri'] || (cgi['uri'] == '')
     response.start(200, true) do |header, body|
       # Foo.error accept an IO object to write to
       Foo.error("URI argument is required", output=body)
     end
   end

   format = request.params['HTTP_ACCEPT'] == 'text/plain' ? 'text' : 'html'
   ape = Foo.new(:output => format)

   if cgi['user'] && cgi['pass']
     Foo.check(cgi['uri'], cgi['user'], cgi['pass'])
   else
     Foo.check(cgi['uri'])
   end

   response.start(200, true) do |head, body|
     Foo.report(output=body)
   end
 end
end

h = Mongrel::HttpServer.new('0.0.0.0', 5000)
h.register('/foo', FooHandler.new)
h.run.join
]]]

That's it. Now I can launch the app from the command line without the
pain of any server configuration. Thanks to Evan for pointing me to
the right direction btw


-- 
Simon Rozet <simon at rozet.name>

From igor at pokelondon.com  Fri Jan  4 05:23:27 2008
From: igor at pokelondon.com (Igor Clark)
Date: Fri, 4 Jan 2008 10:23:27 +0000
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <29FB335C-2CF5-4483-8223-9C1FDDAC1AD3@pokelondon.com>

Hello,

On 3 Jan 2008, at 17:45, Evan Weaver wrote:

> Building on the last messages about Fastthread, can we get a detailed
> survey of the different ways people are deploying their applications?
> It will help with near-future Mongrel development.

We have a few machines with different setups depending on when they  
were deployed - some stuff from 2005 is still on Apache2/FastCGI,  
which is slightly upsetting, but the most recent apps are as follows,  
and new ones will be similar, though perhaps with the addition of  
swiftiply.

> Please include the following things:
>
> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA,  
> Rack...)

Rails, currently 1.2.3. Looking at Merb right now.

> * Mongrel version

1.1.3

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

rails

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

So probably <= 2 ;-)

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

None

> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

mongrel::cluster for managing all mongrels.

> * Number of mongrels per server per app

This is still moot for us really; we're trying to work out the best  
profile per app, as we do a lot of short-lived campaign-based sites.  
We had an app get whacked a few weeks ago with 16 mongrels running  
behind nginx, and the process load was getting really high. Initial  
thought was to up the number of mongrels so they could cut through the  
queue quicker, but of course all this did was increase memory usage  
significantly, meaning with 32 mongrels starting to eat up to 230MB of  
RAM each, the system started thrashing pretty quickly. So we killed  
them and cut it down to 8 and things actually seemed a lot smoother,  
but by that time the load had dropped significantly, so it's hard to  
tell.

In summary, we'll most likely start out with 8 and see how it goes.

> * Monitoring system (runit, monit, god...)

Ahem ... just getting going with monit

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

latest nginx, 0.5.xx branch

> * HW loadbalancer, if any (Netscaler...)

n/a

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

memcached objects, rails page cache as appropriate.

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

Any flat files go out direct through nginx, doesn't seem any point in  
loading mongrel with this when nginx is sooo fast.

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

CentOS 5

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

Linux xxx.xxx.xxx 2.6.9-42.ELsmp #1 SMP Sat Aug 12 09:39:11 CDT 2006  
i686 i686 i386 GNU/Linux

> * CPU count

dual-core xeon 3.0ghz

Database is on an identical separate machine in the instance I'm  
getting stats from, might be on the same host for other apps.

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)

ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-linux] - compiled from  
source.

After reading the recent threads this is going to move up to a later  
patchlevel!

> * Rubygems (yes/no, version)

yes, recently upgraded from 0.94 to 1.0.1

> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.

To be honest since mongrel_cluster came out it's been relatively  
trouble-free. Well, compared to Apache ;-)
Starting and stopping can be a bit temperamental when instances have  
died or been killed outside mongrel_cluster, but I guess that's to be  
expected, and as I understand it that's a cluster issue rather than a  
mongrel issue per se.

The only real issue is memory usage. When we see 230MB mongrels as  
above when most stuff is being served out of memcached, leaks spring  
to mind, but we've so far been unsucessful in establishing whether  
it's in our code, a plug-in, the framework, whether it's related to  
the unpatched ruby, etc ...

> PS. You can get some of the Ruby information via the 'tattle' gem:
>
> $ gem install tattle --ignore-dependencies
> $ tattle report


user_key,
prefix, /poke/software/server/install/ruby-1.8.6
ruby_version, 1.8.6
host_vendor, pc
ruby_install_name, ruby
build, i686-pc-linux-gnu
target_cpu, i686
arch, i686-linux
rubygems_version, 1.0.1
SHELL, /bin/sh
host_os, linux-gnu
report_time, Fri Jan 04 09:48:29 +0000 2008
host_cpu, i686
LIBRUBY, libruby-static.a
LIBRUBY_SO, libruby.so.1.8.6
target, i686-pc-linux-gnu

Incidentally the site that got hammered is http://www.goodthingsshouldneverend.co.uk/
It's supposed to be a "never-ending web page" - imagine my delight  
when I heard that brief for the first time!

Cheers guys, keep up the great work.
Igor

--
Igor Clark // POKE // 10 Redchurch Street // E2 7DD // +44 (0)20 7749  
5355 // www.pokelondon.com





From johan at johansorensen.com  Fri Jan  4 06:06:42 2008
From: johan at johansorensen.com (=?ISO-8859-1?Q?Johan_S=F8rensen?=)
Date: Fri, 4 Jan 2008 12:06:42 +0100
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <9e0f31700801040306m4c2088ees11d22645ee54733d@mail.gmail.com>

On Jan 3, 2008 6:45 PM, Evan Weaver <evan at cloudbur.st> wrote:

> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)


Rails, Rack apps, Merb

playing around with random ones too from time to time


> * Mongrel version


1.0.1, 1.1.3


> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)


rails, some custom ones (mostly for dev/play)


> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)


< 2


> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)


mongrel_rails


> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).


mongrel_cluster, mongrel_rails, inhouse thing at $DAYJOB


> * Number of mongrels per server per app


generally 1 to ~15 depending on app and framework


> * Monitoring system (runit, monit, god...)


monit, god


> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)


nginx


> * HW loadbalancer, if any (Netscaler...)


not currently


> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)


memcached (fragments, + objects + other that fits), memory, disk (such as
rails' page caching), looking at varnish (with ESI)


> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver


webserver, mongrel for processed/generated images (which are then cached)


>
> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)


Debian/Ubuntu (6&7). OSX for dev


> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)


x86_64, i386

Did actually try and make mongrel run on (nokias) ARM one evening for fun,
but their crosscompiling env was a PITA.


> * CPU count


typically 2-4

* Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)


OSX 10.5 supplied ruby (ruby 1.8.6 (2007-09-24 patchlevel 111) [
universal-darwin9.0])
ruby 1.8.6 (2007-03-13 patchlevel 0) [x86_64-linux]
ruby 1.8.6 (2007-06-07 patchlevel 36) [x86_64-linux]
ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]



>
> * Rubygems (yes/no, version)


yes,  1.0.1 and 0.9.x


> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.


Different mongrel-groups balanced by url  on some boxes
running the nginx "fair" balancer patch on some boxes (though not really
mongrel related)

JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080104/aa8b781a/attachment.html 

From armin at personifi.com  Fri Jan  4 02:54:58 2008
From: armin at personifi.com (Armin Roehrl)
Date: Fri, 04 Jan 2008 08:54:58 +0100
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <477DE652.70500@personifi.com>


> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)
>   
rack
> * Mongrel version
>   
1.0.4
> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)
>   
rack
> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)
>   
<=2
> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)
>   
none
> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).
>   
? none I think.
> * Number of mongrels per server per app
>   
depends on the application 1-100
> * Monitoring system (runit, monit, god...)
>   
simple self-written scripts
> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)
>   
nginx
> * HW loadbalancer, if any (Netscaler...)
>   
none
> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)
>   
memcached & self-grown hacks.
> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver
>   
no
> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)
>   
gentoo linux
> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)
>   
Linux prod8 2.6.22-gentoo-r8-a #1 SMP Wed Oct 3 06:41:23 CDT 2007 x86_64 
Dual-Core AMD Opteron(tm) Processor 8212 AuthenticAMD GNU/Linux

> * CPU count
>   
4 dual core
> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)
>   
ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]  (direct from 
emerge ruby)

> * Rubygems (yes/no, version)
>   
y, 0.9.4
> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.
>
>   
We had some weird issues with mongrel >=1.1, which we never understood, 
but after downgrading
to 1.0.4 things are going well again. Kirk Haines looked into it, but I 
have to admit
I never understood what the reason of the problem with newer mongrel is.

Thanks to all mongrel hackers for the amazing work!

Ciao,
  -Armin

 

From baldmountain at gmail.com  Fri Jan  4 09:00:31 2008
From: baldmountain at gmail.com (Geoffrey Clements)
Date: Fri, 4 Jan 2008 09:00:31 -0500
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <EDCE0344-32F0-4D86-A6A1-588AEFA42A93@ncsu.edu>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
	<477CDD44.80809@hotgazpacho.com>
	<EDCE0344-32F0-4D86-A6A1-588AEFA42A93@ncsu.edu>
Message-ID: <472ed2750801040600k664c0f23p3a2984848cf28cf7@mail.gmail.com>

I'm a little surprised. We always build things like ruby so we have a bit
more control over what is turned on or off. Most distributions ship with a
version of ruby (or python, or any other scripting language) that is
configured for their convenience rather than ours. We build ruby on our
development machines even though Macs ship with a reasonable ruby installed.

On Jan 3, 2008 5:20 PM, Jason Young <jason.young at ncsu.edu> wrote:

>
> On Jan 3, 2008, at 8:04 AM, Will Green wrote:
>
> > CentOS 5 still ships with 1.8.5...
>
>
-- 
geoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080104/b6a2d6dd/attachment.html 

From evan at cloudbur.st  Fri Jan  4 09:45:53 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Fri, 4 Jan 2008 09:45:53 -0500
Subject: [Mongrel] deployment survey
In-Reply-To: <477DE652.70500@personifi.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
	<477DE652.70500@personifi.com>
Message-ID: <b6f68fc60801040645u91b5c7dub5d4b682ea0fbb19@mail.gmail.com>

> We had some weird issues with mongrel >=1.1, which we never understood, but after downgrading
> to 1.0.4 things are going well again. Kirk Haines looked into it, but I have to admit
> I never understood what the reason of the problem with newer mongrel is.

He mentioned someone was having lockups. If you could gdb the process
that locked and generate a backtrace that would be a big help.

Evan

On Jan 4, 2008 2:54 AM, Armin Roehrl <armin at personifi.com> wrote:
>
> > * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)
> >
> rack
> > * Mongrel version
> >
> 1.0.4
> > * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)
> >
> rack
> > * How many mongrel routes and handlers per route registered (if you
> > don't know, it's probably <= 2)
> >
> <=2
> > * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> > mongrel_cow_cluster, mongrel_experimental...)
> >
> none
> > * Mongrel runners used (mongrel_rails, mongrel::cluster,
> > mongrel_service, RV, others... please be *very specific* about which
> > options of the runner you use. For example, some people use
> > mongrel::cluster but only for the --clean functionality, not for the
> > clustering).
> >
> ? none I think.
> > * Number of mongrels per server per app
> >
> depends on the application 1-100
> > * Monitoring system (runit, monit, god...)
> >
> simple self-written scripts
> > * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> > nginx, pen...)
> >
> nginx
> > * HW loadbalancer, if any (Netscaler...)
> >
> none
> > * Caching strategy (memcached fragments, memcached object, squid,
> > rails page cache, rails page fragments, ESI)
> >
> memcached & self-grown hacks.
> > * Whether you serve media assets via mongrel itself, as opposed to
> > through a webserver
> >
> no
> > * Operating system including distribution or version (OS X 10.4.10,
> > Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)
> >
> gentoo linux
> > * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> > Arm (ha), JRuby)
> >
> Linux prod8 2.6.22-gentoo-r8-a #1 SMP Wed Oct 3 06:41:23 CDT 2007 x86_64
> Dual-Core AMD Opteron(tm) Processor 8212 AuthenticAMD GNU/Linux
>
> > * CPU count
> >
> 4 dual core
> > * Ruby version including custom distribution patches,
> > (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> > note where you got it, in case it isn't clear, for example, OS X 10.5
> > built-in, Ubuntu apt, Instant Rails, direct compile from source)
> >
> ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]  (direct from
> emerge ruby)
>
> > * Rubygems (yes/no, version)
> >
> y, 0.9.4
> > Please mention anything else about your system that's kind of weird,
> > and anything that's been particularly troublesome regarding mongrel
> > deployment.
> >
> >
> We had some weird issues with mongrel >=1.1, which we never understood,
> but after downgrading
> to 1.0.4 things are going well again. Kirk Haines looked into it, but I
> have to admit
> I never understood what the reason of the problem with newer mongrel is.
>
> Thanks to all mongrel hackers for the amazing work!
>
> Ciao,
>   -Armin
>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From evan at cloudbur.st  Fri Jan  4 10:06:35 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Fri, 4 Jan 2008 10:06:35 -0500
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801040645u91b5c7dub5d4b682ea0fbb19@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
	<477DE652.70500@personifi.com>
	<b6f68fc60801040645u91b5c7dub5d4b682ea0fbb19@mail.gmail.com>
Message-ID: <b6f68fc60801040706scbadfb7nc10081e2f431374d@mail.gmail.com>

Might as well include myself in the survey:

* Framework:
Camping, Rails

* Mongrel version:
0.3.13.4, 1.0.5, 1.1.3

* Mongrel handlers used:
rails, dirhandler, camping, homebrew

* How many mongrel routes and handlers per route registered
<= 2

* Any Mongrel plugins used
none

* Mongrel runners used
mongrel::cluster with --clean
RV

* Number of mongrels per server per app
1 to 8

* Monitoring system
nothing (camping), monit (rails)

* Proxy or software loadbalance
apache 2.2 mod_proxy_balancer
apache 2.0 mod_proxy -> pen

* HW loadbalancer
Netscaler

* Caching strategy
memcached fragments
camping FS page cache

* Whether you serve media assets via mongrel itself
no

* Operating system including distribution or version
ubuntu 6.0.6
RHEL 5

* Architecture
Linux 2.6.9-22.0.2.ELsmp #1 SMP Thu Jan 5 17:11:56 EST 2006 x86_64
x86_64 x86_64 GNU/Linux
Linux 2.6.16.29-xen #1 SMP Sun Sep 30 04:00:13 UTC 2007 x86_64 GNU/Linux

* CPU count
2 cores per server I think... not a lot

* Ruby version including custom distribution patches,
ruby 1.8.4 (2005-12-24) [x86_64-linux] (from Ubuntu)
ruby 1.8.6 (2007-03-13 patchlevel 0) [x86_64-linux] (from source with
Bleakhouse patches)

* Rubygems (yes/no, version)
0.9.4, 0.9.2


-- 
Evan Weaver
Cloudburst, LLC

From seanmichaelbrown at gmail.com  Fri Jan  4 12:20:21 2008
From: seanmichaelbrown at gmail.com (Sean Brown)
Date: Fri, 4 Jan 2008 12:20:21 -0500
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <1086fb5f0801040920t4e1d8627lfbd1f971d2e7834@mail.gmail.com>

On 1/3/08, Evan Weaver <evan at cloudbur.st> wrote:

>
> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)

Rails, just begun to look at Merb

> * Mongrel version

1.0.1, 1.1.3

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

Rails

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

n/a

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

none

> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

mongrel_rails, mongrel::cluster (for clustering)

> * Number of mongrels per server per app

Typically three to five per app

> * Monitoring system (runit, monit, god...)

monit

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

apache mod_proxy_balancer

> * HW loadbalancer, if any (Netscaler...)

none

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

rails page and action/fragment caching

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

Media/static assets served by apache

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

Red Hat Enterprise Linux ES release 4 (Nahant Update 6)

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

Linux 118790-www 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:17:21 EST
2007 i686 athlon i386 GNU/Linux

> * CPU count

2

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)
> * Rubygems (yes/no, version)

ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-linux] (compiled from source)
Rubygems - yes, 0.9.2 and 1.0.1


>
> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.

No trouble at all.


>
> $ gem install tattle --ignore-dependencies
> $ tattle report

user_key,
prefix, /usr/local
ruby_version, 1.8.6
host_vendor, pc
ruby_install_name, ruby
build, i686-pc-linux-gnu
target_cpu, i686
arch, i686-linux
rubygems_version, 1.0.1
SHELL, /bin/sh
host_os, linux-gnu
report_time, Fri Jan 04 11:17:52 -0600 2008
host_cpu, i686
LIBRUBY, libruby-static.a
LIBRUBY_SO, libruby.so.1.8.6
target, i686-pc-linux-gnu

and

user_key,
prefix, /usr/local
ruby_version, 1.8.6
host_vendor, pc
ruby_install_name, ruby
build, i686-pc-linux-gnu
target_cpu, i686
arch, i686-linux
rubygems_version, 0.9.2
SHELL, /bin/sh
host_os, linux-gnu
report_time, Fri Jan 04 11:19:52 -0600 2008
host_cpu, i686
LIBRUBY, libruby-static.a
LIBRUBY_SO, libruby.so.1.8.6
target, i686-pc-linux-gnu

-- 

Sean Brown
seanmichaelbrown at gmail.com

From jordan at bracco.name  Fri Jan  4 12:40:30 2008
From: jordan at bracco.name (Jordan Bracco)
Date: Fri, 4 Jan 2008 18:40:30 +0100
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <3fea7c7f0801040940k44c6c16ax2c315baec269e4e7@mail.gmail.com>

Hello !

On Jan 3, 2008 6:45 PM, Evan Weaver <evan at cloudbur.st> wrote:
> Hello Mongrels,
>
> Building on the last messages about Fastthread, can we get a detailed
> survey of the different ways people are deploying their applications?
> It will help with near-future Mongrel development.
>
> Please include the following things:
>
> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)

Rails, Camping

> * Mongrel version

1.1.3

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

Rails, Camping

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

don't know:)

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

mongrel_upload_progress

> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

mongrel::cluster

> * Number of mongrels per server per app

1 to 50

> * Monitoring system (runit, monit, god...)

God or Monit

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

Lighttpd

> * HW loadbalancer, if any (Netscaler...)

none

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

rails page cache & ESI

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

No, I serve the static files/assets via lighttpd

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

OS X for dev, FreeBSD for prod

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

x86

> * CPU count

core2duo, 2.66Ghz

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)

ruby 1.8.6; patchlevel 0, built from freebsd with oniguruma

> * Rubygems (yes/no, version)

yes, 1.0.1

>
> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.
>
> Evan
>
> PS. You can get some of the Ruby information via the 'tattle' gem:
>
> $ gem install tattle --ignore-dependencies
> $ tattle report
>

user_key,
prefix, /usr/local
ruby_version, 1.8.6
host_vendor, portbld
ruby_install_name, ruby18
build, i386-portbld-freebsd6
target_cpu, i386
arch, i386-freebsd6
rubygems_version, 1.0.1
SHELL, /bin/sh
host_os, freebsd6
report_time, Fri Jan 04 18:39:15 +0100 2008
host_cpu, i386
LIBRUBY, libruby18.so.18
LIBRUBY_SO, libruby18.so.18
target, i386-portbld-freebsd6


>
> --
>

From stephen.engelman at gmail.com  Fri Jan  4 13:05:07 2008
From: stephen.engelman at gmail.com (Stephen Engelman)
Date: Fri, 4 Jan 2008 10:05:07 -0800
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <989ac4af0801041005q16a19e4ah8d4efd0ab9ed2d7a@mail.gmail.com>

* Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)
Rails 1.2.6/2.0.2
* Mongrel version
1.1.2
* Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)
rails
* How many mongrel routes and handlers per route registered (if you
don't know, it's probably <= 2)
<=2
* Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
mongrel_cow_cluster, mongrel_experimental...)
mongrel_cluster
* Mongrel runners used (mongrel_rails, mongrel::cluster,
mongrel_service, RV, others... please be *very specific* about which
options of the runner you use. For example, some people use
mongrel::cluster but only for the --clean functionality, not for the
clustering).
Using Capistrano spin script that uses process spawner:
script/process/spawner -p 8000 -a 127.0.0.1 -i 4
* Number of mongrels per server per app
4
* Monitoring system (runit, monit, god...)
none at the moment, most likely will implement monit soon
* Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
nginx, pen...)
apache mod_proxy_balancer
* HW loadbalancer, if any (Netscaler...)
None
* Caching strategy (memcached fragments, memcached object, squid,
rails page cache, rails page fragments, ESI)
None
* Whether you serve media assets via mongrel itself, as opposed to
through a webserver
Webserver Apache
* Operating system including distribution or version (OS X 10.4.10,
Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)
Ubuntu/Linux 7.10 Server
* Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
Arm (ha), JRuby)
Linux 2.6.22-14-server #1 SMP Sun Oct 14 23:34:23 GMT 2007 i686 GNU/Linux
* CPU count
1
* Ruby version including custom distribution patches,
(1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
note where you got it, in case it isn't clear, for example, OS X 10.5
built-in, Ubuntu apt, Instant Rails, direct compile from source)
ruby 1.8.6 (2007-06-07 patchlevel 36) [i486-linux]
* Rubygems (yes/no, version)
0.9.4
On Jan 3, 2008 9:45 AM, Evan Weaver <evan at cloudbur.st> wrote:

> Hello Mongrels,
>
> Building on the last messages about Fastthread, can we get a detailed
> survey of the different ways people are deploying their applications?
> It will help with near-future Mongrel development.
>
> Please include the following things:
>
> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)
> * Mongrel version
> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)
> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)
> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)
> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).
> * Number of mongrels per server per app
> * Monitoring system (runit, monit, god...)
> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)
> * HW loadbalancer, if any (Netscaler...)
> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)
> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver
> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)
> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)
> * CPU count
> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)
> * Rubygems (yes/no, version)
>
> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.
>
> Evan
>
> PS. You can get some of the Ruby information via the 'tattle' gem:
>
> $ gem install tattle --ignore-dependencies
> $ tattle report
>
>
> --
> Evan Weaver
> Cloudburst, LLC
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080104/75cb1524/attachment.html 

From kevwil at gmail.com  Fri Jan  4 14:25:10 2008
From: kevwil at gmail.com (Kevin Williams)
Date: Fri, 4 Jan 2008 12:25:10 -0700
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <683a886f0801041125n6a766a5bjc9566e729640ad96@mail.gmail.com>

> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...)

Merb,Rails

> * Mongrel version

1.1.3

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

rails

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

don't know

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

1 plugin I made myself, a secure download handler

> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

mongrel_rails from Swiftiply with EVENT=1

> * Number of mongrels per server per app

1 (very low load)

> * Monitoring system (runit, monit, god...)

monit

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

used to use nginx but didn't need it for only 1 mongrel process

> * HW loadbalancer, if any (Netscaler...)

none

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

memcached fragments + memcached object

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

front-end webserver handles static files

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

Fedora 8 on server, OS X 10.5.1 in dev

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

x86_64

> * CPU count

2

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)

server - 1.8.6p111, dev - 1.8.6 OS X 10.5 version

> * Rubygems (yes/no, version)

yes, 1.0.1

>
> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.

I had a hard time getting monit to set EVENT=1, eventually using a
wrapper shell script.

>
> Evan
>
> PS. You can get some of the Ruby information via the 'tattle' gem:
>
> $ gem install tattle --ignore-dependencies
> $ tattle report
>
>
> --
> Evan Weaver
> Cloudburst, LLC
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From will at hotgazpacho.com  Fri Jan  4 22:57:29 2008
From: will at hotgazpacho.com (Will Green)
Date: Fri, 04 Jan 2008 22:57:29 -0500
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <472ed2750801040600k664c0f23p3a2984848cf28cf7@mail.gmail.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>	<477CDD44.80809@hotgazpacho.com>	<EDCE0344-32F0-4D86-A6A1-588AEFA42A93@ncsu.edu>
	<472ed2750801040600k664c0f23p3a2984848cf28cf7@mail.gmail.com>
Message-ID: <477F0029.4010801@hotgazpacho.com>

Why are you surprised? The version that ships with CentOS 5 is, IMHO, 
quite reasonable - ruby 1.8.5 (2006-08-25) [i386-linux]

Best of all, its supported by a commercial entity (CentOS packages lag 
behind RedHat Enterprise by about 2 days, I believe). Meaning that I, a 
lone developer/sysadmin , can spend my time building apps for my 
customers instead of recompiling Ruby.

It's a case of "good enough". I suspect you'll also find this sentiment 
resonates with other small groups of developers.

==
Will Green

Geoffrey Clements wrote:
> I'm a little surprised. We always build things like ruby so we have a 
> bit more control over what is turned on or off. Most distributions 
> ship with a version of ruby (or python, or any other scripting 
> language) that is configured for their convenience rather than ours. 
> We build ruby on our development machines even though Macs ship with a 
> reasonable ruby installed.
>
> On Jan 3, 2008 5:20 PM, Jason Young <jason.young at ncsu.edu 
> <mailto:jason.young at ncsu.edu>> wrote:
>
>
>     On Jan 3, 2008, at 8:04 AM, Will Green wrote:
>
>     > CentOS 5 still ships with 1.8.5...
>
>
> -- 
> geoff
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From baldmountain at gmail.com  Sat Jan  5 08:30:46 2008
From: baldmountain at gmail.com (Geoffrey Clements)
Date: Sat, 5 Jan 2008 08:30:46 -0500
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <477F0029.4010801@hotgazpacho.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
	<477CDD44.80809@hotgazpacho.com>
	<EDCE0344-32F0-4D86-A6A1-588AEFA42A93@ncsu.edu>
	<472ed2750801040600k664c0f23p3a2984848cf28cf7@mail.gmail.com>
	<477F0029.4010801@hotgazpacho.com>
Message-ID: <472ed2750801050530mf24108qcda3956a7f5283fb@mail.gmail.com>

It may be good enough but it's built for i386 and you get the features
redhat chose to install with it. The one on my local machine is: ruby
1.8.6(2007-09-23 patchlevel 110) [
i686-darwin9.1.0]. If nothing else it is compiled for i686 rather than i386
which means the compiler can use 686 instructions to build my version of
ruby rather than be limited to 386 instructions in yours.
If you build your own you can control what features are installed and the
gems library will not mix with what ever gems redhat chose to install. (I
don't remember if they actually install gems or not so I may be off base
here.)

In any case, it's not that important, Just my feeling...

On Jan 4, 2008 10:57 PM, Will Green <will at hotgazpacho.com> wrote:

> Why are you surprised? The version that ships with CentOS 5 is, IMHO,
> quite reasonable - ruby 1.8.5 (2006-08-25) [i386-linux]
>
> Best of all, its supported by a commercial entity (CentOS packages lag
> behind RedHat Enterprise by about 2 days, I believe). Meaning that I, a
> lone developer/sysadmin , can spend my time building apps for my
> customers instead of recompiling Ruby.
>
> It's a case of "good enough". I suspect you'll also find this sentiment
> resonates with other small groups of developers.
>
> ==
> Will Green
>
> Geoffrey Clements wrote:
> > I'm a little surprised. We always build things like ruby so we have a
> > bit more control over what is turned on or off. Most distributions
> > ship with a version of ruby (or python, or any other scripting
> > language) that is configured for their convenience rather than ours.
> > We build ruby on our development machines even though Macs ship with a
> > reasonable ruby installed.
> >
> > On Jan 3, 2008 5:20 PM, Jason Young <jason.young at ncsu.edu
> > <mailto:jason.young at ncsu.edu>> wrote:
> >
> >
> >     On Jan 3, 2008, at 8:04 AM, Will Green wrote:
> >
> >     > CentOS 5 still ships with 1.8.5...
> >
> >
> > --
> > geoff
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
geoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080105/3024e24e/attachment.html 

From luislavena at gmail.com  Sat Jan  5 13:56:07 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 5 Jan 2008 16:56:07 -0200
Subject: [Mongrel] fastthread no longer needed?
In-Reply-To: <472ed2750801050530mf24108qcda3956a7f5283fb@mail.gmail.com>
References: <81b453920801021105l786f9446i39bdd6769d6fb936@mail.gmail.com>
	<7fd922c3dab8b7f00f272fcb9c94b09e@localhost>
	<b6f68fc60801021255h4ced347ak956fbcea2d26ff34@mail.gmail.com>
	<477CDD44.80809@hotgazpacho.com>
	<EDCE0344-32F0-4D86-A6A1-588AEFA42A93@ncsu.edu>
	<472ed2750801040600k664c0f23p3a2984848cf28cf7@mail.gmail.com>
	<477F0029.4010801@hotgazpacho.com>
	<472ed2750801050530mf24108qcda3956a7f5283fb@mail.gmail.com>
Message-ID: <71166b3b0801051056r1d590b5i3f0621ce8b133714@mail.gmail.com>

On Jan 5, 2008 11:30 AM, Geoffrey Clements <baldmountain at gmail.com> wrote:
> It may be good enough but it's built for i386 and you get the features
> redhat chose to install with it. The one on my local machine is: ruby 1.8.6
> (2007-09-23 patchlevel 110) [i686-darwin9.1.0]. If nothing else it is
> compiled for i686 rather than i386 which means the compiler can use 686
> instructions to build my version of ruby rather than be limited to 386
> instructions in yours.
>

I'll also like to point that some of these distros build ruby with
--enable-pthreads, just for the sake of compatibility with Tk.

If oyu don't plan to use Tk (mostly you wouldn't), you can have a bit
performance boost.

Ezra pointed me that fact a few months back when talking about ruby
builds inside EY.

> If you build your own you can control what features are installed and the
> gems library will not mix with what ever gems redhat chose to install. (I
> don't remember if they actually install gems or not so I may be off base
> here.)

Yes, the mix is a bit problematic and something like rubygems update
raised a lot of issues.
Users using their distro packaged rubygem tried to use 'gem update
--system' and thus, ended with a broken rubygems.

If you build your own ruby, you don't have to worry about that :-)

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From jeremy at ibexinternet.co.uk  Tue Jan  8 12:20:09 2008
From: jeremy at ibexinternet.co.uk (Jeremy Wilkins)
Date: Tue, 8 Jan 2008 17:20:09 +0000
Subject: [Mongrel] XSendFile in development environment
Message-ID: <6A144E9E-020E-4180-B929-DA10F220F119@ibexinternet.co.uk>

Hi

I'm currently trying to use X-Sendfile to take some load off my rails  
app, unfortunately in my development environment mongrel is happily  
passing through the x-sendfile header, presumably for the (non- 
existant) proxy to handle the header.

Is there some way to make mongrel process the x-sendfile header itself?

Thanks

jebw

From lists at ruby-forum.com  Tue Jan  8 19:58:58 2008
From: lists at ruby-forum.com (Greg Willits)
Date: Wed, 9 Jan 2008 01:58:58 +0100
Subject: [Mongrel] mongrel, monit, and the many, many messages
Message-ID: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>

Monit 4.9, Mongrel 1.0.1, Rails 1.2.6, Mac OS X 10.4.11 (PPC)

I don't know whether this is a mongrel issue or a monit issue.

I'm trying to poke my way around a system set up by someone else. I have
no more experience w/ mongrel that local Rails dev at this point, and a
conceptual understanding of how monit is working. I have the Deploying
Rails beta book, and I'm muddling my way thru mongrel and monit docs,
but I think some hints as to direction would be useful.

I am suspicious that all cannot be well on this setup as monit will send
dozens of messages a day, and occasionally hundreds of messages. The
worst day was 1400 alerts. Yes, 1400.

The bulk comes from there being 3 clusters (staging, beta, production),
and 10 mongrels per cluster, and two servers. So, we can reduce the
total quantity by these factors, I get that part, but still, there's an
aweful lot of "this stopped" and "that does not exist" even factoring
the redundancy out.

I don't understand the implications of what each of these means. Mongrel
keep crashing? Rails crashing? Monit crashing?

Thanks for any clues you can offer.

Sample messages I get are:

-- (A)----------------------------------
Monit instance changed Service [domain snipped]

  Date:        Tue, 08 Jan 2008 14:41:50 -0800
  Action:      alert
  Host:         [domain snipped]
  Description: Monit stopped

-- (B)----------------------------------
Does not exist Service mongrel-production-8300

  Date:        Tue, 08 Jan 2008 15:30:04 -0800
  Action:      restart
  Host:         [domain snipped]
  Description: 'mongrel-production-8300' process is not running

-- (C)----------------------------------
Execution failed Service mongrel-production-8301

  Date:        Tue, 08 Jan 2008 15:30:34 -0800
  Action:      alert
  Host:         [domain snipped]
  Description: 'mongrel-production-8301' failed to start
-- 
Posted via http://www.ruby-forum.com/.

From dave at cheney.net  Tue Jan  8 20:02:19 2008
From: dave at cheney.net (Dave Cheney)
Date: Wed, 9 Jan 2008 12:02:19 +1100
Subject: [Mongrel] mongrel, monit, and the many, many messages
In-Reply-To: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
References: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
Message-ID: <83FAC2F4-1C06-4192-889D-57B051C937FC@cheney.net>

Sounds like you have a number of issues. Starting with mongrel, what  
do the mongrel logs for the pids that have stopped running say ? Also  
check /var/log/system.log for monit messages.

It may be worth upgrading to monit 4.10.1, which includes a number of  
fixes for running monit under OSX.

Cheers

Dave

On 09/01/2008, at 11:58 AM, Greg Willits wrote:

> I don't understand the implications of what each of these means.  
> Mongrel
> keep crashing? Rails crashing? Monit crashing?


From erik.hetzner at ucop.edu  Tue Jan  8 20:18:54 2008
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Tue, 08 Jan 2008 17:18:54 -0800
Subject: [Mongrel] mongrel, monit, and the many, many messages
In-Reply-To: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
References: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
Message-ID: <87hchnokxt.wl%erik.hetzner@ucop.edu>

At Wed, 9 Jan 2008 01:58:58 +0100,
Greg Willits <lists at ruby-forum.com> wrote:
> 
> Monit 4.9, Mongrel 1.0.1, Rails 1.2.6, Mac OS X 10.4.11 (PPC)
> 
> I don't know whether this is a mongrel issue or a monit issue.
> 
> I'm trying to poke my way around a system set up by someone else. I have
> no more experience w/ mongrel that local Rails dev at this point, and a
> conceptual understanding of how monit is working. I have the Deploying
> Rails beta book, and I'm muddling my way thru mongrel and monit docs,
> but I think some hints as to direction would be useful.
>
> [?]

I have seen a similar situation here. What happened was (more or less,
this is from memory) a mongrel instance would be locked up on an HTTP
response that would take a long time to complete. Because requests
would just queue up behind this one, monit would fail to get a
response in a reasonable time, would assume that the process was
non-responsive and try to restart it gracefully (using mongrel_rails
stop). Mongrel would take a long time to shut down because it was
still processing that long running response, so we would get a message
that monit couldn't shut it down and it would fail to start (or
something like that). Finally the long running rails process would
complete, mongrel would restart, and monit would let us know that the
process was back up.

The solution was to make sure that responses come back in a reasonable
amount of time.

best,
Erik Hetzner
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20080108/15656214/attachment.bin 

From evan at cloudbur.st  Tue Jan  8 22:28:58 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Tue, 8 Jan 2008 22:28:58 -0500
Subject: [Mongrel] mongrel, monit, and the many, many messages
In-Reply-To: <87hchnokxt.wl%erik.hetzner@ucop.edu>
References: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
	<87hchnokxt.wl%erik.hetzner@ucop.edu>
Message-ID: <b6f68fc60801081928v60ba594aj7a8ad628d7835887@mail.gmail.com>

Make sure your Monit check interval (not sure abou the default) is
greater than your Mongrel request timeout interval (default 60
seconds).

Evan

On Jan 8, 2008 8:18 PM, Erik Hetzner <erik.hetzner at ucop.edu> wrote:
> At Wed, 9 Jan 2008 01:58:58 +0100,
> Greg Willits <lists at ruby-forum.com> wrote:
> >
> > Monit 4.9, Mongrel 1.0.1, Rails 1.2.6, Mac OS X 10.4.11 (PPC)
> >
> > I don't know whether this is a mongrel issue or a monit issue.
> >
> > I'm trying to poke my way around a system set up by someone else. I have
> > no more experience w/ mongrel that local Rails dev at this point, and a
> > conceptual understanding of how monit is working. I have the Deploying
> > Rails beta book, and I'm muddling my way thru mongrel and monit docs,
> > but I think some hints as to direction would be useful.
> >
> > [?]
>
> I have seen a similar situation here. What happened was (more or less,
> this is from memory) a mongrel instance would be locked up on an HTTP
> response that would take a long time to complete. Because requests
> would just queue up behind this one, monit would fail to get a
> response in a reasonable time, would assume that the process was
> non-responsive and try to restart it gracefully (using mongrel_rails
> stop). Mongrel would take a long time to shut down because it was
> still processing that long running response, so we would get a message
> that monit couldn't shut it down and it would fail to start (or
> something like that). Finally the long running rails process would
> complete, mongrel would restart, and monit would let us know that the
> process was back up.
>
> The solution was to make sure that responses come back in a reasonable
> amount of time.
>
> best,
> Erik Hetzner
> ;; Erik Hetzner, California Digital Library
> ;; gnupg key id: 1024D/01DB07E3
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From lists at ruby-forum.com  Wed Jan  9 13:55:27 2008
From: lists at ruby-forum.com (Greg Willits)
Date: Wed, 9 Jan 2008 19:55:27 +0100
Subject: [Mongrel] mongrel, monit, and the many, many messages
In-Reply-To: <b6f68fc60801081928v60ba594aj7a8ad628d7835887@mail.gmail.com>
References: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
	<87hchnokxt.wl%erik.hetzner@ucop.edu>
	<b6f68fc60801081928v60ba594aj7a8ad628d7835887@mail.gmail.com>
Message-ID: <78cf17c24e0972fa76f663ef8bd6e5d6@ruby-forum.com>

Thanks for the ideas so far. I'll look into the latest monit. Message 
(A) is starting to look like a monit crash to me. It is always followed 
by a bunch of similar messages that monit maybe stopping/starting all 
the mongrels.

looks like the logs have little or no date/time stamps, so they're 
semi-useless in trying to correlate to the email alerts.

I do have some requests that can take a while to process (depends on 
response time from external services), so that's a valid lead.

Evan Weaver wrote:
> Make sure your Monit check interval (not sure abou the default) is
> greater than your Mongrel request timeout interval (default 60
> seconds).

I have looked everywhere I can think of, and I don't see any mention of 
this timeout value anywhere in Mongrel docs. This page 
(http://mongrel.rubyforge.org/docs/howto.html) mentions a -t (timeout), 
but the description doesn't match what you're referring to. It looks 
like a delay between the end of responding to request A and starting to 
handle request B, not when to give up on A.

I guess I'll assume the 60 secs, and play with monit accordingly.

-- gw


-- 
Posted via http://www.ruby-forum.com/.

From evan at cloudbur.st  Wed Jan  9 14:36:26 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Wed, 9 Jan 2008 14:36:26 -0500
Subject: [Mongrel] mongrel, monit, and the many, many messages
In-Reply-To: <78cf17c24e0972fa76f663ef8bd6e5d6@ruby-forum.com>
References: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
	<87hchnokxt.wl%erik.hetzner@ucop.edu>
	<b6f68fc60801081928v60ba594aj7a8ad628d7835887@mail.gmail.com>
	<78cf17c24e0972fa76f663ef8bd6e5d6@ruby-forum.com>
Message-ID: <b6f68fc60801091136r30f854d7gfc4d6c7c23637d76@mail.gmail.com>

That page is out of date. The RDoc is probably better. And there's
always the source...

Soon we'll do some work on the state of the documentation.

Evan


On Jan 9, 2008 1:55 PM, Greg Willits <lists at ruby-forum.com> wrote:
> Thanks for the ideas so far. I'll look into the latest monit. Message
> (A) is starting to look like a monit crash to me. It is always followed
> by a bunch of similar messages that monit maybe stopping/starting all
> the mongrels.
>
> looks like the logs have little or no date/time stamps, so they're
> semi-useless in trying to correlate to the email alerts.
>
> I do have some requests that can take a while to process (depends on
> response time from external services), so that's a valid lead.
>
> Evan Weaver wrote:
> > Make sure your Monit check interval (not sure abou the default) is
> > greater than your Mongrel request timeout interval (default 60
> > seconds).
>
> I have looked everywhere I can think of, and I don't see any mention of
> this timeout value anywhere in Mongrel docs. This page
> (http://mongrel.rubyforge.org/docs/howto.html) mentions a -t (timeout),
> but the description doesn't match what you're referring to. It looks
> like a delay between the end of responding to request A and starting to
> handle request B, not when to give up on A.
>
> I guess I'll assume the 60 secs, and play with monit accordingly.
>
> -- gw
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
>
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From erik.hetzner at ucop.edu  Wed Jan  9 15:12:20 2008
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Wed, 09 Jan 2008 12:12:20 -0800
Subject: [Mongrel] mongrel, monit, and the many, many messages
In-Reply-To: <78cf17c24e0972fa76f663ef8bd6e5d6@ruby-forum.com>
References: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
	<87hchnokxt.wl%erik.hetzner@ucop.edu>
	<b6f68fc60801081928v60ba594aj7a8ad628d7835887@mail.gmail.com>
	<78cf17c24e0972fa76f663ef8bd6e5d6@ruby-forum.com>
Message-ID: <87fxx6oj17.wl%erik.hetzner@ucop.edu>

At Wed, 9 Jan 2008 19:55:27 +0100,
Greg Willits <lists at ruby-forum.com> wrote:
> 
> Thanks for the ideas so far. I'll look into the latest monit. Message 
> (A) is starting to look like a monit crash to me. It is always followed 
> by a bunch of similar messages that monit maybe stopping/starting all 
> the mongrels.
>
> [?]

I doubt a monit crash. This is the message I get when I start monit
with the ?-I quit? option. It sounds like something (a cron job?) is
restarting monit, & monit is not noticing that the mongrels are
running when it restarts, so it tries to bring the mongrels up. Fool
around with the monitrc: perhaps monit is failing to notice the pid
files that exist for mongrel?

best,
Erik Hetzner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20080109/a60a434d/attachment.bin 

From lists at ruby-forum.com  Wed Jan  9 16:09:11 2008
From: lists at ruby-forum.com (Greg Willits)
Date: Wed, 9 Jan 2008 22:09:11 +0100
Subject: [Mongrel] mongrel, monit, and the many, many messages
In-Reply-To: <87fxx6oj17.wl%erik.hetzner@ucop.edu>
References: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
	<87hchnokxt.wl%erik.hetzner@ucop.edu>
	<b6f68fc60801081928v60ba594aj7a8ad628d7835887@mail.gmail.com>
	<78cf17c24e0972fa76f663ef8bd6e5d6@ruby-forum.com>
	<87fxx6oj17.wl%erik.hetzner@ucop.edu>
Message-ID: <316f12994bd4346b1474e249ac5dff77@ruby-forum.com>

Erik Hetzner wrote:
> At Wed, 9 Jan 2008 19:55:27 +0100,
> Greg Willits <lists at ruby-forum.com> wrote:
>> 
>> Thanks for the ideas so far. I'll look into the latest monit. Message 
>> (A) is starting to look like a monit crash to me. It is always followed 
>> by a bunch of similar messages that monit maybe stopping/starting all 
>> the mongrels.
>>
>> [?]
> 
> I doubt a monit crash. This is the message I get when I start monit
> with the ?-I quit? option. It sounds like something (a cron job?) is
> restarting monit....

Yeah we have launchd monitoring monit, so that could explain that.

When it was all set up it was explained to me that "mongrel/rails 
crashes/has leaks, so we use monit to keep an eye on that, but monit 
crashes/has leaks, so we'll use launchd to monitor monit"

Sounded like a house of cards to me, but wasn't in a position to argue 
it at the time. IIRC the monit thing may have been a leak specific to OS 
X at the time. So hopefully the recent versions are the solution to 
that. I should get a chance to look into that tonight.

Thanks.

-- gw


-- 
Posted via http://www.ruby-forum.com/.

From njvack at wisc.edu  Wed Jan  9 16:40:34 2008
From: njvack at wisc.edu (Nathan Vack)
Date: Wed, 9 Jan 2008 15:40:34 -0600
Subject: [Mongrel] mongrel, monit, and the many, many messages
In-Reply-To: <316f12994bd4346b1474e249ac5dff77@ruby-forum.com>
References: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
	<87hchnokxt.wl%erik.hetzner@ucop.edu>
	<b6f68fc60801081928v60ba594aj7a8ad628d7835887@mail.gmail.com>
	<78cf17c24e0972fa76f663ef8bd6e5d6@ruby-forum.com>
	<87fxx6oj17.wl%erik.hetzner@ucop.edu>
	<316f12994bd4346b1474e249ac5dff77@ruby-forum.com>
Message-ID: <005D6FE9-2908-4F08-8D2B-EFC3745C30C5@wisc.edu>

On Jan 9, 2008, at 3:09 PM, Greg Willits wrote:

> Yeah we have launchd monitoring monit, so that could explain that.

Y'know, you can just have launchd monitor mongrel. That probably  
makes more sense than launchd watching monit watching mongrel ;-)

-n

From lists at ruby-forum.com  Wed Jan  9 16:56:55 2008
From: lists at ruby-forum.com (Greg Willits)
Date: Wed, 9 Jan 2008 22:56:55 +0100
Subject: [Mongrel] mongrel, monit, and the many, many messages
In-Reply-To: <005D6FE9-2908-4F08-8D2B-EFC3745C30C5@wisc.edu>
References: <c462ec7ed72cc6fa49e080a9d1312185@ruby-forum.com>
	<87hchnokxt.wl%erik.hetzner@ucop.edu>
	<b6f68fc60801081928v60ba594aj7a8ad628d7835887@mail.gmail.com>
	<78cf17c24e0972fa76f663ef8bd6e5d6@ruby-forum.com>
	<87fxx6oj17.wl%erik.hetzner@ucop.edu>
	<316f12994bd4346b1474e249ac5dff77@ruby-forum.com>
	<005D6FE9-2908-4F08-8D2B-EFC3745C30C5@wisc.edu>
Message-ID: <c21e98faa7ae61d5a9df4a3345042645@ruby-forum.com>

Nathan Vack wrote:
> On Jan 9, 2008, at 3:09 PM, Greg Willits wrote:
> 
>> Yeah we have launchd monitoring monit, so that could explain that.
> 
> Y'know, you can just have launchd monitor mongrel. That probably
> makes more sense than launchd watching monit watching mongrel ;-)

Yep. Now that I've been poking around and getting more familiar with 
this setup and see that launchd can monitor those details, that seemed 
like a logical thing to me, so now I have a "second" :-) The orginal guy 
was just learning OS X at the time and was more familiar with monit as 
part of his overall Rails deployment package.

-- gw


-- 
Posted via http://www.ruby-forum.com/.

From pete at nextengine.com  Wed Jan  9 18:05:41 2008
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 9 Jan 2008 15:05:41 -0800
Subject: [Mongrel] deployment survey
In-Reply-To: <1086fb5f0801040920t4e1d8627lfbd1f971d2e7834@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
	<1086fb5f0801040920t4e1d8627lfbd1f971d2e7834@mail.gmail.com>
Message-ID: <00350772-6AC0-4B78-B8FA-1FEEDCBE550E@nextengine.com>

It's great to get a sense for what everybody's using.  Here's my setup:

> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA,  
> Rack...)

Rails.  Not using anything but ActiveRecord and very basic  
controllers, so planning to switch to Merb soon for improved speed +  
less memory overhead.

> * Mongrel version

1.0.1

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

Rails

> * How many mongrel routes and handlers per route registered (if you
> don't know, it's probably <= 2)

n/a

> * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip,
> mongrel_cow_cluster, mongrel_experimental...)

none

> * Mongrel runners used (mongrel_rails, mongrel::cluster,
> mongrel_service, RV, others... please be *very specific* about which
> options of the runner you use. For example, some people use
> mongrel::cluster but only for the --clean functionality, not for the
> clustering).

mongrel_rails, mongrel::cluster (for clustering)

> * Number of mongrels per server per app

12-16 per server

> * Monitoring system (runit, monit, god...)

monit

> * Proxy or software loadbalancer, if any (apache mod_proxy_balancer,
> nginx, pen...)

nginx 0.5.34 (recently switched from lighttpd, and very happy with  
nginx)

> * HW loadbalancer, if any (Netscaler...)

a separate linux box running pound

> * Caching strategy (memcached fragments, memcached object, squid,
> rails page cache, rails page fragments, ESI)

custom caching in central ruby process (mongrels talk to it via DRB)

> * Whether you serve media assets via mongrel itself, as opposed to
> through a webserver

Media/static assets served by nginx using X-Accel-Redirect

> * Operating system including distribution or version (OS X 10.4.10,
> Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

Ubuntu Feisty Fawn 7.04

> * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC,
> Arm (ha), JRuby)

Linux server4 2.6.20-15-generic #2 SMP Sun Apr 15 06:17:24 UTC 2007  
x86_64 GNU/Linux

> * CPU count

2 servers, each running 2 dual core Xeon's

> * Ruby version including custom distribution patches,
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also
> note where you got it, in case it isn't clear, for example, OS X 10.5
> built-in, Ubuntu apt, Instant Rails, direct compile from source)
> * Rubygems (yes/no, version)

ruby 1.8.5 (2006-08-25) [x86_64-linux]

> * Rubygems (yes/no, version)

yes, 0.9.0

> Please mention anything else about your system that's kind of weird,
> and anything that's been particularly troublesome regarding mongrel
> deployment.

Could never build mysql_gem successfully on these machines (received  
errors about 64-bits).  Other than that, everything has been running  
great.


-Pete

From donald.ball at nashville.gov  Wed Jan  9 17:37:24 2008
From: donald.ball at nashville.gov (Ball, Donald A Jr (Library))
Date: Wed, 9 Jan 2008 16:37:24 -0600
Subject: [Mongrel] deployment survey
In-Reply-To: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
References: <b6f68fc60801030945t22ebdefbxd36fcde4c4278410@mail.gmail.com>
Message-ID: <918A0DD3EFA7F248BFBF447187F8A9323A91BA@HOBVSISMS01.nashville.org>

> * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, 
> IOWA, Rack...)

Rails-1.2.x

> * Mongrel version

Mongrel-1.1

> * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...)

rails

> * How many mongrel routes and handlers per route registered 
> (if you don't know, it's probably <= 2)

Uh...

> * Any Mongrel plugins used (mongrel_upload_progress, 
> mongrel_gzip, mongrel_cow_cluster, mongrel_experimental...)

Nope

> * Mongrel runners used (mongrel_rails, mongrel::cluster, 
> mongrel_service, RV, others... please be *very specific* 
> about which options of the runner you use. For example, some 
> people use mongrel::cluster but only for the --clean 
> functionality, not for the clustering).

mongrel_service-0.3.1

> * Number of mongrels per server per app

3

> * Monitoring system (runit, monit, god...)

Uh...

> * Proxy or software loadbalancer, if any (apache 
> mod_proxy_balancer, nginx, pen...)

pen+cygwin for load balancing, isapi_rewrite for reverse proxying behind
IIS

> * HW loadbalancer, if any (Netscaler...)

Nope

> * Caching strategy (memcached fragments, memcached object, 
> squid, rails page cache, rails page fragments, ESI)

rails page cache

> * Whether you serve media assets via mongrel itself, as 
> opposed to through a webserver

Some both ways. Static images and stylesheets via the web server, but my
model objects can have attached images which are scaled and served from
the rails page cache by mongrel

> * Operating system including distribution or version (OS X 
> 10.4.10, Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...)

WinXP SP2 and Win2k3 Server

> * Architecture, via 'uname -a' preferably (x86, x86_64, 
> Sparc, PPC, Arm (ha), JRuby)

x86

> * CPU count

2

> * Ruby version including custom distribution patches, 
> (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... 

1.8.6

> also note where you got it, in case it isn't clear, for 
> example, OS X 10.5 built-in, Ubuntu apt, Instant Rails, 
> direct compile from source)

OneClick installer

> * Rubygems (yes/no, version)

yes, 0.9.2

> Please mention anything else about your system that's kind of 
> weird, and anything that's been particularly troublesome 
> regarding mongrel deployment.

Having to install pen on win32 to get load balancing is a PITA. It would
be super swell if mongrel_service or mongrel_cluster could offer that
capability, even if it's not the fastest option available.

I should, of course, be using apache on win32, but my hands are tied in
that regard, and I know I'm not the only one.

- donald

From cnk at caltech.edu  Wed Jan  9 19:00:48 2008
From: cnk at caltech.edu (Cynthia Kiser)
Date: Wed, 9 Jan 2008 16:00:48 -0800
Subject: [Mongrel] Integration of Mongrel with RHEL,
	Fedora and derivatives
In-Reply-To: <ced105d40712200008y2de95019m4b57b0f6eb1d9345@mail.gmail.com>
References: <ced105d40712200008y2de95019m4b57b0f6eb1d9345@mail.gmail.com>
Message-ID: <20080110000048.GV28849@clyde.caltech.edu>

Quoting Paolo Campegiani <paolo.campegiani at gmail.com>:
> here at Scuola IaD we have some Rails applications in production, I'm
> the sysadmin so I made a script for governing mongrel instances via
> the service command and integrating their management in a RHEL
> environment. This script, available with more information here:
> 
> http://bitsandchaos.wordpress.com/2007/12/14/mongrel-integration-for-rhel-fedora-and-derivatives-new-release/
> 

Paolo, I hung on to this email and finally got the time to download
and try your init script. Fabulous! thanks for making this available
to the community. 

From chrisangileri at yahoo.com  Thu Jan 10 15:11:48 2008
From: chrisangileri at yahoo.com (Eire Angel)
Date: Thu, 10 Jan 2008 12:11:48 -0800 (PST)
Subject: [Mongrel] evented mongrel question - maybe for Kirk
Message-ID: <25588.31854.qm@web53401.mail.re2.yahoo.com>

hi i am setting up evented mongrels on one of my servers and 
i am running into a little confusion.

i understand that there is a few diff ways to set this up.  one being
using the swiftiply gem,  setting the env variable to event=1
( this is one level of confusion on ubuntu ) ( how to do this )
then also setting the require in environment.rb in rails
 
and the other i believe is to overwrite the mongrel_rails file
with the one in the package ?  is this correct ?

please someone shed some light 




       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080110/491d8089/attachment-0001.html 

From eggie5 at gmail.com  Thu Jan 10 23:40:53 2008
From: eggie5 at gmail.com (Alex Egg)
Date: Thu, 10 Jan 2008 20:40:53 -0800
Subject: [Mongrel] XSendFile in development environment
In-Reply-To: <6A144E9E-020E-4180-B929-DA10F220F119@ibexinternet.co.uk>
References: <6A144E9E-020E-4180-B929-DA10F220F119@ibexinternet.co.uk>
Message-ID: <6f7401650801102040h7d8403b9h777c6facbc1ec6a1@mail.gmail.com>

I believe this functionality doesn't exist in mongrel.

On Jan 8, 2008 9:20 AM, Jeremy Wilkins <jeremy at ibexinternet.co.uk> wrote:
> Hi
>
> I'm currently trying to use X-Sendfile to take some load off my rails
> app, unfortunately in my development environment mongrel is happily
> passing through the x-sendfile header, presumably for the (non-
> existant) proxy to handle the header.
>
> Is there some way to make mongrel process the x-sendfile header itself?
>
> Thanks
>
> jebw
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From pete at nextengine.com  Fri Jan 11 00:40:21 2008
From: pete at nextengine.com (Pete DeLaurentis)
Date: Thu, 10 Jan 2008 21:40:21 -0800
Subject: [Mongrel] XSendFile in development environment
In-Reply-To: <6f7401650801102040h7d8403b9h777c6facbc1ec6a1@mail.gmail.com>
References: <6A144E9E-020E-4180-B929-DA10F220F119@ibexinternet.co.uk>
	<6f7401650801102040h7d8403b9h777c6facbc1ec6a1@mail.gmail.com>
Message-ID: <F2477EF0-DBC1-4F08-9721-B446011F9EDB@nextengine.com>

Hi Jebw,

Which webserver are you using to handle the X-Sendfile requests in  
production?

If you're using nginx in production, it's pretty easy to get this  
running on your development machine too (it has X-Accel-Redirect,  
which is just like X-Sendfile).  You can have it proxy through to your  
development mongrel server at port 3000.

-Pete


On Jan 10, 2008, at 8:40 PM, Alex Egg wrote:

> I believe this functionality doesn't exist in mongrel.
>
> On Jan 8, 2008 9:20 AM, Jeremy Wilkins <jeremy at ibexinternet.co.uk>  
> wrote:
>> Hi
>>
>> I'm currently trying to use X-Sendfile to take some load off my rails
>> app, unfortunately in my development environment mongrel is happily
>> passing through the x-sendfile header, presumably for the (non-
>> existant) proxy to handle the header.
>>
>> Is there some way to make mongrel process the x-sendfile header  
>> itself?
>>
>> Thanks
>>
>> jebw
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From lists at ruby-forum.com  Fri Jan 11 02:12:46 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Fri, 11 Jan 2008 08:12:46 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
Message-ID: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>

All,

Mongrel 1.1.3
Rails 2.0.2
Ruby 1.8.6
Windows XP SP2

When I issue the command "ruby script/server" from any of my Rails
projects on v. 2.0.2, I get a Windows dialog with the error:

"The application has failed to start because MSVCR80.dll was not found.
Re-installing the application may fix this problem."

I've gone through the process of attempting to introduce MSVCR80.dll
into my PATH but just generate more errors.

I suspect that at some point, the precompiled Mongrel gem started
getting compiled with a newer version of the MS C compiler than my
runtime supports.  I have the Windows Platform SDK for Windows Server
2003 R2 installed.

Does anyone know if the runtime support for Mongrel has changed in the
last few revs.?  Or is my theory completely wack?

Thanks,
Wes Gamble
-- 
Posted via http://www.ruby-forum.com/.

From will at hotgazpacho.com  Fri Jan 11 02:39:05 2008
From: will at hotgazpacho.com (Will Green)
Date: Fri, 11 Jan 2008 02:39:05 -0500
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
Message-ID: <47871D19.3050202@hotgazpacho.com>

Wes, are your using RMagick 2.0 or above? I ask because I noticed in the 
release notes recently that it was compiled with VC 8 (2005). Perhaps 
this is the problem?

Wes Gamble wrote:
> All,
>
> Mongrel 1.1.3
> Rails 2.0.2
> Ruby 1.8.6
> Windows XP SP2
>
> When I issue the command "ruby script/server" from any of my Rails
> projects on v. 2.0.2, I get a Windows dialog with the error:
>
> "The application has failed to start because MSVCR80.dll was not found.
> Re-installing the application may fix this problem."
>
> I've gone through the process of attempting to introduce MSVCR80.dll
> into my PATH but just generate more errors.
>
> I suspect that at some point, the precompiled Mongrel gem started
> getting compiled with a newer version of the MS C compiler than my
> runtime supports.  I have the Windows Platform SDK for Windows Server
> 2003 R2 installed.
>
> Does anyone know if the runtime support for Mongrel has changed in the
> last few revs.?  Or is my theory completely wack?
>
> Thanks,
> Wes Gamble
>   


From lists at ruby-forum.com  Fri Jan 11 03:00:45 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Fri, 11 Jan 2008 09:00:45 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <47871D19.3050202@hotgazpacho.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
Message-ID: <a593750384309835bafbe1ff791b44ef@ruby-forum.com>

Current resolution:

Rolled back to Mongrel 1.1 and I can run it.

The original error (w/Mongrel 1.1.3) was a Windows dialog that displayed 
""The application has failed to start because MSVCR80.dll was not found. 
Re-installing the application may fix this problem."  When I would click 
on that dialog's OK button, it would pop up again and I would never be 
able to get past the error.

This behavior appears for Mongrel versions >= 1.1.1.

At 1.1, I get the error dialog once, click the OK button and Mongrel 
proceeds to start up.

Wes

-- 
Posted via http://www.ruby-forum.com/.

From luislavena at gmail.com  Fri Jan 11 04:56:31 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 11 Jan 2008 07:56:31 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <a593750384309835bafbe1ff791b44ef@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
Message-ID: <71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>

On Jan 11, 2008 6:00 AM, Wes Gamble <lists at ruby-forum.com> wrote:
> Current resolution:
>
> Rolled back to Mongrel 1.1 and I can run it.
>

But again, you're using RMagick 2.0?

It seems you're missing the VC8 C runtimes, and later versions of
Mongrel fire the requirement.

Try this on irb:
require 'rubygems'
require 'mongrel'

And you will see there is no problem with that.

Anyway, script/server is something weird, if you try "mongrel_rails
start" you will see there is no problem.

Again, you have some extension that is linked with MSVCR80.dll, and
since is RMagick, that could bring a series of problems in relation to
malloc and free.

Don't blame us we didnt' warn you :-)

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From lists at ruby-forum.com  Fri Jan 11 11:40:04 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Fri, 11 Jan 2008 17:40:04 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
Message-ID: <e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>

Luis,

I do not have RMagick installed at all.

I see the same exact behavior that I described above if I start mongrel 
using "mongrel_rails start".

I also see that same behavior if I go into irb and issue the "require 
rubygems" and "require mongrel" commands.

Thanks,
Wes

-- 
Posted via http://www.ruby-forum.com/.

From runner at berkeley.edu  Fri Jan 11 11:48:49 2008
From: runner at berkeley.edu (Steven Hansen)
Date: Fri, 11 Jan 2008 08:48:49 -0800
Subject: [Mongrel] XSendFile in development environment
In-Reply-To: <6f7401650801102040h7d8403b9h777c6facbc1ec6a1@mail.gmail.com>
References: <6A144E9E-020E-4180-B929-DA10F220F119@ibexinternet.co.uk>
	<6f7401650801102040h7d8403b9h777c6facbc1ec6a1@mail.gmail.com>
Message-ID: <47879DF1.3080706@berkeley.edu>



For what it's worth, I have a method that handles the logic for sending 
the file.  If the rails environment == 'production' it just sets the 
headers to trigger apache x_send_file.  Otherwise I just use the default 
sendfile that comes with rails...

-Steven


Alex Egg wrote:
> I believe this functionality doesn't exist in mongrel.
>
> On Jan 8, 2008 9:20 AM, Jeremy Wilkins <jeremy at ibexinternet.co.uk> wrote:
>   
>> Hi
>>
>> I'm currently trying to use X-Sendfile to take some load off my rails
>> app, unfortunately in my development environment mongrel is happily
>> passing through the x-sendfile header, presumably for the (non-
>> existant) proxy to handle the header.
>>
>> Is there some way to make mongrel process the x-sendfile header itself?
>>
>> Thanks
>>
>> jebw
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>>     
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   


From kevwil at gmail.com  Fri Jan 11 13:51:15 2008
From: kevwil at gmail.com (Kevin Williams)
Date: Fri, 11 Jan 2008 11:51:15 -0700
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
Message-ID: <683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>

Could this be a rubygems issue? I constantly get gems installing the
ruby version instead of the win32 version just because it can. If you
uninstall and re-install, does it say it is compiling? If so, you
would need to have VC6 set as your default compiler in Windows.

On Jan 11, 2008 9:40 AM, Wes Gamble <lists at ruby-forum.com> wrote:
> Luis,
>
> I do not have RMagick installed at all.
>
> I see the same exact behavior that I described above if I start mongrel
> using "mongrel_rails start".
>
> I also see that same behavior if I go into irb and issue the "require
> rubygems" and "require mongrel" commands.
>
> Thanks,
> Wes
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
>
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Cheers,

Kevin Williams
http://www.bantamtech.com/

From luislavena at gmail.com  Fri Jan 11 14:25:35 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 11 Jan 2008 17:25:35 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
Message-ID: <71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>

On Jan 11, 2008 4:51 PM, Kevin Williams <kevwil at gmail.com> wrote:
> Could this be a rubygems issue? I constantly get gems installing the
> ruby version instead of the win32 version just because it can. If you
> uninstall and re-install, does it say it is compiling? If so, you
> would need to have VC6 set as your default compiler in Windows.
>

Will be more helpful if you provide us with the versions of ruby.

Anyway, if you're getting that MSVCR80.dll is missing, that means that
something is getting loaded and it is reaquiring that missing library.

That could be because you installed a gem that was build with VC8
(which is not the same as the One-Click Installer, in case you used
it).

Please, provide more background information.

Can you provide your RUBY_PLATFORM and Ruby version?
ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]

ruby -e "puts RUBY_PLATFORM"
i386-mswin32

I can bet that you have i386-mswin32_80 as platform, since rubygems is
switching to pure ruby gems instead of pre compiled ones.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From bettheriver at gmail.com  Fri Jan 11 14:28:24 2008
From: bettheriver at gmail.com (Stephen C)
Date: Fri, 11 Jan 2008 13:28:24 -0600
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
Message-ID: <e47b92bd0801111128k55fc3ca3h2a1eb395f70a3759@mail.gmail.com>

Hello. I'm new to this list as of this week.
I am supporting a Win2k3Server installation of RoR. I'm not very familiar
with what you guys are discussing but I did have a very similar error
occuring earlier in the week. I had just installed Ruby for IIS version 0.1(
http://rubyforiis.sosukodo.org/rubyforiis/). For some reason it stepped on
this dll during the install. After realizing it would be very stupid to try
to support RoR on IIS, I uninstalled this software and the error magically
disappeared. I have no further explanation for what happened.
Hope this helps.

On Jan 11, 2008 12:51 PM, Kevin Williams <kevwil at gmail.com> wrote:

> Could this be a rubygems issue? I constantly get gems installing the
> ruby version instead of the win32 version just because it can. If you
> uninstall and re-install, does it say it is compiling? If so, you
> would need to have VC6 set as your default compiler in Windows.
>
> On Jan 11, 2008 9:40 AM, Wes Gamble <lists at ruby-forum.com> wrote:
> > Luis,
> >
> > I do not have RMagick installed at all.
> >
> > I see the same exact behavior that I described above if I start mongrel
> > using "mongrel_rails start".
> >
> > I also see that same behavior if I go into irb and issue the "require
> > rubygems" and "require mongrel" commands.
> >
> > Thanks,
> > Wes
> >
> > --
> > Posted via http://www.ruby-forum.com/.
> > _______________________________________________
> >
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
>
>
> --
> Cheers,
>
> Kevin Williams
> http://www.bantamtech.com/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080111/99cb71bc/attachment-0001.html 

From luislavena at gmail.com  Fri Jan 11 14:36:51 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 11 Jan 2008 17:36:51 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <e47b92bd0801111128k55fc3ca3h2a1eb395f70a3759@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<e47b92bd0801111128k55fc3ca3h2a1eb395f70a3759@mail.gmail.com>
Message-ID: <71166b3b0801111136t172fa8a3h2a7d3040d611ac36@mail.gmail.com>

On Jan 11, 2008 5:28 PM, Stephen C <bettheriver at gmail.com> wrote:
> Hello. I'm new to this list as of this week.
> I am supporting a Win2k3Server installation of RoR. I'm not very familiar
> with what you guys are discussing but I did have a very similar error
> occuring earlier in the week. I had just installed Ruby for IIS version 0.1
> (http://rubyforiis.sosukodo.org/rubyforiis/). For some reason it stepped on
> this dll during the install. After realizing it would be very stupid to try
> to support RoR on IIS, I uninstalled this software and the error magically
> disappeared. I have no further explanation for what happened.
> Hope this helps.
>

RubyForIIS have two problems:

Is outdated.
Is compiled with VC8, which is not compatible with One-Click Installer (VC6).

Part of RubyForIIS is libfcgi and ruby-fcgi, which could be getting
loaded and thus, failing with missing dll.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From lists at ruby-forum.com  Fri Jan 11 14:49:44 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Fri, 11 Jan 2008 20:49:44 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
Message-ID: <407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>

Luis Lavena wrote:

> Will be more helpful if you provide us with the versions of ruby.
> 
Luis,

Here is my version information.

C:\eclipse\workspace>ruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]

C:\eclipse\workspace>ruby -e "puts RUBY_PLATFORM"
i386-mswin32

C:\eclipse\workspace>gem --version
1.0.1

C:\eclipse\workspace>gem list mongrel

*** LOCAL GEMS ***

mongrel (1.1)
mongrel_cluster (1.0.5)
mongrel_service (0.3.4)

Also, I have successfully installed C-based gems under the new rubygems 
regime of wanting to compile - AFAIK, my C environment is set up 
correctly for this.  However, installing the mongrel gem has never 
kicked off a compile, so I'm getting pre-compiled gems.

Wes
-- 
Posted via http://www.ruby-forum.com/.

From luislavena at gmail.com  Fri Jan 11 14:59:05 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 11 Jan 2008 17:59:05 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
Message-ID: <71166b3b0801111159j48f8a56dm86ea7428e415d4bb@mail.gmail.com>

On Jan 11, 2008 5:49 PM, Wes Gamble <lists at ruby-forum.com> wrote:
>
> Here is my version information.
>
> C:\eclipse\workspace>ruby -v
> ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
>
> C:\eclipse\workspace>ruby -e "puts RUBY_PLATFORM"
> i386-mswin32
>
> C:\eclipse\workspace>gem --version
> 1.0.1
>
> C:\eclipse\workspace>gem list mongrel
>
> *** LOCAL GEMS ***
>
> mongrel (1.1)
> mongrel_cluster (1.0.5)
> mongrel_service (0.3.4)
>

Ok, it seems I lost my bet.

But the "missing MSVCR80.dll" error is because some extension is
linked with it, and your application is loading it.

You can install the Microsoft Redistributable C runtime 8.0 and maybe
that will solve the error message.

> Also, I have successfully installed C-based gems under the new rubygems
> regime of wanting to compile - AFAIK, my C environment is set up
> correctly for this.  However, installing the mongrel gem has never
> kicked off a compile, so I'm getting pre-compiled gems.
>

Yes, that version of ruby will get proper, existing compiled gems installed.

Can you provide the whole list of gems you have installed?

Also, you're using One-Click Installer, InstantRails or Bitnami?

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From lists at ruby-forum.com  Fri Jan 11 15:07:13 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Fri, 11 Jan 2008 21:07:13 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
Message-ID: <7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>

Some more information:

(* using mongrel_rails start to startup *)

Mongrel v. 0.3.13.3: No error dialog on startup
Mongrel v. 1.0 - 1.1: Error dialog, click OK, mongrel proceeds
Mongrel v >= 1.1.1: Error dialog, click OK, error dialog reappears, no 
further progress can be made.

All I have to do is modify Mongrel versions to get these behaviors.

Does anyone know if MSVCR80.DLL is a standard part of the Microsoft 
Platform SDK for Windows Server 2003 R2 distribution?  If so, then the 
implication is I screwed up the installation somehow.

What is the latest correct version of the Windows SDK on Windows XP SP2? 
I may just try to move to that (although I'm trying to avoid that - I 
will be forsaking the Windows platform for a MacBookPro as soon as they 
announce the new models).

Wes
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Fri Jan 11 15:10:39 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Fri, 11 Jan 2008 21:10:39 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
Message-ID: <e7304a033b5f8779b3988ade4cf15bb8@ruby-forum.com>

I installed with One-Click about 2 months ago.

Here are my gems (don't make fun at how I have like almost every version 
of rails :]):

C:\eclipse\workspace\credentials>gem list

*** LOCAL GEMS ***

actionmailer (2.0.2, 2.0.1, 1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.2.5)
actionpack (2.0.2, 2.0.1, 1.13.6, 1.13.5, 1.13.4, 1.13.3, 1.12.5)
actionwebservice (1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.1.6)
activerecord (2.0.2, 2.0.1, 1.15.6, 1.15.5, 1.15.4, 1.15.3, 1.14.4)
activeresource (2.0.2)
activesupport (2.0.2, 2.0.1, 1.4.4, 1.4.3, 1.4.2, 1.3.1)
appcelerator (2.0.2)
capistrano (2.1.0, 2.0.0, 1.4.1)
cgi_multipart_eof_fix (2.5.0)
fastercsv (1.2.3)
fastthread (1.0.1)
fit (1.1)
fxri (0.3.6)
fxruby (1.6.13)
gem_plugin (0.2.3)
highline (1.4.0)
hoe (1.4.0)
hpricot (0.6)
htmlentities (4.0.0)
htmltools (1.10)
image_science (1.1.3)
json (1.1.2)
log4r (1.0.5)
mocha (0.5.6)
mongrel (1.1)
mongrel_cluster (1.0.5)
mongrel_service (0.3.4)
mysql (2.7.3)
needle (1.3.0)
net-sftp (1.1.0)
net-ssh (1.1.2)
rails (2.0.2, 2.0.1, 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.1.6)
railsbench (0.9.2)
rake (0.8.1)
rcov (0.8.1.2.0)
RedCloth (3.0.4)
redgreen (1.2.2)
rjb (1.1.1)
ropenlaszlo (0.4.1)
ruby-debug (0.10.0)
ruby-debug-base (0.10.0)
ruby-snarl (0.0.8)
rubyforge (0.4.4)
rubygems-update (1.0.1)
RubyInline (3.6.6)
rubyzip (0.9.1)
sources (0.0.1)
tattle (1.0.3)
text-format (1.0.0)
text-hyphen (1.0.0)
tzinfo (0.3.6)
watir (1.5.3)
win32-api (1.0.5)
win32-clipboard (0.4.3)
win32-dir (0.3.2)
win32-eventlog (0.4.7)
win32-file (0.5.5)
win32-file-stat (1.2.7)
win32-process (0.5.5)
win32-sapi (0.1.4)
win32-service (0.6.1, 0.5.2)
win32-sound (0.4.1)
win32console (1.0.8)
windows-api (0.2.0)
windows-pr (0.7.4)
ZenTest (3.7.2)
-- 
Posted via http://www.ruby-forum.com/.

From will at hotgazpacho.com  Fri Jan 11 21:37:16 2008
From: will at hotgazpacho.com (Will Green)
Date: Fri, 11 Jan 2008 21:37:16 -0500
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>	<47871D19.3050202@hotgazpacho.com>	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
Message-ID: <478827DC.3040409@hotgazpacho.com>

Is nmake in your path?  If so, from your comments, it appears that 
*some* of your gem installs ARE compiling gems with whatever Platform 
SDK you have installed (looks like its Server 2003).

Luis can explain far better than I, but gems compiled with VC 8 are NOT 
compatible with the One Click installer (which is compiled with VC 6). 
Sure, they *might* run, but they'll lead to trouble.

If you want to continue down this path, then the quickest way to get rid 
of the error messages you get is to install the VC 8 Runtime 
Redistributable. Don't count on a stable system, though.

I feel your pain here. I develop mostly on Vista notebook. I keep both 
the OCI *and* Cygwin's Ruby around. They both have their strengths and 
weaknesses, but until Ruby can be made to compile and function reliably 
with VC 8, I've found this to be the most stable mix (short of buying a 
Mac or installing Linux).

==
Will Green

Wes Gamble wrote:
> Some more information:
>
> (* using mongrel_rails start to startup *)
>
> Mongrel v. 0.3.13.3: No error dialog on startup
> Mongrel v. 1.0 - 1.1: Error dialog, click OK, mongrel proceeds
> Mongrel v >= 1.1.1: Error dialog, click OK, error dialog reappears, no 
> further progress can be made.
>
> All I have to do is modify Mongrel versions to get these behaviors.
>
> Does anyone know if MSVCR80.DLL is a standard part of the Microsoft 
> Platform SDK for Windows Server 2003 R2 distribution?  If so, then the 
> implication is I screwed up the installation somehow.
>
> What is the latest correct version of the Windows SDK on Windows XP SP2? 
> I may just try to move to that (although I'm trying to avoid that - I 
> will be forsaking the Windows platform for a MacBookPro as soon as they 
> announce the new models).
>
> Wes
>   


From luislavena at gmail.com  Sat Jan 12 09:30:18 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 12 Jan 2008 12:30:18 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <478827DC.3040409@hotgazpacho.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
Message-ID: <71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>

On Jan 12, 2008 12:37 AM, Will Green <will at hotgazpacho.com> wrote:
> Is nmake in your path?  If so, from your comments, it appears that
> *some* of your gem installs ARE compiling gems with whatever Platform
> SDK you have installed (looks like its Server 2003).
>

Oh, I think I overlooked at the comments done in this thread..

Yeah: if oyu have VC8/9 and Platform SDK in the Path, any gem that
output "Building native extension" legend during installation will
show up some serious problems.

> Luis can explain far better than I, but gems compiled with VC 8 are NOT
> compatible with the One Click installer (which is compiled with VC 6).
> Sure, they *might* run, but they'll lead to trouble.
>

Yep. Exactly.

I'll suggest you install a clean version of One-Click Installer
(latest is 1.8.6-26) and then install your gems in a clean
environment.

Ensure first you don't have nmake or cl in your path. That will avoid
gems being compiled with VC8.

Anyway, if you had installed both VC8 and Platform SDK, you shouldn't
see the missing runtime... unless you have some gem that wasn't
compiled properly (which is possible).

> I've found this to be the most stable mix (short of buying a
> Mac or installing Linux).
>

A mac is expensive, and will not remove the whole pain of using
Ruby... check some of the Leopard nightmares around the web ;-)

HTH,
-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From lists at ruby-forum.com  Sat Jan 12 12:48:17 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Sat, 12 Jan 2008 18:48:17 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
Message-ID: <e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>

> I'll suggest you install a clean version of One-Click Installer
> (latest is 1.8.6-26) and then install your gems in a clean
> environment.
> 
> Ensure first you don't have nmake or cl in your path. That will avoid
> gems being compiled with VC8.
> 

This is kind of funny, because when rubygems 0.9.5 came out, it appeared 
that I was now _required_ to compile native gems on Windows and that is 
when I finally made sure that nmake would work to completion and 
actually compile stuff.  It sounds like you're saying that I should have 
waited for the pre-compiled gems to get fixed :).

> A mac is expensive, and will not remove the whole pain of using
> Ruby... check some of the Leopard nightmares around the web ;-)

It's true.  But given that, in my experience, many gem and plugin 
developers test little to not at all on Windows, the Mac is the 
"platform of least surprise".  Although I've been able to solve all of 
my Windows-specific Ruby issues eventually, I am just tired of having to 
spend time and energy doing that.

Wes
-- 
Posted via http://www.ruby-forum.com/.

From luislavena at gmail.com  Sat Jan 12 12:59:17 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 12 Jan 2008 15:59:17 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
Message-ID: <71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>

On Jan 12, 2008 3:48 PM, Wes Gamble <lists at ruby-forum.com> wrote:
> > I'll suggest you install a clean version of One-Click Installer
> > (latest is 1.8.6-26) and then install your gems in a clean
> > environment.
> >
> > Ensure first you don't have nmake or cl in your path. That will avoid
> > gems being compiled with VC8.
> >
>
> This is kind of funny, because when rubygems 0.9.5 came out, it appeared
> that I was now _required_ to compile native gems on Windows and that is
> when I finally made sure that nmake would work to completion and
> actually compile stuff.  It sounds like you're saying that I should have
> waited for the pre-compiled gems to get fixed :).
>

Oh, no!

Please try upgrading rubygems to 1.0.1!!!

0.9.5 is broken for us (Windows users)!

I posted this a way back when Rails guys did the 2.dot Oh release:

http://blog.mmediasys.com/2007/12/19/latest-rubygems-and-rails-is-a-deadly-combo/

I worked a few hours with Eric Hodel getting this fixed before rubygems 1.0...

Please, update to it and the pain will go away :-D

> > A mac is expensive, and will not remove the whole pain of using
> > Ruby... check some of the Leopard nightmares around the web ;-)
>
> It's true.  But given that, in my experience, many gem and plugin
> developers test little to not at all on Windows, the Mac is the
> "platform of least surprise".  Although I've been able to solve all of
> my Windows-specific Ruby issues eventually, I am just tired of having to
> spend time and energy doing that.
>

"of least surprise" ... right :-)

I also like the "think different" motto and the just offer 2 (or one)
option to "be different". If you don't do it "the mac way", then you
should die... :-P

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From lists at ruby-forum.com  Sat Jan 12 13:23:17 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Sat, 12 Jan 2008 19:23:17 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
	<71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>
Message-ID: <01f8f85c13cca928568398f39bf42726@ruby-forum.com>

Based on my testing, it appears to me there is something that Mongrel is 
loading that is requiring MSVCR80.dll, since 1.0.  Isn't that correct?

> Oh, no!
> 
> Please try upgrading rubygems to 1.0.1!!!
> 
> 0.9.5 is broken for us (Windows users)!
> 

I've been on 1.0.1 for a while.  I'm on the rubygems-developers list so 
I see as soon as they post updates and I tend to upgrade immediately. 
So I ran into all the 0.9.5 problems and to try and fix it, I got my 
gems to compile on Windows.  But I've been off of 0.9.5 for a while.

> I also like the "think different" motto and the just offer 2 (or one)
> option to "be different". If you don't do it "the mac way", then you
> should die... :-P

I know.  Honestly, I've enjoyed the "underdog" role of being "the only 
or one of few Windows guys in the room" at Ruby/Rails gathering to some 
degree.  And when I get the sense that there is Mac elitism at work, it 
really bugs me.  But, if I'm going to use Rails as a major tool in my 
work, it behooves me to make it as easy as possible for myself to 
develop.  Back when I was doing mostly Java work, it didn't really 
matter that I was on Windows.

Wes
-- 
Posted via http://www.ruby-forum.com/.

From will at hotgazpacho.com  Sat Jan 12 14:06:30 2008
From: will at hotgazpacho.com (Will Green)
Date: Sat, 12 Jan 2008 14:06:30 -0500
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <01f8f85c13cca928568398f39bf42726@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>	<47871D19.3050202@hotgazpacho.com>	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>	<478827DC.3040409@hotgazpacho.com>	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>	<71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>
	<01f8f85c13cca928568398f39bf42726@ruby-forum.com>
Message-ID: <47890FB6.9030202@hotgazpacho.com>

Given all this, I'm starting to entertain using JRuby. It ships with 
NetBeans, and we *know* that we can compile with Java successfully...

==
Will Green

From kevwil at gmail.com  Sat Jan 12 14:07:47 2008
From: kevwil at gmail.com (Kevin Williams)
Date: Sat, 12 Jan 2008 12:07:47 -0700
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
Message-ID: <683a886f0801121107y555bed75i3aa86b250f03a5aa@mail.gmail.com>

On Jan 12, 2008 10:48 AM, Wes Gamble <lists at ruby-forum.com> wrote:
> This is kind of funny, because when rubygems 0.9.5 came out, it appeared
> that I was now _required_ to compile native gems on Windows and that is
> when I finally made sure that nmake would work to completion and
> actually compile stuff.  It sounds like you're saying that I should have
> waited for the pre-compiled gems to get fixed :).

I had the same concern when 0.9.5 came out. I think what was missed
was the fact that only compiling with VC++6 would be safe with the OCI
installation. If you have VC++6 and nmake is compiling gems for you,
you should be fine. Or, make sure you're not compiling gems. That's my
approach, at least.

-- 
Cheers,

Kevin Williams
http://www.bantamtech.com/

From luislavena at gmail.com  Sat Jan 12 14:08:56 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 12 Jan 2008 17:08:56 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <47890FB6.9030202@hotgazpacho.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
	<71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>
	<01f8f85c13cca928568398f39bf42726@ruby-forum.com>
	<47890FB6.9030202@hotgazpacho.com>
Message-ID: <71166b3b0801121108s60d39c20g325860182e060724@mail.gmail.com>

On Jan 12, 2008 5:06 PM, Will Green <will at hotgazpacho.com> wrote:
> Given all this, I'm starting to entertain using JRuby. It ships with
> NetBeans, and we *know* that we can compile with Java successfully...
>

Compile once, debug everywhere... :D
Hehehe, I remember the days back in 1997 when java was released :D

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From luislavena at gmail.com  Sat Jan 12 14:10:54 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 12 Jan 2008 17:10:54 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <01f8f85c13cca928568398f39bf42726@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
	<71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>
	<01f8f85c13cca928568398f39bf42726@ruby-forum.com>
Message-ID: <71166b3b0801121110r1d189016m9639df545915a3c7@mail.gmail.com>

On Jan 12, 2008 4:23 PM, Wes Gamble <lists at ruby-forum.com> wrote:
> Based on my testing, it appears to me there is something that Mongrel is
> loading that is requiring MSVCR80.dll, since 1.0.  Isn't that correct?
>

No, all the version of mongrel are build with VC6, so the http11
extension is linked to MSVCRT.dll, and not MSVCR80.dll

can you try this on a IRB console?

irb(main):002:0> require 'rubygems'
=> true
irb(main):003:0> require 'mongrel'
=> true
irb(main):004:0> Mongrel::Const::MONGREL_VERSION
=> "1.1.2"

If you don't get the msgbox in that process is because mongrel isn't
responsible for that. If you get, I'll suggest you remove the mongrel
gem and clean install it again.

>
> I know.  Honestly, I've enjoyed the "underdog" role of being "the only
> or one of few Windows guys in the room" at Ruby/Rails gathering to some
> degree.  And when I get the sense that there is Mac elitism at work, it
> really bugs me.  But, if I'm going to use Rails as a major tool in my
> work, it behooves me to make it as easy as possible for myself to
> develop.  Back when I was doing mostly Java work, it didn't really
> matter that I was on Windows.
>

Since I started with Rails (back in 0.13) I didn't have too many
troubles with it. Ruby, by itself, didn't showed my troubles neither.
But some of the "popular libraries" have them, mostly because some
developers ignores other platforms (part of their elitism or
ignorance).

I use Rails on a daily basis to deploy to linux servers, all without
glitches (trust me: noone).

ssh to some server? no problem. have all your ssh keys? no problem
(pageant, putty ssh agent).

Anyway, I found no problems using Rails on Windows, except those
plugins from some developers that didn't care about good/fair usage of
resources or the true nature of ruby a being cross-platform language.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From luislavena at gmail.com  Sat Jan 12 14:12:16 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 12 Jan 2008 17:12:16 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <683a886f0801121107y555bed75i3aa86b250f03a5aa@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
	<683a886f0801121107y555bed75i3aa86b250f03a5aa@mail.gmail.com>
Message-ID: <71166b3b0801121112v7b077f7lc5bcd044505d8419@mail.gmail.com>

On Jan 12, 2008 5:07 PM, Kevin Williams <kevwil at gmail.com> wrote:
> On Jan 12, 2008 10:48 AM, Wes Gamble <lists at ruby-forum.com> wrote:
> > This is kind of funny, because when rubygems 0.9.5 came out, it appeared
> > that I was now _required_ to compile native gems on Windows and that is
> > when I finally made sure that nmake would work to completion and
> > actually compile stuff.  It sounds like you're saying that I should have
> > waited for the pre-compiled gems to get fixed :).
>
> I had the same concern when 0.9.5 came out. I think what was missed
> was the fact that only compiling with VC++6 would be safe with the OCI
> installation. If you have VC++6 and nmake is compiling gems for you,
> you should be fine. Or, make sure you're not compiling gems. That's my
> approach, at least.
>

0.9.5 was using the pure-ruby version of the gems, that doesn't mean
it was right.
Neither ruby compilation troubles where fixed :-P

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From lists at ruby-forum.com  Sat Jan 12 14:39:45 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Sat, 12 Jan 2008 20:39:45 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <71166b3b0801121110r1d189016m9639df545915a3c7@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
	<71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>
	<01f8f85c13cca928568398f39bf42726@ruby-forum.com>
	<71166b3b0801121110r1d189016m9639df545915a3c7@mail.gmail.com>
Message-ID: <e0ca0fb9c17fdc4b1a59f39b995f2d58@ruby-forum.com>

I found it.  Sigh.

Mongrel was trying to use fastthread 1.0.1 which apparently had been 
compiled with VC 8 (see below).  I'm pretty sure that fastthread is not 
even necessary anymore - is that right?  When I removed the fastthread 
gem, it starts up fine.

Also, check out my VC8 polluted PATH entries:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE;
C:\Program Files\Microsoft Visual Studio 8\VC\BIN;
C:\Program Files\Microsoft Visual Studio 8\Common7\Tools;
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin;
C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin;
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;
C:\Program Files\Microsoft Visual Studio 8\VC\VCPackages;

(I got these because I installed the MSVC++ 2005 Express Edition at some 
point).

So...just to be clear, should these entries be banished from my PATH 
immediately (unless of course I decide to start developing VC++ :])?

Thanks for all of the help, guys.

Wes
-- 
Posted via http://www.ruby-forum.com/.

From luislavena at gmail.com  Sat Jan 12 15:10:55 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 12 Jan 2008 18:10:55 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <e0ca0fb9c17fdc4b1a59f39b995f2d58@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
	<71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>
	<01f8f85c13cca928568398f39bf42726@ruby-forum.com>
	<71166b3b0801121110r1d189016m9639df545915a3c7@mail.gmail.com>
	<e0ca0fb9c17fdc4b1a59f39b995f2d58@ruby-forum.com>
Message-ID: <71166b3b0801121210v4341772dw65adb5b67152b011@mail.gmail.com>

On Jan 12, 2008 5:39 PM, Wes Gamble <lists at ruby-forum.com> wrote:
> I found it.  Sigh.
>
> Mongrel was trying to use fastthread 1.0.1 which apparently had been
> compiled with VC 8 (see below).  I'm pretty sure that fastthread is not
> even necessary anymore - is that right?  When I removed the fastthread
> gem, it starts up fine.
>

Aha!

that's Rubygems 0.9.5 fault!

When you tried to install at some point mongrel with 0.9.5, rubygems
pulled fastthread source instead of the pre-compiled gem I made
available.

Anyway, if you're using PATCHLEVEL above 36 you're safe, if not, you
need fastthread.

I suggest you update to latest One-Click Installer, do a gem update
--system and use it :-)

> Also, check out my VC8 polluted PATH entries:
>
> C:\Program Files\Microsoft Visual Studio 8\Common7\IDE;
> C:\Program Files\Microsoft Visual Studio 8\VC\BIN;
> C:\Program Files\Microsoft Visual Studio 8\Common7\Tools;
> C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin;
> C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin;
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;
> C:\Program Files\Microsoft Visual Studio 8\VC\VCPackages;
>
> (I got these because I installed the MSVC++ 2005 Express Edition at some
> point).
>

That's why the gem installation process didn't fail on you since nmake
and cl.exe was available all the time!

I love to have my PATHs under control (yeah, I'm uscha  control freak) ;-)
Visual Studio made that impossible...

> So...just to be clear, should these entries be banished from my PATH
> immediately (unless of course I decide to start developing VC++ :])?

Maybe you can create a shortcut for the commandline version, like
previous Visual Studio versions did. Google for that and you will find
good resources about setvc, setvars or setvcvars (bat and cmd).

> Thanks for all of the help, guys.

No problem, I was worried that I broke something inside mongrel in
latest release! :P

Take care,

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From lists at ruby-forum.com  Sat Jan 12 15:20:24 2008
From: lists at ruby-forum.com (Wes Gamble)
Date: Sat, 12 Jan 2008 21:20:24 +0100
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <71166b3b0801121210v4341772dw65adb5b67152b011@mail.gmail.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<47871D19.3050202@hotgazpacho.com>
	<a593750384309835bafbe1ff791b44ef@ruby-forum.com>
	<71166b3b0801110156q28b497a1m814611696a83497c@mail.gmail.com>
	<e971c8a1d71ec689d7d8ec74f23bb72a@ruby-forum.com>
	<683a886f0801111051n2a11d7a5ve9b4940470447023@mail.gmail.com>
	<71166b3b0801111125u37b59e49o65d17615242b0c06@mail.gmail.com>
	<407e95cfe078401c0a55fb3959ffedde@ruby-forum.com>
	<7689d89952bd725ffc3401a2040f99cc@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
	<71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>
	<01f8f85c13cca928568398f39bf42726@ruby-forum.com>
	<71166b3b0801121110r1d189016m9639df545915a3c7@mail.gmail.com>
	<e0ca0fb9c17fdc4b1a59f39b995f2d58@ruby-forum.com>
	<71166b3b0801121210v4341772dw65adb5b67152b011@mail.gmail.com>
Message-ID: <79f57f73ba8d0f1651971dab4e592077@ruby-forum.com>

Luis Lavena wrote:
> Anyway, if you're using PATCHLEVEL above 36 you're safe, if not, you
> need fastthread.

You mean the patchlevel of ruby in the OCI gotten via ruby -v?

Wes
-- 
Posted via http://www.ruby-forum.com/.

From luislavena at gmail.com  Sat Jan 12 15:37:36 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 12 Jan 2008 18:37:36 -0200
Subject: [Mongrel] Mongrel doesn't start under Rails 2.0.2/Win XP
In-Reply-To: <79f57f73ba8d0f1651971dab4e592077@ruby-forum.com>
References: <da14998de031a54da8fcc6a3c838c895@ruby-forum.com>
	<478827DC.3040409@hotgazpacho.com>
	<71166b3b0801120630o2cd56f20hdcda3a59dedb6546@mail.gmail.com>
	<e7d83ab18a1cc873ceb6fc7a8299d689@ruby-forum.com>
	<71166b3b0801120959v2111e770rf86333d66844c50b@mail.gmail.com>
	<01f8f85c13cca928568398f39bf42726@ruby-forum.com>
	<71166b3b0801121110r1d189016m9639df545915a3c7@mail.gmail.com>
	<e0ca0fb9c17fdc4b1a59f39b995f2d58@ruby-forum.com>
	<71166b3b0801121210v4341772dw65adb5b67152b011@mail.gmail.com>
	<79f57f73ba8d0f1651971dab4e592077@ruby-forum.com>
Message-ID: <71166b3b0801121237p6f51c673n5a3e81fac4cde39@mail.gmail.com>

On Jan 12, 2008 6:20 PM, Wes Gamble <lists at ruby-forum.com> wrote:
> Luis Lavena wrote:
> > Anyway, if you're using PATCHLEVEL above 36 you're safe, if not, you
> > need fastthread.
>
> You mean the patchlevel of ruby in the OCI gotten via ruby -v?

Yep, sorry about that:

>ruby -e "puts RUBY_PATCHLEVEL"
111

>ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From lists at ruby-forum.com  Sun Jan 13 10:55:33 2008
From: lists at ruby-forum.com (Bbq Plate)
Date: Sun, 13 Jan 2008 16:55:33 +0100
Subject: [Mongrel] Mongrel + apache 2.2 + proxy error
In-Reply-To: <bdefa7fcb661e0471aad39caf8c45723@ruby-forum.com>
References: <5729527e61082c10eb8e04e3615c2565@ruby-forum.com>
	<C24E2704-6D95-4E4F-8244-656BD49548A8@cheney.net>
	<bdefa7fcb661e0471aad39caf8c45723@ruby-forum.com>
Message-ID: <e8e0238b411ee2f2a26f594775e425d3@ruby-forum.com>

hi,
i am getting this error as well but my process is a small one. it seems 
after my rails app is running for a day, i notice that every so 
often(every 3-4 clicks on the site), the process hangs. after i restart 
my mongrels, its back to normal again. any solution you have found?
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Mon Jan 14 05:12:12 2008
From: lists at ruby-forum.com (Abir B.)
Date: Mon, 14 Jan 2008 11:12:12 +0100
Subject: [Mongrel] Reading HTTP Request parameters
Message-ID: <2f66c268efd1462a64ab821c5e14668d@ruby-forum.com>

Hello
I've a client which send this request to a mongrel HTTPHandler :

res=Net::HTTP.post_form(URI.parse('http://localhost:3000/test'),{"a"=>1,"b"=>2})

But in the handler I can't read the parameters one by one, I can read
the entire String only :
class Serveur
  class MyHandler < Mongrel::HttpHandler
    def process(req, resp)
              ...
           @params=req.params
           @params.http_body
              ...
   end
 end
...
end


@params.http_body give me :
a=1&b=2 which is a string

I would like a code which return me 1 for something[:a] and 2 for
something[:b]...
thanks
-- 
Posted via http://www.ruby-forum.com/.

From eden at mojiti.com  Mon Jan 14 05:31:57 2008
From: eden at mojiti.com (Eden Li)
Date: Mon, 14 Jan 2008 18:31:57 +0800
Subject: [Mongrel] Reading HTTP Request parameters
In-Reply-To: <2f66c268efd1462a64ab821c5e14668d@ruby-forum.com>
References: <2f66c268efd1462a64ab821c5e14668d@ruby-forum.com>
Message-ID: <1dd361e10801140231r3f2db151tca2273a9b55826fc@mail.gmail.com>

HttpRequest.query_parse(@params.http_body)

http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpRequest.html#M000126

On Jan 14, 2008 6:12 PM, Abir B. <lists at ruby-forum.com> wrote:
> Hello
> I've a client which send this request to a mongrel HTTPHandler :
>
> res=Net::HTTP.post_form(URI.parse('http://localhost:3000/test'),{"a"=>1,"b"=>2})
>
> But in the handler I can't read the parameters one by one, I can read
> the entire String only :
> class Serveur
>   class MyHandler < Mongrel::HttpHandler
>     def process(req, resp)
>               ...
>            @params=req.params
>            @params.http_body
>               ...
>    end
>  end
> ...
> end
>
>
> @params.http_body give me :
> a=1&b=2 which is a string
>
> I would like a code which return me 1 for something[:a] and 2 for
> something[:b]...
> thanks
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From lists at ruby-forum.com  Mon Jan 14 09:39:25 2008
From: lists at ruby-forum.com (Abir B.)
Date: Mon, 14 Jan 2008 15:39:25 +0100
Subject: [Mongrel] Reading HTTP Request parameters
In-Reply-To: <1dd361e10801140231r3f2db151tca2273a9b55826fc@mail.gmail.com>
References: <2f66c268efd1462a64ab821c5e14668d@ruby-forum.com>
	<1dd361e10801140231r3f2db151tca2273a9b55826fc@mail.gmail.com>
Message-ID: <0925604640c4decff76dbfe3babfb8e1@ruby-forum.com>

Eden Li wrote:
> HttpRequest.query_parse(@params.http_body)
> 
> http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpRequest.html#M000126

:-)
that's just what I'm searching (I tried it with a wrong syntax : 
req.query_parse and it didn't work...)

thanks
-- 
Posted via http://www.ruby-forum.com/.

From ry at tinyclouds.org  Mon Jan 14 11:43:09 2008
From: ry at tinyclouds.org (ry dahl)
Date: Mon, 14 Jan 2008 17:43:09 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
Message-ID: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>

Hello Mongrel Users,

I'm writing a web server called Ebb. It's written in C, makes use of
the Mongrel HTTP parser, and uses libev its event loop. The goal is to
be small, fast, and language independent server that can host web
frameworks. I have written a small Ruby binding which provides a Rack
handler - this will allow Ebb to host Rails, Merb, and other Ruby
frameworks. In the future I will write a Python WSGI binding.

The design is similar to the evented Mongrel web server. Connections
are processed as follows:

1. libev loops and waits for incoming connections.
2. When Ebb can read from a client socket, it passes the buffer into the
   mongrel state machine which parses the headers into name value pairs.
3. Ebb starts a new thread and passes the request information and peer socket
   to a user supplied callback. The thread lasts only for the length of that
   callback.
4. The included Ruby binding, supplying this callback transforms the request
   into a Rack compatible "env" variable and passes it on a Rack adapter.

The code measures in at less than 1000 lines of C code.

There is much work to do; it is not ready for use. I am soliciting
help from the community for testing and development. You may browse
the git repository at http://repo.or.cz/w/ebb.git or check out the
code with this command:
git clone git://repo.or.cz/ebb.git
I release Ebb under the MIT license.
It is very fun to program Ebb so I suggest you do too :)


Ry Dahl

From luislavena at gmail.com  Mon Jan 14 12:16:01 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 14 Jan 2008 15:16:01 -0200
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
Message-ID: <71166b3b0801140916m1808f5c5jd43457e07ff80140@mail.gmail.com>

On Jan 14, 2008 2:43 PM, ry dahl <ry at tinyclouds.org> wrote:
> Hello Mongrel Users,
>
> I'm writing a web server called Ebb. It's written in C, makes use of
> the Mongrel HTTP parser, and uses libev its event loop. The goal is to
> be small, fast, and language independent server that can host web
> frameworks. I have written a small Ruby binding which provides a Rack
> handler - this will allow Ebb to host Rails, Merb, and other Ruby
> frameworks. In the future I will write a Python WSGI binding.
>

Nice ry!

>
> There is much work to do; it is not ready for use. I am soliciting
> help from the community for testing and development. You may browse
> the git repository at http://repo.or.cz/w/ebb.git or check out the
> code with this command:
> git clone git://repo.or.cz/ebb.git
> I release Ebb under the MIT license.
> It is very fun to program Ebb so I suggest you do too :)
>

A svn repo clone? (git-svn)? Not all jumped into the git bandwagon :-)

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From ersin.er at gmail.com  Mon Jan 14 13:21:08 2008
From: ersin.er at gmail.com (Ersin Er)
Date: Mon, 14 Jan 2008 20:21:08 +0200
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
Message-ID: <a1b4a6610801141021m5416de91x876451fa5a04c8ec@mail.gmail.com>

Good luck with your new server! I also suggest looking at Thin which
has been developed very recently and seems quite promising:

http://code.macournoyer.com/thin/

According to the benchmarks it's the fastest Ruby web server currently.

On Jan 14, 2008 6:43 PM, ry dahl <ry at tinyclouds.org> wrote:
> Hello Mongrel Users,
>
> I'm writing a web server called Ebb. It's written in C, makes use of
> the Mongrel HTTP parser, and uses libev its event loop. The goal is to
> be small, fast, and language independent server that can host web
> frameworks. I have written a small Ruby binding which provides a Rack
> handler - this will allow Ebb to host Rails, Merb, and other Ruby
> frameworks. In the future I will write a Python WSGI binding.
>
> The design is similar to the evented Mongrel web server. Connections
> are processed as follows:
>
> 1. libev loops and waits for incoming connections.
> 2. When Ebb can read from a client socket, it passes the buffer into the
>    mongrel state machine which parses the headers into name value pairs.
> 3. Ebb starts a new thread and passes the request information and peer socket
>    to a user supplied callback. The thread lasts only for the length of that
>    callback.
> 4. The included Ruby binding, supplying this callback transforms the request
>    into a Rack compatible "env" variable and passes it on a Rack adapter.
>
> The code measures in at less than 1000 lines of C code.
>
> There is much work to do; it is not ready for use. I am soliciting
> help from the community for testing and development. You may browse
> the git repository at http://repo.or.cz/w/ebb.git or check out the
> code with this command:
> git clone git://repo.or.cz/ebb.git
> I release Ebb under the MIT license.
> It is very fun to program Ebb so I suggest you do too :)
>
>
> Ry Dahl
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Ersin Er

From macournoyer at gmail.com  Mon Jan 14 13:56:02 2008
From: macournoyer at gmail.com (=?ISO-8859-1?Q?Marc-Andr=E9_Cournoyer?=)
Date: Mon, 14 Jan 2008 13:56:02 -0500
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <a1b4a6610801141021m5416de91x876451fa5a04c8ec@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<a1b4a6610801141021m5416de91x876451fa5a04c8ec@mail.gmail.com>
Message-ID: <DB7EE419-0FF6-4B91-9632-CE90783FE058@gmail.com>

Hey Ry,

Your project looks amazing. I had a look at rev to use libev, but it  
seems to be Ruby 1.9 only and I'm far from a C expert. So right now  
Thin uses EventMachine.

I really like your idea and I think we could help each other in  
building something very cool.
If you'd like to participate in Thin and have some suggestions on how  
to make it better we should have a talk.
Send me an email if you're interested.

Marc

On 14-Jan-08, at 1:21 PM, Ersin Er wrote:

> Good luck with your new server! I also suggest looking at Thin which
> has been developed very recently and seems quite promising:
>
> http://code.macournoyer.com/thin/
>
> According to the benchmarks it's the fastest Ruby web server  
> currently.
>
> On Jan 14, 2008 6:43 PM, ry dahl <ry at tinyclouds.org> wrote:
>> Hello Mongrel Users,
>>
>> I'm writing a web server called Ebb. It's written in C, makes use of
>> the Mongrel HTTP parser, and uses libev its event loop. The goal is  
>> to
>> be small, fast, and language independent server that can host web
>> frameworks. I have written a small Ruby binding which provides a Rack
>> handler - this will allow Ebb to host Rails, Merb, and other Ruby
>> frameworks. In the future I will write a Python WSGI binding.
>>
>> The design is similar to the evented Mongrel web server. Connections
>> are processed as follows:
>>
>> 1. libev loops and waits for incoming connections.
>> 2. When Ebb can read from a client socket, it passes the buffer  
>> into the
>>   mongrel state machine which parses the headers into name value  
>> pairs.
>> 3. Ebb starts a new thread and passes the request information and  
>> peer socket
>>   to a user supplied callback. The thread lasts only for the length  
>> of that
>>   callback.
>> 4. The included Ruby binding, supplying this callback transforms  
>> the request
>>   into a Rack compatible "env" variable and passes it on a Rack  
>> adapter.
>>
>> The code measures in at less than 1000 lines of C code.
>>
>> There is much work to do; it is not ready for use. I am soliciting
>> help from the community for testing and development. You may browse
>> the git repository at http://repo.or.cz/w/ebb.git or check out the
>> code with this command:
>> git clone git://repo.or.cz/ebb.git
>> I release Ebb under the MIT license.
>> It is very fun to program Ebb so I suggest you do too :)
>>
>>
>> Ry Dahl
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>
>
>
> -- 
> Ersin Er
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From ry at tinyclouds.org  Mon Jan 14 13:56:11 2008
From: ry at tinyclouds.org (ry dahl)
Date: Mon, 14 Jan 2008 19:56:11 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <71166b3b0801140916m1808f5c5jd43457e07ff80140@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<71166b3b0801140916m1808f5c5jd43457e07ff80140@mail.gmail.com>
Message-ID: <3ae7f4480801141056j32f7b657m84e5bd72a09be33e@mail.gmail.com>

> A svn repo clone? (git-svn)? Not all jumped into the git bandwagon :-)

Sorry - my hosting abilities are limited. I also find the multitude of
revision control software annoying (but git seems functional!)
apt-get install git


ry

From luislavena at gmail.com  Mon Jan 14 15:50:50 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 14 Jan 2008 18:50:50 -0200
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801141056j32f7b657m84e5bd72a09be33e@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<71166b3b0801140916m1808f5c5jd43457e07ff80140@mail.gmail.com>
	<3ae7f4480801141056j32f7b657m84e5bd72a09be33e@mail.gmail.com>
Message-ID: <71166b3b0801141250tbb7b06ya2cc55147b1b8c67@mail.gmail.com>

On Jan 14, 2008 4:56 PM, ry dahl <ry at tinyclouds.org> wrote:
> > A svn repo clone? (git-svn)? Not all jumped into the git bandwagon :-)
>
> Sorry - my hosting abilities are limited. I also find the multitude of
> revision control software annoying (but git seems functional!)
> apt-get install git
>

no apt-get on Windows. And git support on it is a bit flacky
(I hear another git versus *nix versus windows discussion starting).

I'm on Bazaar, which is the same used by Ubuntu :-)

http://bazaar-vcs.org/BzrVsGit

Anyway, have git but not on my Windows box.

Will check your code this weekend ;-)

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From ezmobius at gmail.com  Mon Jan 14 16:03:18 2008
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Mon, 14 Jan 2008 13:03:18 -0800
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
Message-ID: <12E63B8C-8166-470E-9BFD-D48EB552DBAA@gmail.com>


On Jan 14, 2008, at 8:43 AM, ry dahl wrote:

> Hello Mongrel Users,
>
> I'm writing a web server called Ebb. It's written in C, makes use of
> the Mongrel HTTP parser, and uses libev its event loop. The goal is to
> be small, fast, and language independent server that can host web
> frameworks. I have written a small Ruby binding which provides a Rack
> handler - this will allow Ebb to host Rails, Merb, and other Ruby
> frameworks. In the future I will write a Python WSGI binding.
>
> The design is similar to the evented Mongrel web server. Connections
> are processed as follows:
>
> 1. libev loops and waits for incoming connections.
> 2. When Ebb can read from a client socket, it passes the buffer into  
> the
>   mongrel state machine which parses the headers into name value  
> pairs.
> 3. Ebb starts a new thread and passes the request information and  
> peer socket
>   to a user supplied callback. The thread lasts only for the length  
> of that
>   callback.
> 4. The included Ruby binding, supplying this callback transforms the  
> request
>   into a Rack compatible "env" variable and passes it on a Rack  
> adapter.
>
> The code measures in at less than 1000 lines of C code.
>
> There is much work to do; it is not ready for use. I am soliciting
> help from the community for testing and development. You may browse
> the git repository at http://repo.or.cz/w/ebb.git or check out the
> code with this command:
> git clone git://repo.or.cz/ebb.git
> I release Ebb under the MIT license.
> It is very fun to program Ebb so I suggest you do too :)
>
>
> Ry Dahl

Hey Ry-

	Is glib-2.0 a dependency? It seems like 2.0 is an old version of  
glib. So ebb doesn't compile on leopard out of the box. What do I need  
to install to make it work?

~/ebb > make
gcc -g -Wall `pkg-config --cflags glib-2.0` -I/opt/libev-2.01/include - 
L/opt/libev-2.01/lib -c tcp.c -o tcp.o
Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glib-2.0' found
tcp.c:18:16: error: ev.h: No such file or directory
tcp.c:19:18: error: glib.h: No such file or directory
In file included from tcp.c:23:
tcp.h:48: error: syntax error before ?GQueue?
tcp.h:48: warning: no semicolon at end of struct or union
tcp.h:53: error: syntax error before ?*? token
tcp.h:53: warning: type defaults to ?int? in declaration of  
?accept_watcher?
tcp.h:53: warning: data definition has no type or storage class
tcp.h:55: error: syntax error before ?}? token
tcp.h:72: error: syntax error before ?ev_io?
tcp.h:72: warning: no semicolon at end of struct or union
tcp.c: In function ?tcp_client_write?:
tcp.c:33: error: dereferencing pointer to incomplete type
tcp.c:34: error: dereferencing pointer to incomplete type
tcp.c:36: warning: implicit declaration of function ?g_log?
tcp.c:36: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this  
function)
tcp.c:36: error: (Each undeclared identifier is reported only once
tcp.c:36: error: for each function it appears in.)
tcp.c: At top level:
tcp.c:46: warning: ?struct ev_io? declared inside parameter list
tcp.c:46: warning: its scope is only this definition or declaration,  
which is probably not what you want
tcp.c: In function ?tcp_client_on_readable?:
tcp.c:48: error: dereferencing pointer to incomplete type
tcp.c:52: error: ?EV_ERROR? undeclared (first use in this function)
tcp.c:53: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this  
function)
tcp.c:57: error: dereferencing pointer to incomplete type
tcp.c:58: error: dereferencing pointer to incomplete type
tcp.c:59: error: dereferencing pointer to incomplete type
tcp.c:60: error: dereferencing pointer to incomplete type
tcp.c:62: error: dereferencing pointer to incomplete type
tcp.c:64: error: dereferencing pointer to incomplete type
tcp.c:64: error: dereferencing pointer to incomplete type
tcp.c:67: warning: implicit declaration of function ?g_debug?
tcp.c:81: error: dereferencing pointer to incomplete type
tcp.c:81: error: dereferencing pointer to incomplete type
tcp.c:81: error: dereferencing pointer to incomplete type
tcp.c: In function ?tcp_client_new?:
tcp.c:95: warning: implicit declaration of function ?g_new0?
tcp.c:95: error: syntax error before ?tcp_client?
tcp.c:97: error: dereferencing pointer to incomplete type
tcp.c:99: error: dereferencing pointer to incomplete type
tcp.c:99: error: dereferencing pointer to incomplete type
tcp.c:99: error: dereferencing pointer to incomplete type
tcp.c:100: error: dereferencing pointer to incomplete type
tcp.c:101: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this  
function)
tcp.c:105: error: dereferencing pointer to incomplete type
tcp.c:105: error: ?TRUE? undeclared (first use in this function)
tcp.c:107: error: dereferencing pointer to incomplete type
tcp.c:113: error: dereferencing pointer to incomplete type
tcp.c:115: error: dereferencing pointer to incomplete type
tcp.c:115: error: syntax error before ?struct?
tcp.c:116: error: dereferencing pointer to incomplete type
tcp.c:117: warning: implicit declaration of function ?ev_init?
tcp.c:117: error: dereferencing pointer to incomplete type
tcp.c:118: warning: implicit declaration of function ?ev_io_set?
tcp.c:118: error: dereferencing pointer to incomplete type
tcp.c:118: error: dereferencing pointer to incomplete type
tcp.c:118: error: ?EV_READ? undeclared (first use in this function)
tcp.c:118: error: ?EV_ERROR? undeclared (first use in this function)
tcp.c:119: warning: implicit declaration of function ?ev_io_start?
tcp.c:119: error: dereferencing pointer to incomplete type
tcp.c:119: error: dereferencing pointer to incomplete type
tcp.c: In function ?tcp_client_stop_read_watcher?:
tcp.c:131: error: dereferencing pointer to incomplete type
tcp.c:134: error: dereferencing pointer to incomplete type
tcp.c:136: warning: implicit declaration of function ?ev_io_stop?
tcp.c:136: error: dereferencing pointer to incomplete type
tcp.c:136: error: dereferencing pointer to incomplete type
tcp.c:137: error: dereferencing pointer to incomplete type
tcp.c:138: error: dereferencing pointer to incomplete type
tcp.c: In function ?tcp_client_free?:
tcp.c:146: error: dereferencing pointer to incomplete type
tcp.c: In function ?tcp_client_close?:
tcp.c:153: error: dereferencing pointer to incomplete type
tcp.c:155: error: dereferencing pointer to incomplete type
tcp.c:156: error: dereferencing pointer to incomplete type
tcp.c:156: error: ?FALSE? undeclared (first use in this function)
tcp.c: In function ?tcp_server_new?:
tcp.c:165: error: syntax error before ?tcp_server?
tcp.c:167: error: dereferencing pointer to incomplete type
tcp.c:168: error: dereferencing pointer to incomplete type
tcp.c:170: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this  
function)
tcp.c:175: error: dereferencing pointer to incomplete type
tcp.c:189: error: dereferencing pointer to incomplete type
tcp.c:189: warning: implicit declaration of function ?ev_loop_new?
tcp.c:191: error: dereferencing pointer to incomplete type
tcp.c:191: warning: implicit declaration of function ?g_queue_new?
tcp.c:192: error: dereferencing pointer to incomplete type
tcp.c:192: error: ?FALSE? undeclared (first use in this function)
tcp.c: In function ?tcp_server_free?:
tcp.c:203: warning: implicit declaration of function ?g_queue_free?
tcp.c:203: error: dereferencing pointer to incomplete type
tcp.c: In function ?tcp_server_close?:
tcp.c:211: error: dereferencing pointer to incomplete type
tcp.c:214: warning: implicit declaration of function ?g_queue_pop_head?
tcp.c:214: error: dereferencing pointer to incomplete type
tcp.c:214: warning: assignment makes pointer from integer without a cast
tcp.c:217: error: dereferencing pointer to incomplete type
tcp.c:218: error: dereferencing pointer to incomplete type
tcp.c:219: error: dereferencing pointer to incomplete type
tcp.c:221: error: dereferencing pointer to incomplete type
tcp.c:222: error: dereferencing pointer to incomplete type
tcp.c:223: error: dereferencing pointer to incomplete type
tcp.c:225: error: dereferencing pointer to incomplete type
tcp.c:227: error: dereferencing pointer to incomplete type
tcp.c:227: error: dereferencing pointer to incomplete type
tcp.c:228: error: dereferencing pointer to incomplete type
tcp.c:229: error: dereferencing pointer to incomplete type
tcp.c:231: warning: implicit declaration of function ?ev_unloop?
tcp.c:231: error: dereferencing pointer to incomplete type
tcp.c:231: error: ?EVUNLOOP_ALL? undeclared (first use in this function)
tcp.c:232: warning: implicit declaration of function ?ev_loop_destroy?
tcp.c:232: error: dereferencing pointer to incomplete type
tcp.c:233: error: dereferencing pointer to incomplete type
tcp.c:235: error: dereferencing pointer to incomplete type
tcp.c:236: error: dereferencing pointer to incomplete type
tcp.c:236: error: ?FALSE? undeclared (first use in this function)
tcp.c: At top level:
tcp.c:242: warning: ?struct ev_io? declared inside parameter list
tcp.c: In function ?tcp_server_accept?:
tcp.c:244: error: dereferencing pointer to incomplete type
tcp.c:247: error: dereferencing pointer to incomplete type
tcp.c:248: error: dereferencing pointer to incomplete type
tcp.c:251: error: ?EV_ERROR? undeclared (first use in this function)
tcp.c:252: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this  
function)
tcp.c:258: warning: implicit declaration of function ?g_queue_push_head?
tcp.c:258: error: dereferencing pointer to incomplete type
tcp.c:258: error: ?gpointer? undeclared (first use in this function)
tcp.c:258: error: syntax error before ?client?
tcp.c:260: error: dereferencing pointer to incomplete type
tcp.c:261: error: dereferencing pointer to incomplete type
tcp.c:261: error: dereferencing pointer to incomplete type
tcp.c: In function ?tcp_server_listen?:
tcp.c:276: error: dereferencing pointer to incomplete type
tcp.c:277: error: dereferencing pointer to incomplete type
tcp.c:280: error: dereferencing pointer to incomplete type
tcp.c:281: error: dereferencing pointer to incomplete type
tcp.c:283: error: dereferencing pointer to incomplete type
tcp.c:284: error: dereferencing pointer to incomplete type
tcp.c:284: error: dereferencing pointer to incomplete type
tcp.c:285: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this  
function)
tcp.c:288: error: dereferencing pointer to incomplete type
tcp.c:288: error: dereferencing pointer to incomplete type
tcp.c:298: error: dereferencing pointer to incomplete type
tcp.c:298: error: dereferencing pointer to incomplete type
tcp.c:298: error: dereferencing pointer to incomplete type
tcp.c:304: error: dereferencing pointer to incomplete type
tcp.c:310: error: dereferencing pointer to incomplete type
tcp.c:310: error: ?FALSE? undeclared (first use in this function)
tcp.c:311: error: dereferencing pointer to incomplete type
tcp.c:311: error: ?TRUE? undeclared (first use in this function)
tcp.c:313: error: dereferencing pointer to incomplete type
tcp.c:313: error: syntax error before ?struct?
tcp.c:314: error: dereferencing pointer to incomplete type
tcp.c:315: error: dereferencing pointer to incomplete type
tcp.c:316: error: dereferencing pointer to incomplete type
tcp.c:318: error: dereferencing pointer to incomplete type
tcp.c:319: error: dereferencing pointer to incomplete type
tcp.c:319: error: dereferencing pointer to incomplete type
tcp.c:319: error: ?EV_READ? undeclared (first use in this function)
tcp.c:319: error: ?EV_ERROR? undeclared (first use in this function)
tcp.c:320: error: dereferencing pointer to incomplete type
tcp.c:320: error: dereferencing pointer to incomplete type
tcp.c:321: warning: implicit declaration of function ?ev_loop?
tcp.c:321: error: dereferencing pointer to incomplete type
tcp.c: In function ?tcp_server_address?:
tcp.c:331: error: dereferencing pointer to incomplete type
tcp.c:332: error: dereferencing pointer to incomplete type
tcp.c:335: warning: control reaches end of non-void function
make: *** [tcp.o] Error 1


Thanks


- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ezra at engineyard.com
-- EngineYard.com


From ry at tinyclouds.org  Mon Jan 14 16:17:27 2008
From: ry at tinyclouds.org (ry dahl)
Date: Mon, 14 Jan 2008 22:17:27 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <12E63B8C-8166-470E-9BFD-D48EB552DBAA@gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<12E63B8C-8166-470E-9BFD-D48EB552DBAA@gmail.com>
Message-ID: <3ae7f4480801141317k6a0edb9eu70195d34596e5ba4@mail.gmail.com>

Hi Erza,

I'm not sure if glib is installed by default on macs. (Seems like it
should be but I don't see it on mine.) If you use fink you can do
  apt-get install glib2-dev
The makefile is pretty hacky - make sure you have libev in your
LIBRARY_PATH and ev.h in your CPATH

ry

On Jan 14, 2008 10:03 PM, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
>
> On Jan 14, 2008, at 8:43 AM, ry dahl wrote:
>
> > Hello Mongrel Users,
> >
> > I'm writing a web server called Ebb. It's written in C, makes use of
> > the Mongrel HTTP parser, and uses libev its event loop. The goal is to
> > be small, fast, and language independent server that can host web
> > frameworks. I have written a small Ruby binding which provides a Rack
> > handler - this will allow Ebb to host Rails, Merb, and other Ruby
> > frameworks. In the future I will write a Python WSGI binding.
> >
> > The design is similar to the evented Mongrel web server. Connections
> > are processed as follows:
> >
> > 1. libev loops and waits for incoming connections.
> > 2. When Ebb can read from a client socket, it passes the buffer into
> > the
> >   mongrel state machine which parses the headers into name value
> > pairs.
> > 3. Ebb starts a new thread and passes the request information and
> > peer socket
> >   to a user supplied callback. The thread lasts only for the length
> > of that
> >   callback.
> > 4. The included Ruby binding, supplying this callback transforms the
> > request
> >   into a Rack compatible "env" variable and passes it on a Rack
> > adapter.
> >
> > The code measures in at less than 1000 lines of C code.
> >
> > There is much work to do; it is not ready for use. I am soliciting
> > help from the community for testing and development. You may browse
> > the git repository at http://repo.or.cz/w/ebb.git or check out the
> > code with this command:
> > git clone git://repo.or.cz/ebb.git
> > I release Ebb under the MIT license.
> > It is very fun to program Ebb so I suggest you do too :)
> >
> >
> > Ry Dahl
>
> Hey Ry-
>
>         Is glib-2.0 a dependency? It seems like 2.0 is an old version of
> glib. So ebb doesn't compile on leopard out of the box. What do I need
> to install to make it work?
>
> ~/ebb > make
> gcc -g -Wall `pkg-config --cflags glib-2.0` -I/opt/libev-2.01/include -
> L/opt/libev-2.01/lib -c tcp.c -o tcp.o
> Package glib-2.0 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `glib-2.0.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'glib-2.0' found
> tcp.c:18:16: error: ev.h: No such file or directory
> tcp.c:19:18: error: glib.h: No such file or directory
> In file included from tcp.c:23:
> tcp.h:48: error: syntax error before 'GQueue'
> tcp.h:48: warning: no semicolon at end of struct or union
> tcp.h:53: error: syntax error before '*' token
> tcp.h:53: warning: type defaults to 'int' in declaration of
> 'accept_watcher'
> tcp.h:53: warning: data definition has no type or storage class
> tcp.h:55: error: syntax error before '}' token
> tcp.h:72: error: syntax error before 'ev_io'
> tcp.h:72: warning: no semicolon at end of struct or union
> tcp.c: In function 'tcp_client_write':
> tcp.c:33: error: dereferencing pointer to incomplete type
> tcp.c:34: error: dereferencing pointer to incomplete type
> tcp.c:36: warning: implicit declaration of function 'g_log'
> tcp.c:36: error: 'G_LOG_LEVEL_ERROR' undeclared (first use in this
> function)
> tcp.c:36: error: (Each undeclared identifier is reported only once
> tcp.c:36: error: for each function it appears in.)
> tcp.c: At top level:
> tcp.c:46: warning: 'struct ev_io' declared inside parameter list
> tcp.c:46: warning: its scope is only this definition or declaration,
> which is probably not what you want
> tcp.c: In function 'tcp_client_on_readable':
> tcp.c:48: error: dereferencing pointer to incomplete type
> tcp.c:52: error: 'EV_ERROR' undeclared (first use in this function)
> tcp.c:53: error: 'G_LOG_LEVEL_ERROR' undeclared (first use in this
> function)
> tcp.c:57: error: dereferencing pointer to incomplete type
> tcp.c:58: error: dereferencing pointer to incomplete type
> tcp.c:59: error: dereferencing pointer to incomplete type
> tcp.c:60: error: dereferencing pointer to incomplete type
> tcp.c:62: error: dereferencing pointer to incomplete type
> tcp.c:64: error: dereferencing pointer to incomplete type
> tcp.c:64: error: dereferencing pointer to incomplete type
> tcp.c:67: warning: implicit declaration of function 'g_debug'
> tcp.c:81: error: dereferencing pointer to incomplete type
> tcp.c:81: error: dereferencing pointer to incomplete type
> tcp.c:81: error: dereferencing pointer to incomplete type
> tcp.c: In function 'tcp_client_new':
> tcp.c:95: warning: implicit declaration of function 'g_new0'
> tcp.c:95: error: syntax error before 'tcp_client'
> tcp.c:97: error: dereferencing pointer to incomplete type
> tcp.c:99: error: dereferencing pointer to incomplete type
> tcp.c:99: error: dereferencing pointer to incomplete type
> tcp.c:99: error: dereferencing pointer to incomplete type
> tcp.c:100: error: dereferencing pointer to incomplete type
> tcp.c:101: error: 'G_LOG_LEVEL_ERROR' undeclared (first use in this
> function)
> tcp.c:105: error: dereferencing pointer to incomplete type
> tcp.c:105: error: 'TRUE' undeclared (first use in this function)
> tcp.c:107: error: dereferencing pointer to incomplete type
> tcp.c:113: error: dereferencing pointer to incomplete type
> tcp.c:115: error: dereferencing pointer to incomplete type
> tcp.c:115: error: syntax error before 'struct'
> tcp.c:116: error: dereferencing pointer to incomplete type
> tcp.c:117: warning: implicit declaration of function 'ev_init'
> tcp.c:117: error: dereferencing pointer to incomplete type
> tcp.c:118: warning: implicit declaration of function 'ev_io_set'
> tcp.c:118: error: dereferencing pointer to incomplete type
> tcp.c:118: error: dereferencing pointer to incomplete type
> tcp.c:118: error: 'EV_READ' undeclared (first use in this function)
> tcp.c:118: error: 'EV_ERROR' undeclared (first use in this function)
> tcp.c:119: warning: implicit declaration of function 'ev_io_start'
> tcp.c:119: error: dereferencing pointer to incomplete type
> tcp.c:119: error: dereferencing pointer to incomplete type
> tcp.c: In function 'tcp_client_stop_read_watcher':
> tcp.c:131: error: dereferencing pointer to incomplete type
> tcp.c:134: error: dereferencing pointer to incomplete type
> tcp.c:136: warning: implicit declaration of function 'ev_io_stop'
> tcp.c:136: error: dereferencing pointer to incomplete type
> tcp.c:136: error: dereferencing pointer to incomplete type
> tcp.c:137: error: dereferencing pointer to incomplete type
> tcp.c:138: error: dereferencing pointer to incomplete type
> tcp.c: In function 'tcp_client_free':
> tcp.c:146: error: dereferencing pointer to incomplete type
> tcp.c: In function 'tcp_client_close':
> tcp.c:153: error: dereferencing pointer to incomplete type
> tcp.c:155: error: dereferencing pointer to incomplete type
> tcp.c:156: error: dereferencing pointer to incomplete type
> tcp.c:156: error: 'FALSE' undeclared (first use in this function)
> tcp.c: In function 'tcp_server_new':
> tcp.c:165: error: syntax error before 'tcp_server'
> tcp.c:167: error: dereferencing pointer to incomplete type
> tcp.c:168: error: dereferencing pointer to incomplete type
> tcp.c:170: error: 'G_LOG_LEVEL_ERROR' undeclared (first use in this
> function)
> tcp.c:175: error: dereferencing pointer to incomplete type
> tcp.c:189: error: dereferencing pointer to incomplete type
> tcp.c:189: warning: implicit declaration of function 'ev_loop_new'
> tcp.c:191: error: dereferencing pointer to incomplete type
> tcp.c:191: warning: implicit declaration of function 'g_queue_new'
> tcp.c:192: error: dereferencing pointer to incomplete type
> tcp.c:192: error: 'FALSE' undeclared (first use in this function)
> tcp.c: In function 'tcp_server_free':
> tcp.c:203: warning: implicit declaration of function 'g_queue_free'
> tcp.c:203: error: dereferencing pointer to incomplete type
> tcp.c: In function 'tcp_server_close':
> tcp.c:211: error: dereferencing pointer to incomplete type
> tcp.c:214: warning: implicit declaration of function 'g_queue_pop_head'
> tcp.c:214: error: dereferencing pointer to incomplete type
> tcp.c:214: warning: assignment makes pointer from integer without a cast
> tcp.c:217: error: dereferencing pointer to incomplete type
> tcp.c:218: error: dereferencing pointer to incomplete type
> tcp.c:219: error: dereferencing pointer to incomplete type
> tcp.c:221: error: dereferencing pointer to incomplete type
> tcp.c:222: error: dereferencing pointer to incomplete type
> tcp.c:223: error: dereferencing pointer to incomplete type
> tcp.c:225: error: dereferencing pointer to incomplete type
> tcp.c:227: error: dereferencing pointer to incomplete type
> tcp.c:227: error: dereferencing pointer to incomplete type
> tcp.c:228: error: dereferencing pointer to incomplete type
> tcp.c:229: error: dereferencing pointer to incomplete type
> tcp.c:231: warning: implicit declaration of function 'ev_unloop'
> tcp.c:231: error: dereferencing pointer to incomplete type
> tcp.c:231: error: 'EVUNLOOP_ALL' undeclared (first use in this function)
> tcp.c:232: warning: implicit declaration of function 'ev_loop_destroy'
> tcp.c:232: error: dereferencing pointer to incomplete type
> tcp.c:233: error: dereferencing pointer to incomplete type
> tcp.c:235: error: dereferencing pointer to incomplete type
> tcp.c:236: error: dereferencing pointer to incomplete type
> tcp.c:236: error: 'FALSE' undeclared (first use in this function)
> tcp.c: At top level:
> tcp.c:242: warning: 'struct ev_io' declared inside parameter list
> tcp.c: In function 'tcp_server_accept':
> tcp.c:244: error: dereferencing pointer to incomplete type
> tcp.c:247: error: dereferencing pointer to incomplete type
> tcp.c:248: error: dereferencing pointer to incomplete type
> tcp.c:251: error: 'EV_ERROR' undeclared (first use in this function)
> tcp.c:252: error: 'G_LOG_LEVEL_ERROR' undeclared (first use in this
> function)
> tcp.c:258: warning: implicit declaration of function 'g_queue_push_head'
> tcp.c:258: error: dereferencing pointer to incomplete type
> tcp.c:258: error: 'gpointer' undeclared (first use in this function)
> tcp.c:258: error: syntax error before 'client'
> tcp.c:260: error: dereferencing pointer to incomplete type
> tcp.c:261: error: dereferencing pointer to incomplete type
> tcp.c:261: error: dereferencing pointer to incomplete type
> tcp.c: In function 'tcp_server_listen':
> tcp.c:276: error: dereferencing pointer to incomplete type
> tcp.c:277: error: dereferencing pointer to incomplete type
> tcp.c:280: error: dereferencing pointer to incomplete type
> tcp.c:281: error: dereferencing pointer to incomplete type
> tcp.c:283: error: dereferencing pointer to incomplete type
> tcp.c:284: error: dereferencing pointer to incomplete type
> tcp.c:284: error: dereferencing pointer to incomplete type
> tcp.c:285: error: 'G_LOG_LEVEL_ERROR' undeclared (first use in this
> function)
> tcp.c:288: error: dereferencing pointer to incomplete type
> tcp.c:288: error: dereferencing pointer to incomplete type
> tcp.c:298: error: dereferencing pointer to incomplete type
> tcp.c:298: error: dereferencing pointer to incomplete type
> tcp.c:298: error: dereferencing pointer to incomplete type
> tcp.c:304: error: dereferencing pointer to incomplete type
> tcp.c:310: error: dereferencing pointer to incomplete type
> tcp.c:310: error: 'FALSE' undeclared (first use in this function)
> tcp.c:311: error: dereferencing pointer to incomplete type
> tcp.c:311: error: 'TRUE' undeclared (first use in this function)
> tcp.c:313: error: dereferencing pointer to incomplete type
> tcp.c:313: error: syntax error before 'struct'
> tcp.c:314: error: dereferencing pointer to incomplete type
> tcp.c:315: error: dereferencing pointer to incomplete type
> tcp.c:316: error: dereferencing pointer to incomplete type
> tcp.c:318: error: dereferencing pointer to incomplete type
> tcp.c:319: error: dereferencing pointer to incomplete type
> tcp.c:319: error: dereferencing pointer to incomplete type
> tcp.c:319: error: 'EV_READ' undeclared (first use in this function)
> tcp.c:319: error: 'EV_ERROR' undeclared (first use in this function)
> tcp.c:320: error: dereferencing pointer to incomplete type
> tcp.c:320: error: dereferencing pointer to incomplete type
> tcp.c:321: warning: implicit declaration of function 'ev_loop'
> tcp.c:321: error: dereferencing pointer to incomplete type
> tcp.c: In function 'tcp_server_address':
> tcp.c:331: error: dereferencing pointer to incomplete type
> tcp.c:332: error: dereferencing pointer to incomplete type
> tcp.c:335: warning: control reaches end of non-void function
> make: *** [tcp.o] Error 1
>
>
> Thanks
>
>
> - Ezra Zygmuntowicz
> -- Founder & Software Architect
> -- ezra at engineyard.com
> -- EngineYard.com
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From kevwil at gmail.com  Mon Jan 14 17:09:36 2008
From: kevwil at gmail.com (Kevin Williams)
Date: Mon, 14 Jan 2008 15:09:36 -0700
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <71166b3b0801141250tbb7b06ya2cc55147b1b8c67@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<71166b3b0801140916m1808f5c5jd43457e07ff80140@mail.gmail.com>
	<3ae7f4480801141056j32f7b657m84e5bd72a09be33e@mail.gmail.com>
	<71166b3b0801141250tbb7b06ya2cc55147b1b8c67@mail.gmail.com>
Message-ID: <683a886f0801141409n3a396f53jcfcb0da626c4b2c4@mail.gmail.com>

An alternative might be github.com. It looks like they provide svn
mirrors of your git repos.

On Jan 14, 2008 1:50 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Jan 14, 2008 4:56 PM, ry dahl <ry at tinyclouds.org> wrote:
> > > A svn repo clone? (git-svn)? Not all jumped into the git bandwagon :-)
> >
> > Sorry - my hosting abilities are limited. I also find the multitude of
> > revision control software annoying (but git seems functional!)
> > apt-get install git
> >
>
> no apt-get on Windows. And git support on it is a bit flacky
> (I hear another git versus *nix versus windows discussion starting).
>
> I'm on Bazaar, which is the same used by Ubuntu :-)
>
> http://bazaar-vcs.org/BzrVsGit
>
> Anyway, have git but not on my Windows box.
>
> Will check your code this weekend ;-)
>
> --
> Luis Lavena
> Multimedia systems
> -
> A common mistake that people make when trying to design
> something completely foolproof is to underestimate
> the ingenuity of complete fools.
> Douglas Adams
> _______________________________________________
>
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Cheers,

Kevin Williams
http://www.bantamtech.com/

From zedshaw at zedshaw.com  Mon Jan 14 19:50:48 2008
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 14 Jan 2008 19:50:48 -0500
Subject: [Mongrel] Reading HTTP Request parameters
In-Reply-To: <0925604640c4decff76dbfe3babfb8e1@ruby-forum.com>
References: <2f66c268efd1462a64ab821c5e14668d@ruby-forum.com>
	<1dd361e10801140231r3f2db151tca2273a9b55826fc@mail.gmail.com>
	<0925604640c4decff76dbfe3babfb8e1@ruby-forum.com>
Message-ID: <20080114195048.8cc4d7fd.zedshaw@zedshaw.com>

On Mon, 14 Jan 2008 15:39:25 +0100
"Abir B." <lists at ruby-forum.com> wrote:

> Eden Li wrote:
> > HttpRequest.query_parse(@params.http_body)
> > 
> > http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpRequest.html#M000126
> 
> :-)
> that's just what I'm searching (I tried it with a wrong syntax : 
> req.query_parse and it didn't work...)

Yes, sadly you have to do this yourself because all the frameworks have
their own interpretation of how the query parameters are parsed.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From lists at ruby-forum.com  Wed Jan 16 18:38:59 2008
From: lists at ruby-forum.com (Brett Eisenberg)
Date: Thu, 17 Jan 2008 00:38:59 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <12E63B8C-8166-470E-9BFD-D48EB552DBAA@gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<12E63B8C-8166-470E-9BFD-D48EB552DBAA@gmail.com>
Message-ID: <1c7052b2f98b8226b013b24dc05f11d5@ruby-forum.com>

Ezra,

libev will be in MacPorts later tonight or tomorrow, and with glib2
installed, Ebb builds cleanly on Leopard.

best,
Brett

Ezra Zygmuntowicz wrote:
> On Jan 14, 2008, at 8:43 AM, ry dahl wrote:

> Hey Ry-
> 
>   Is glib-2.0 a dependency? It seems like 2.0 is an old version of
> glib. So ebb doesn't compile on leopard out of the box. What do I need
> to install to make it work?
> 
> <snip>
> 
> Thanks
> 
> 
> - Ezra Zygmuntowicz
> -- Founder & Software Architect
> -- ezra at engineyard.com
> -- EngineYard.com
-- 
Posted via http://www.ruby-forum.com/.

From jalmberg at identry.com  Thu Jan 17 09:44:23 2008
From: jalmberg at identry.com (John Almberg)
Date: Thu, 17 Jan 2008 09:44:23 -0500
Subject: [Mongrel] Apache22+mod_proxy+mongrel+ssl
Message-ID: <8D2745F3-7BA8-42E1-A5D4-B0A0E770EC4F@identry.com>

I am trying to move a Rails application, that uses SSL, from an  
Apache/FastCGI stack, that works fine, to Apache22 and mongrel  
working with a single mongrel instance (i.e., not mongrel cluster, yet.)

I have a single mongrel instance demonized and working fine on http,  
on port 3000. Apache/OpenSSL/certs working fine.

Here is my test http.conf (deliberately kept as simple as possible):

<VirtualHost 69.1.254.101:80>
   ServerName new.identry.com
   ErrorLog "/var/log/www/new.identry.com-error.log"
   CustomLog "/var/log/www/new.identry.com-access.log" combined

   #DocumentRoot "/home/identry/public_html"
   ProxyPass / http://new.identry.com:3000/
   ProxyPassReverse / http://new.identry.com:3000/
   ProxyPreserveHost on
</VirtualHost>

<VirtualHost 69.1.254.101:443>
   ServerName new.identry.com
   ErrorLog "/var/log/www/new.identry.com-error.log"
   CustomLog "/var/log/www/new.identry.com-access.log" combined
   SSLEngine on
   SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW: 
+SSLv2:+EXP:+eNULL
   SSLCertificateKeyFile "/usr/local/etc/apache22/certs/ 
new.identry.com/server.key"
   SSLCertificateFile "/usr/local/etc/apache22/certs/new.identry.com/ 
server.crt"

   #DocumentRoot "/home/identry/public_html"
   RequestHeader set X_FORWARDED_PROTO 'https'
   ProxyPass / https://new.identry.com:3000/
   ProxyPassReverse / https://new.identry.com:3000/
   ProxyPreserveHost on
</VirtualHost>

The two commented-out DocumentRoot lines let me test the Apache SSL  
config with static content. If I use the DocumentRoot lines instead  
of the Proxy lines, then Apache serves up the static test content  
with both http and https addresses, no problem. So I believe Apache/ 
SSL is working fine.

Furthermore, using the configuration as written above, the http  
connection to mongrel (and the Rails app behind it) also works fine.  
So a the plain Apache/mod_proxy/mongrel/Rails stack also seems to be  
working fine.

What I'm having trouble with is the Apache/SSL/mod_proxy/mongrel/ 
Rails stack. If I try to reach the site with https://new.identry.com,  
I get the following error in the mongrel.log:

Thu Jan 17 09:10:57 -0500 2008: HTTP parse error, malformed request  
(75.127.142.66): #<Mongrel::HttpParserError: Invalid HTTP format,  
parsing fails.>
Thu Jan 17 09:10:57 -0500 2008: REQUEST DATA: "\200=\001\003\000\000$ 
\000\000\000\020\000\0009\000\0008\000\0005\000\0003\000\0002\000\000 
\004\000\000\005\000\000/\000\000\026\000\000\023\000\376\377\000\000 
\n\243?S\376?????|\255??y"
---
PARAMS: {}
---

I get exactly the same error if I bypass Apache and go to https:// 
new.identry.com:3000.

I am guessing that the above error message is Mongrel choking on  
encrypted data. So, I am guessing that Mongrel simply can't handle an  
https connection. Therefore, redirecting to an https instance is a  
bad idea.

The problem is, if I redirect to an http instance, like so:

<VirtualHost 69.1.254.101:443>
   .. snip ..
	
   RequestHeader set X_FORWARDED_PROTO 'https'
   ProxyPass / http://new.identry.com:3000/
   ProxyPassReverse / http://new.identry.com:3000/
   ProxyPreserveHost on
</VirtualHost>

I don't get a secure connection on the browser. I type https://...  
and get redirected to http://

Obviously I am doing something wrong. I've googled all over the  
place, and can't find a good answer. Any help, much appreciated.

Brgds: John


~


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Websites for On-line Collectible Dealers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Identry, LLC
John Almberg
(631) 546-5079
jalmberg at identry.com
www.identry.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080117/4b552906/attachment-0001.html 

From jalmberg at identry.com  Thu Jan 17 10:43:58 2008
From: jalmberg at identry.com (John Almberg)
Date: Thu, 17 Jan 2008 10:43:58 -0500
Subject: [Mongrel] Apache22+mod_proxy+mongrel+ssl
In-Reply-To: <8D2745F3-7BA8-42E1-A5D4-B0A0E770EC4F@identry.com>
References: <8D2745F3-7BA8-42E1-A5D4-B0A0E770EC4F@identry.com>
Message-ID: <B31D05EE-D807-45C5-ADE7-EA8E0520AFEF@identry.com>

So I just found this in the mongrel FAQ (a good place for it, too!):

Q: Does Mongrel have SSL?
	No, having a Ruby web server do complex SSL cryptography is stupid  
when you can get any of the major web servers to do it faster.
Q: Why are Apache & SSL ? Redirects going to http:// not https://?
	Basically, you need to pass in a header so Rails knows what to do.  
Read the bottom of the Apache Documentation for instructions on how  
to do this.

So I guess the correct approach is to redirect to http:// 
address.of.mongrel:3000, and to use the RequestHeader to signal to  
Rails that this is an https request.

Can someone confirm that my understanding is correct?

I'm asking because this config doesn't work for me, yet, but if I'm  
on the right track, I should be able to find the problem eventually.

Thanks: John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080117/26bc952a/attachment.html 

From jalmberg at identry.com  Thu Jan 17 11:04:13 2008
From: jalmberg at identry.com (John Almberg)
Date: Thu, 17 Jan 2008 11:04:13 -0500
Subject: [Mongrel] Apache22+mod_proxy+mongrel+ssl
In-Reply-To: <B31D05EE-D807-45C5-ADE7-EA8E0520AFEF@identry.com>
References: <8D2745F3-7BA8-42E1-A5D4-B0A0E770EC4F@identry.com>
	<B31D05EE-D807-45C5-ADE7-EA8E0520AFEF@identry.com>
Message-ID: <8DABD661-6EAB-4A7F-8761-B8CCCBB2648A@identry.com>

It's amazing how often you figure out a problem, simply by writing it  
down in the form of a question!

Okay! I've got it working. I was actually testing a non-https page,  
so Rails very correctly redirected me back to http. This is one of  
the things that threw me.

When I tried it on an 'ssl_required' page,  it worked fine.

Hopefully these emails will help someone in the future.

Brgds: John


On Jan 17, 2008, at 10:43 AM, John Almberg wrote:

> So I just found this in the mongrel FAQ (a good place for it, too!):
>
> Q: Does Mongrel have SSL?
> 	No, having a Ruby web server do complex SSL cryptography is stupid  
> when you can get any of the major web servers to do it faster.
> Q: Why are Apache & SSL ? Redirects going to http:// not https://?
> 	Basically, you need to pass in a header so Rails knows what to do.  
> Read the bottom of the Apache Documentation for instructions on how  
> to do this.
>
> So I guess the correct approach is to redirect to http:// 
> address.of.mongrel:3000, and to use the RequestHeader to signal to  
> Rails that this is an https request.
>
> Can someone confirm that my understanding is correct?
>
> I'm asking because this config doesn't work for me, yet, but if I'm  
> on the right track, I should be able to find the problem eventually.
>
> Thanks: John
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Websites for On-line Collectible Dealers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Identry, LLC
John Almberg
(631) 546-5079
jalmberg at identry.com
www.identry.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080117/8f77795a/attachment.html 

From wayneeseguin at gmail.com  Thu Jan 17 14:48:43 2008
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Thu, 17 Jan 2008 14:48:43 -0500
Subject: [Mongrel] Apache22+mod_proxy+mongrel+ssl
In-Reply-To: <8DABD661-6EAB-4A7F-8761-B8CCCBB2648A@identry.com>
References: <8D2745F3-7BA8-42E1-A5D4-B0A0E770EC4F@identry.com>
	<B31D05EE-D807-45C5-ADE7-EA8E0520AFEF@identry.com>
	<8DABD661-6EAB-4A7F-8761-B8CCCBB2648A@identry.com>
Message-ID: <ef3e5d50801171148q519c0dc5icfe77f3e69685397@mail.gmail.com>

On Jan 17, 2008 11:04 AM, John Almberg <jalmberg at identry.com> wrote:

> It's amazing how often you figure out a problem, simply by writing it down
> in the form of a question!
> Okay! I've got it working. I was actually testing a non-https page, so
> Rails very correctly redirected me back to http. This is one of the things
> that threw me.
>
> When I tried it on an 'ssl_required' page,  it worked fine.
>
> Hopefully these emails will help someone in the future.
>
> Brgds: John
>

Awesome!

  ~Wayne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080117/65ccb45c/attachment.html 

From rust at stnard.jp  Fri Jan 18 04:12:12 2008
From: rust at stnard.jp (rust at stnard.jp)
Date: Fri, 18 Jan 2008 18:12:12 +0900
Subject: [Mongrel] Apache22+mod_proxy+mongrel+ssl
In-Reply-To: <ef3e5d50801171148q519c0dc5icfe77f3e69685397@mail.gmail.com>
References: <8D2745F3-7BA8-42E1-A5D4-B0A0E770EC4F@identry.com>
	<B31D05EE-D807-45C5-ADE7-EA8E0520AFEF@identry.com>
	<8DABD661-6EAB-4A7F-8761-B8CCCBB2648A@identry.com>
	<ef3e5d50801171148q519c0dc5icfe77f3e69685397@mail.gmail.com>
Message-ID: <35cba0410801180112i1050c3a1j7e6283ad1619b6ed@mail.gmail.com>

On 1/18/08, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:
> On Jan 17, 2008 11:04 AM, John Almberg <jalmberg at identry.com> wrote:
>
> > It's amazing how often you figure out a problem, simply by writing it down
> > in the form of a question!
> > Okay! I've got it working. I was actually testing a non-https page, so
> > Rails very correctly redirected me back to http. This is one of the things
> > that threw me.
> >
> > When I tried it on an 'ssl_required' page,  it worked fine.
> >
> > Hopefully these emails will help someone in the future.
> >
> > Brgds: John
> >
>
> Awesome!
>
>   ~Wayne
>


-- 
$B>. at n!!?-0lO:(B ( Shin-ichiro OGAWA )

From wayneeseguin at gmail.com  Fri Jan 18 14:59:56 2008
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Fri, 18 Jan 2008 14:59:56 -0500
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
Message-ID: <ef3e5d50801181159y754a512yb6e1793f85f73d1b@mail.gmail.com>

On Jan 14, 2008 11:43 AM, ry dahl <ry at tinyclouds.org> wrote:

> Hello Mongrel Users,
>
> I'm writing a web server called Ebb. It's written in C, makes use of
> the Mongrel HTTP parser, and uses libev its event loop. The goal is to
> be small, fast, and language independent server that can host web
> frameworks. I have written a small Ruby binding which provides a Rack
> handler - this will allow Ebb to host Rails, Merb, and other Ruby
> frameworks. In the future I will write a Python WSGI binding.
>
> The design is similar to the evented Mongrel web server. Connections
> are processed as follows:
>
> 1. libev loops and waits for incoming connections.
> 2. When Ebb can read from a client socket, it passes the buffer into the
>   mongrel state machine which parses the headers into name value pairs.
> 3. Ebb starts a new thread and passes the request information and peer
> socket
>   to a user supplied callback. The thread lasts only for the length of
> that
>   callback.
> 4. The included Ruby binding, supplying this callback transforms the
> request
>   into a Rack compatible "env" variable and passes it on a Rack adapter.
>
> The code measures in at less than 1000 lines of C code.
>
> There is much work to do; it is not ready for use. I am soliciting
> help from the community for testing and development. You may browse
> the git repository at http://repo.or.cz/w/ebb.git or check out the
> code with this command:
> git clone git://repo.or.cz/ebb.git
> I release Ebb under the MIT license.
> It is very fun to program Ebb so I suggest you do too :)
>
>
> Ry Dahl
>
Ry,

Awesome, great idea!

I will definitely be checking this out hopefully this weekend

  ~Wayne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080118/16af0520/attachment.html 

From johnjosephbachir at gmail.com  Mon Jan 21 14:05:16 2008
From: johnjosephbachir at gmail.com (John Joseph Bachir)
Date: Mon, 21 Jan 2008 14:05:16 -0500
Subject: [Mongrel] properly restarting mongrel instances
Message-ID: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>

Hi folks.

Using mongrel_rails and the mongrel_cluster capistrano recipes, I
often encounter a situation where some of the mongrel processes don't
die in time to be restarted. The output of capistrano will tell me
something like "mongrel on port 8001 is already up", but that's only
because capistrano/mongrel_rails failed to take it down in the first
place.

The solution is to do a full deploy:stop a couple times to make sure
they are all down, and then do a deploy:start.

Is my problem typical? Is there a solution? Seems like mongrel_rails
and/or the capistrano recipes should wait for the processes to stop
before attempting to restart them.

Thanks for any insight,
John


-- 
John Joseph Bachir
http://blog.johnjosephbachir.org
http://lyceum.ibiblio.org
http://dissent.cc
http://jjb.cc

From ry at tinyclouds.org  Mon Jan 21 15:34:22 2008
From: ry at tinyclouds.org (ry dahl)
Date: Mon, 21 Jan 2008 21:34:22 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
Message-ID: <3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>

Hey All,

Just one more quick message to entice contributors to take a look at
Ebb. I was able to run some preliminary benchmarks for the first time
today against evented Mongrel and Thin. They're all running a small
Camping application through Rack.

http://s3.amazonaws.com/four.livejournal/20080121/ebb.png

The code for that benchmark (and chart generation) can be found in the Ebb repo:
http://repo.or.cz/w/ebb.git?a=commit;h=c2fecde0a04603727949ec0b05d694be89a464d2

ry

On Jan 14, 2008 5:43 PM, ry dahl <ry at tinyclouds.org> wrote:
> Hello Mongrel Users,
>
> I'm writing a web server called Ebb. It's written in C, makes use of
> the Mongrel HTTP parser, and uses libev its event loop. The goal is to
> be small, fast, and language independent server that can host web
> frameworks. I have written a small Ruby binding which provides a Rack
> handler - this will allow Ebb to host Rails, Merb, and other Ruby
> frameworks. In the future I will write a Python WSGI binding.
>
> The design is similar to the evented Mongrel web server. Connections
> are processed as follows:
>
> 1. libev loops and waits for incoming connections.
> 2. When Ebb can read from a client socket, it passes the buffer into the
>    mongrel state machine which parses the headers into name value pairs.
> 3. Ebb starts a new thread and passes the request information and peer socket
>    to a user supplied callback. The thread lasts only for the length of that
>    callback.
> 4. The included Ruby binding, supplying this callback transforms the request
>    into a Rack compatible "env" variable and passes it on a Rack adapter.
>
> The code measures in at less than 1000 lines of C code.
>
> There is much work to do; it is not ready for use. I am soliciting
> help from the community for testing and development. You may browse
> the git repository at http://repo.or.cz/w/ebb.git or check out the
> code with this command:
> git clone git://repo.or.cz/ebb.git
> I release Ebb under the MIT license.
> It is very fun to program Ebb so I suggest you do too :)
>
>
> Ry Dahl
>

From luislavena at gmail.com  Mon Jan 21 15:55:53 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 21 Jan 2008 18:55:53 -0200
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
Message-ID: <71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>

On Jan 21, 2008 6:34 PM, ry dahl <ry at tinyclouds.org> wrote:
> Hey All,
>
> Just one more quick message to entice contributors to take a look at
> Ebb. I was able to run some preliminary benchmarks for the first time
> today against evented Mongrel and Thin. They're all running a small
> Camping application through Rack.
>
> http://s3.amazonaws.com/four.livejournal/20080121/ebb.png
>

Hey ry, did you tweaked the HttpParser like Thin guy did?

I was thinking about the modifications he did:

He removed all the if conditions evaluating http_field,
request_method, request_uri and others (most the ones that are
allocated/initialized in HttpParser_alloc).

But since I couldn't find time to ask it in a separate mail, is time
that boost the question using your thread ;-)

> The code for that benchmark (and chart generation) can be found in the Ebb repo:
> http://repo.or.cz/w/ebb.git?a=commit;h=c2fecde0a04603727949ec0b05d694be89a464d2

svn mirror is coming, right? :-D

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From kevwil at gmail.com  Mon Jan 21 16:00:40 2008
From: kevwil at gmail.com (Kevin Williams)
Date: Mon, 21 Jan 2008 14:00:40 -0700
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
Message-ID: <683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>

On Jan 21, 2008 1:55 PM, Luis Lavena <luislavena at gmail.com> wrote:
> Hey ry, did you tweaked the HttpParser like Thin guy did?
>
> I was thinking about the modifications he did:
>
> He removed all the if conditions evaluating http_field,
> request_method, request_uri and others (most the ones that are
> allocated/initialized in HttpParser_alloc).

I don't think those conditions were *removed*, I think they were
*moved*, but I've only glanced at the C code and would barely know
what I was looking at anyway. :)


-- 
Cheers,

Kevin Williams
http://www.bantamtech.com/
http://www.almostserio.us/
http://kevwil.com/

From luislavena at gmail.com  Mon Jan 21 16:12:06 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 21 Jan 2008 19:12:06 -0200
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
	<683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>
Message-ID: <71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>

On Jan 21, 2008 7:00 PM, Kevin Williams <kevwil at gmail.com> wrote:
> On Jan 21, 2008 1:55 PM, Luis Lavena <luislavena at gmail.com> wrote:
> > Hey ry, did you tweaked the HttpParser like Thin guy did?
> >
> > I was thinking about the modifications he did:
> >
> > He removed all the if conditions evaluating http_field,
> > request_method, request_uri and others (most the ones that are
> > allocated/initialized in HttpParser_alloc).
>
> I don't think those conditions were *removed*, I think they were
> *moved*, but I've only glanced at the C code and would barely know
> what I was looking at anyway. :)

No, he removed them:

http://pastie.caboo.se/141633

The ragel code will generate the http11_parser.c file, and http11.c
file defines all the functions pointers:

http11.c:207..225:

VALUE HttpParser_alloc(VALUE klass)
{
  VALUE obj;
  http_parser *hp = ALLOC_N(http_parser, 1);
  TRACE();
  hp->http_field = http_field;
  hp->request_method = request_method;
  hp->request_uri = request_uri;
  hp->fragment = fragment;
  hp->request_path = request_path;
  hp->query_string = query_string;
  hp->http_version = http_version;
  hp->header_done = header_done;
  http_parser_init(hp);

  obj = Data_Wrap_Struct(klass, NULL, HttpParser_free, hp);

  return obj;
}

Theory indicates that allocation happens way before the ragel code is
getting executed, so there is no need to evaluate the conditions all
the time, ending with a speed boost.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From macournoyer at gmail.com  Mon Jan 21 16:22:03 2008
From: macournoyer at gmail.com (=?ISO-8859-1?Q?Marc-Andr=E9_Cournoyer?=)
Date: Mon, 21 Jan 2008 16:22:03 -0500
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
	<683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>
	<71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>
Message-ID: <DB9A9778-5E6A-43DE-8354-A6AB3CC54F02@gmail.com>

yes I removed those conditions and looks like Ry did the same (by  
looking quickly at his code).

On 21-Jan-08, at 4:12 PM, Luis Lavena wrote:

> On Jan 21, 2008 7:00 PM, Kevin Williams <kevwil at gmail.com> wrote:
>> On Jan 21, 2008 1:55 PM, Luis Lavena <luislavena at gmail.com> wrote:
>>> Hey ry, did you tweaked the HttpParser like Thin guy did?
>>>
>>> I was thinking about the modifications he did:
>>>
>>> He removed all the if conditions evaluating http_field,
>>> request_method, request_uri and others (most the ones that are
>>> allocated/initialized in HttpParser_alloc).
>>
>> I don't think those conditions were *removed*, I think they were
>> *moved*, but I've only glanced at the C code and would barely know
>> what I was looking at anyway. :)
>
> No, he removed them:
>
> http://pastie.caboo.se/141633
>
> The ragel code will generate the http11_parser.c file, and http11.c
> file defines all the functions pointers:
>
> http11.c:207..225:
>
> VALUE HttpParser_alloc(VALUE klass)
> {
>  VALUE obj;
>  http_parser *hp = ALLOC_N(http_parser, 1);
>  TRACE();
>  hp->http_field = http_field;
>  hp->request_method = request_method;
>  hp->request_uri = request_uri;
>  hp->fragment = fragment;
>  hp->request_path = request_path;
>  hp->query_string = query_string;
>  hp->http_version = http_version;
>  hp->header_done = header_done;
>  http_parser_init(hp);
>
>  obj = Data_Wrap_Struct(klass, NULL, HttpParser_free, hp);
>
>  return obj;
> }
>
> Theory indicates that allocation happens way before the ragel code is
> getting executed, so there is no need to evaluate the conditions all
> the time, ending with a speed boost.
>
> -- 
> Luis Lavena
> Multimedia systems
> -
> A common mistake that people make when trying to design
> something completely foolproof is to underestimate
> the ingenuity of complete fools.
> Douglas Adams
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From ry at tinyclouds.org  Mon Jan 21 16:38:25 2008
From: ry at tinyclouds.org (ry dahl)
Date: Mon, 21 Jan 2008 22:38:25 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <DB9A9778-5E6A-43DE-8354-A6AB3CC54F02@gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
	<683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>
	<71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>
	<DB9A9778-5E6A-43DE-8354-A6AB3CC54F02@gmail.com>
Message-ID: <3ae7f4480801211338o5ca37048hd48a255cb6f5ae13@mail.gmail.com>

I didn't know about those mods. I pulled the parser code from Thin.

ry

From ry at tinyclouds.org  Mon Jan 21 16:46:52 2008
From: ry at tinyclouds.org (ry dahl)
Date: Mon, 21 Jan 2008 22:46:52 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
Message-ID: <3ae7f4480801211346y4e4e50pb6b2397677fef2c6@mail.gmail.com>

> svn mirror is coming, right? :-D

Hi Luis,

I'll put it on github when they open (or another service?) Apparently
their svn bridge isn't fully functional yet.

ry

From luislavena at gmail.com  Mon Jan 21 16:49:56 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 21 Jan 2008 19:49:56 -0200
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801211346y4e4e50pb6b2397677fef2c6@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
	<3ae7f4480801211346y4e4e50pb6b2397677fef2c6@mail.gmail.com>
Message-ID: <71166b3b0801211349t45f7f492i332275e42977870c@mail.gmail.com>

On Jan 21, 2008 7:46 PM, ry dahl <ry at tinyclouds.org> wrote:
> > svn mirror is coming, right? :-D
>
> Hi Luis,
>
> I'll put it on github when they open (or another service?) Apparently
> their svn bridge isn't fully functional yet.

What you can do is ask for a rubyforge project and use the svn
available there as mirror.

I'm still waiting to get bzr-git with write support so I can use
bazaar all the way :-)

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From zedshaw at zedshaw.com  Mon Jan 21 16:58:25 2008
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 21 Jan 2008 16:58:25 -0500
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
Message-ID: <20080121165825.c84cb82f.zedshaw@zedshaw.com>

On Mon, 21 Jan 2008 21:34:22 +0100
"ry dahl" <ry at tinyclouds.org> wrote:

> Hey All,
> 
> Just one more quick message to entice contributors to take a look at
> Ebb. I was able to run some preliminary benchmarks for the first time
> today against evented Mongrel and Thin. They're all running a small
> Camping application through Rack.
> 
> http://s3.amazonaws.com/four.livejournal/20080121/ebb.png
> 
> The code for that benchmark (and chart generation) can be found in the Ebb repo:
> http://repo.or.cz/w/ebb.git?a=commit;h=c2fecde0a04603727949ec0b05d694be89a464d2

Grrrr, you need a Y axis Ry.  What is that measuring.  Hell, shoot me
the raw data and I'll do the graph with R (since I'm curious).

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From zedshaw at zedshaw.com  Mon Jan 21 17:06:43 2008
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 21 Jan 2008 17:06:43 -0500
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
	<683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>
	<71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>
Message-ID: <20080121170643.50253130.zedshaw@zedshaw.com>

On Mon, 21 Jan 2008 19:12:06 -0200
"Luis Lavena" <luislavena at gmail.com> wrote:

> No, he removed them:
> 
> http://pastie.caboo.se/141633
> 
> The ragel code will generate the http11_parser.c file, and http11.c
> file defines all the functions pointers:
<snip> 
> Theory indicates that allocation happens way before the ragel code is
> getting executed, so there is no need to evaluate the conditions all
> the time, ending with a speed boost.

That's bullshit.  All of those tests are simple checks to make sure
that you aren't passing in NULL pointers (which happens when the lib is
used generally).  Removing those would be a tiny little impact on the
performance since they're written in raw C.  Only reason that'd speed
things up is if the compiler wasn't doing its job right (which is
possible).

It's also a performance *loss* in that a user of the library has to set
all callbacks always (or get a crash) and then every function is called
even if a user of the lib only cares about a particular piece.

Also, what's happened is now the safety checks against invalid input
are gone too.  Any of those actions could fire in the parser section
and if those variables are not set then the whole program will eat it
bad.

That's a very bad design change, and now I wish I'd gone to the dude's
demonstration so I could tell him.

If someone wanted to optimize this just for the case where every
function is used and always set, but not lose safety then they should
change the constructor to the library to require those functions always
be set.  Then you could remove the if-statements.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From macournoyer at gmail.com  Mon Jan 21 17:08:05 2008
From: macournoyer at gmail.com (=?ISO-8859-1?Q?Marc-Andr=E9_Cournoyer?=)
Date: Mon, 21 Jan 2008 17:08:05 -0500
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <20080121170643.50253130.zedshaw@zedshaw.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
	<683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>
	<71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>
	<20080121170643.50253130.zedshaw@zedshaw.com>
Message-ID: <D56CB9F7-FDC1-4E54-B6B0-8B3A11FA4AA0@gmail.com>

thx for the pointer, I'll change the constructor then

On 21-Jan-08, at 5:06 PM, Zed A. Shaw wrote:

> On Mon, 21 Jan 2008 19:12:06 -0200
> "Luis Lavena" <luislavena at gmail.com> wrote:
>
>> No, he removed them:
>>
>> http://pastie.caboo.se/141633
>>
>> The ragel code will generate the http11_parser.c file, and http11.c
>> file defines all the functions pointers:
> <snip>
>> Theory indicates that allocation happens way before the ragel code is
>> getting executed, so there is no need to evaluate the conditions all
>> the time, ending with a speed boost.
>
> That's bullshit.  All of those tests are simple checks to make sure
> that you aren't passing in NULL pointers (which happens when the lib  
> is
> used generally).  Removing those would be a tiny little impact on the
> performance since they're written in raw C.  Only reason that'd speed
> things up is if the compiler wasn't doing its job right (which is
> possible).
>
> It's also a performance *loss* in that a user of the library has to  
> set
> all callbacks always (or get a crash) and then every function is  
> called
> even if a user of the lib only cares about a particular piece.
>
> Also, what's happened is now the safety checks against invalid input
> are gone too.  Any of those actions could fire in the parser section
> and if those variables are not set then the whole program will eat it
> bad.
>
> That's a very bad design change, and now I wish I'd gone to the dude's
> demonstration so I could tell him.
>
> If someone wanted to optimize this just for the case where every
> function is used and always set, but not lose safety then they should
> change the constructor to the library to require those functions  
> always
> be set.  Then you could remove the if-statements.
>
> -- 
> Zed A. Shaw
> - Hate: http://savingtheinternetwithhate.com/
> - Good: http://www.zedshaw.com/
> - Evil: http://yearofevil.com/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From luislavena at gmail.com  Mon Jan 21 17:08:46 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 21 Jan 2008 20:08:46 -0200
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <20080121170643.50253130.zedshaw@zedshaw.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
	<683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>
	<71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>
	<20080121170643.50253130.zedshaw@zedshaw.com>
Message-ID: <71166b3b0801211408v2be00eees1136ed9f721cc1f7@mail.gmail.com>

On Jan 21, 2008 8:06 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> On Mon, 21 Jan 2008 19:12:06 -0200
> "Luis Lavena" <luislavena at gmail.com> wrote:
>
> > No, he removed them:
> >
> > http://pastie.caboo.se/141633
> >
> > The ragel code will generate the http11_parser.c file, and http11.c
> > file defines all the functions pointers:
> <snip>
> > Theory indicates that allocation happens way before the ragel code is
> > getting executed, so there is no need to evaluate the conditions all
> > the time, ending with a speed boost.
>
> That's bullshit.  All of those tests are simple checks to make sure
> that you aren't passing in NULL pointers (which happens when the lib is
> used generally).  Removing those would be a tiny little impact on the
> performance since they're written in raw C.  Only reason that'd speed
> things up is if the compiler wasn't doing its job right (which is
> possible).
>

Please Zed, I'm not validating nor arguing against that decision. I
just exposing that, the way I asked on #thin irc channel too a few
weeks back.

> It's also a performance *loss* in that a user of the library has to set
> all callbacks always (or get a crash) and then every function is called
> even if a user of the lib only cares about a particular piece.
>

That's why I was wondering, but still couldn't run my own series of
tests to see how that change impact on overall performance.

> Also, what's happened is now the safety checks against invalid input
> are gone too.  Any of those actions could fire in the parser section
> and if those variables are not set then the whole program will eat it
> bad.
>
> That's a very bad design change, and now I wish I'd gone to the dude's
> demonstration so I could tell him.
>
> If someone wanted to optimize this just for the case where every
> function is used and always set, but not lose safety then they should
> change the constructor to the library to require those functions always
> be set.  Then you could remove the if-statements.
>

Good point. Still, prove of performance improvement must me shown, but
there also corner cases that exposes situations like you mention.

Again: I'm just exposing the situation, that's why the "in theory"...
I'm not validating anything :-)

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From ry at tinyclouds.org  Mon Jan 21 17:11:11 2008
From: ry at tinyclouds.org (ry dahl)
Date: Mon, 21 Jan 2008 23:11:11 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <20080121165825.c84cb82f.zedshaw@zedshaw.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<20080121165825.c84cb82f.zedshaw@zedshaw.com>
Message-ID: <3ae7f4480801211411y312cc064y165e18fac34b2387@mail.gmail.com>

> Grrrr, you need a Y axis Ry.  What is that measuring.  Hell, shoot me
> the raw data and I'll do the graph with R (since I'm curious).

The vertical axis is requests/sec (says at the top of the graph). I
don't bother to give actual numbers because it's only to demonstrate
the relative increase in speed. You can generate your own data with
the script in ruby_bridge/benchmark/test_camping.rb

ry

From dave at cheney.net  Mon Jan 21 18:25:00 2008
From: dave at cheney.net (Dave Cheney)
Date: Tue, 22 Jan 2008 10:25:00 +1100
Subject: [Mongrel] properly restarting mongrel instances
In-Reply-To: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
Message-ID: <6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>

We run into this problem a lot as well. The problem can be exacerbated  
when a mongrel has a backlog of work, or has bloated to a point that  
it is heavily swapped. The mongrels always get the shutdown signal,  
but they don't act on it fast enough to clear their pid file by the  
time the start is actioned.

In our case those mongrels will eventually quit and monit will restart  
them, but its not ideal.

If cluster::restart supported a --delay parameter that would go some  
way to fixing the problem.

Cheers

Dave

On 22/01/2008, at 6:05 AM, John Joseph Bachir wrote:

> Is my problem typical? Is there a solution? Seems like mongrel_rails
> and/or the capistrano recipes should wait for the processes to stop
> before attempting to restart them.


From zedshaw at zedshaw.com  Mon Jan 21 21:53:27 2008
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 21 Jan 2008 21:53:27 -0500
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <71166b3b0801211408v2be00eees1136ed9f721cc1f7@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
	<683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>
	<71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>
	<20080121170643.50253130.zedshaw@zedshaw.com>
	<71166b3b0801211408v2be00eees1136ed9f721cc1f7@mail.gmail.com>
Message-ID: <20080121215327.1f851a8f.zedshaw@zedshaw.com>

On Mon, 21 Jan 2008 20:08:46 -0200
"Luis Lavena" <luislavena at gmail.com> wrote:

> > That's bullshit.  All of those tests are simple checks to make sure
> > that you aren't passing in NULL pointers (which happens when the lib is
> > used generally).  Removing those would be a tiny little impact on the
> > performance since they're written in raw C.  Only reason that'd speed
> > things up is if the compiler wasn't doing its job right (which is
> > possible).
> >
> 
> Please Zed, I'm not validating nor arguing against that decision. I
> just exposing that, the way I asked on #thin irc channel too a few
> weeks back.

Sorry Luis, but I didn't say "Luis, you're a bullshitter."  I said,
"That's bullshit."  Meaning, the claim of a large performance increase
from just removing a series of if-statements isn't worth the loss in
security and safety.

You should know by now that if I *really* wanted to be mean to you I'd
say it directly to you.  I'm talking about the code, nobody directly or
their personalities.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From luislavena at gmail.com  Mon Jan 21 23:49:15 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 22 Jan 2008 02:49:15 -0200
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <20080121215327.1f851a8f.zedshaw@zedshaw.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<71166b3b0801211255r4e1b30fbq44cc2dba70d2e365@mail.gmail.com>
	<683a886f0801211300l4ec06bc8t3b21f4b06739f65c@mail.gmail.com>
	<71166b3b0801211312y29654909idde948dbd1356491@mail.gmail.com>
	<20080121170643.50253130.zedshaw@zedshaw.com>
	<71166b3b0801211408v2be00eees1136ed9f721cc1f7@mail.gmail.com>
	<20080121215327.1f851a8f.zedshaw@zedshaw.com>
Message-ID: <71166b3b0801212049x7082e72cn3ab5b0784b79be6c@mail.gmail.com>

On Jan 21, 2008 11:53 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> On Mon, 21 Jan 2008 20:08:46 -0200
> "Luis Lavena" <luislavena at gmail.com> wrote:
>
> > > That's bullshit.  All of those tests are simple checks to make sure
> > > that you aren't passing in NULL pointers (which happens when the lib is
> > > used generally).  Removing those would be a tiny little impact on the
> > > performance since they're written in raw C.  Only reason that'd speed
> > > things up is if the compiler wasn't doing its job right (which is
> > > possible).
> > >
> >
> > Please Zed, I'm not validating nor arguing against that decision. I
> > just exposing that, the way I asked on #thin irc channel too a few
> > weeks back.
>
> Sorry Luis, but I didn't say "Luis, you're a bullshitter."  I said,
> "That's bullshit."  Meaning, the claim of a large performance increase
> from just removing a series of if-statements isn't worth the loss in
> security and safety.
>

I know Zed, Monday was not a good day :-P
(so no personal offense, just bad wording from my side).

I was thinking sending an email with this thing I discovered on thin
code, but found the opportunity to ask here (on ry thread instead).

Don't you hate when you don't have enough time to do all the things you love?

> You should know by now that if I *really* wanted to be mean to you I'd
> say it directly to you.  I'm talking about the code, nobody directly or
> their personalities.

Yes Zed, thankfuly you wouldn't, right? :-D

I'm such a nice, lovely person, you couldn't be mean to me ;-)

Take care man,

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From boss at airbladesoftware.com  Tue Jan 22 05:05:40 2008
From: boss at airbladesoftware.com (Andrew Stewart)
Date: Tue, 22 Jan 2008 10:05:40 +0000
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801211411y312cc064y165e18fac34b2387@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<20080121165825.c84cb82f.zedshaw@zedshaw.com>
	<3ae7f4480801211411y312cc064y165e18fac34b2387@mail.gmail.com>
Message-ID: <36D6000A-F8EB-4323-983E-69DB5107BA2F@airbladesoftware.com>


On 21 Jan 2008, at 22:11, ry dahl wrote:
>> Grrrr, you need a Y axis Ry.  What is that measuring.  Hell, shoot me
>> the raw data and I'll do the graph with R (since I'm curious).
>
> The vertical axis is requests/sec (says at the top of the graph). I
> don't bother to give actual numbers because it's only to demonstrate
> the relative increase in speed. You can generate your own data with
> the script in ruby_bridge/benchmark/test_camping.rb

I see what you're saying but unfortunately without numbers on the  
ordinate -- specifically without knowing where zero is -- it's  
impossible to evaluate even the relative differences.

Anyway, I'll have a go and generating my own data with that script.   
Thanks.

Regards,
Andy Stewart

-------
http://airbladesoftware.com




From eden at mojiti.com  Tue Jan 22 07:00:26 2008
From: eden at mojiti.com (Eden Li)
Date: Tue, 22 Jan 2008 20:00:26 +0800
Subject: [Mongrel] properly restarting mongrel instances
In-Reply-To: <6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
Message-ID: <1dd361e10801220400n4a3af5e5u7748a91bde929b13@mail.gmail.com>

This patch to mongrel cluster adds a check wait between each start/stop:

http://rubyforge.org/tracker/download.php/1306/5147/15427/2761/rolling-restart.patch

"check wait" is defined as:
 (1) stop the port
 (2) check if it's really dead
 (3) wait 1 second and check again if it's not
 (4) wait 10 seconds if (3) fails and send a force quit

It also does a "rolling restart" stopping and restarting each mongrel
one at a time rather than taking down the whole batch (good for lb
setups).

I've been using in production on 20 servers (160 mongrels total) via a
monkey patched mongrel_rails script for awhile now with good effect
(ymmv).  However, it's not been accepted into any mongrel cluster
releases yet because I've heard they're revamping the whole package.

On Jan 22, 2008 7:25 AM, Dave Cheney <dave at cheney.net> wrote:
> We run into this problem a lot as well. The problem can be exacerbated
> when a mongrel has a backlog of work, or has bloated to a point that
> it is heavily swapped. The mongrels always get the shutdown signal,
> but they don't act on it fast enough to clear their pid file by the
> time the start is actioned.
>
> In our case those mongrels will eventually quit and monit will restart
> them, but its not ideal.
>
> If cluster::restart supported a --delay parameter that would go some
> way to fixing the problem.
>
> Cheers
>
> Dave
>
> On 22/01/2008, at 6:05 AM, John Joseph Bachir wrote:
>
> > Is my problem typical? Is there a solution? Seems like mongrel_rails
> > and/or the capistrano recipes should wait for the processes to stop
> > before attempting to restart them.
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From jalmberg at identry.com  Tue Jan 22 09:46:45 2008
From: jalmberg at identry.com (John Almberg)
Date: Tue, 22 Jan 2008 09:46:45 -0500
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
Message-ID: <5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>

I am running a number of Rails apps on a quite powerful server (dual  
quad-core xeons, 8G ram, raid 10) running FreeBSD. I'm using a fairly  
simple software stack: Apache22, mod_proxy, and a single mongrel  
instance for each website. Apache is serving all static content.

These websites are not MySpace, or anything like it. They are typical  
small-business websites that get a few thousand, not millions, of  
pageviews per day.

The websites are extremely fast-loading, apparently very stable  
(nothing has failed in the month or so since I've switched over from  
a FastCGI setup), and I love the simplicity.

My question: This was supposed to be a first step towards using a  
mongrel cluster, but the single mongrel instance seems to work  
perfectly fine. Can I keep using it, as long as the loads stay at  
modest levels? I don't want to move to a more complex set up just  
because it would be cool or fun to do. If a single instance will do  
the job, then simple is better, IMHO.

Am I running any risks with this set up? The one I can think of is  
there is no redundancy: if that single mongrel instance fails, the  
site is down. Has anyone tried monitoring the single instance, and  
restarting it if it fails? Is there anything else I should be  
worrying about?

Any advice, much appreciated.

Thanks: John




From ry at tinyclouds.org  Tue Jan 22 10:00:59 2008
From: ry at tinyclouds.org (ry dahl)
Date: Tue, 22 Jan 2008 16:00:59 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <36D6000A-F8EB-4323-983E-69DB5107BA2F@airbladesoftware.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<20080121165825.c84cb82f.zedshaw@zedshaw.com>
	<3ae7f4480801211411y312cc064y165e18fac34b2387@mail.gmail.com>
	<36D6000A-F8EB-4323-983E-69DB5107BA2F@airbladesoftware.com>
Message-ID: <3ae7f4480801220700h71dbd7cbl9563b4772bdf4f4d@mail.gmail.com>

> I see what you're saying but unfortunately without numbers on the
> ordinate -- specifically without knowing where zero is -- it's
> impossible to evaluate even the relative differences.

Oh yeah, sorry, zero is at the the bottom. yes, the graph could be
clearer.. below is my data - each line is an average of multiple runs
of ab with -n 1000.
(in truth, i avoid exposing my numbers because i'm a bit embarrassed
of my ancient computer. i think if you run them on a modern computer,
these numbers will be in the thousands.)

ebb -c 1 = 113.5025
ebb -c 10 = 93.956
ebb -c 19 = 101.156
ebb -c 28 = 110.335
ebb -c 37 = 119.89
ebb -c 46 = 93.464
ebb -c 55 = 87.46
ebb -c 64 = 93.116
ebb -c 73 = 94.01
ebb -c 82 = 80.8566666666667
ebb -c 91 = 92.064
ebb -c 100 = 98.666
evented mongrel -c 1 = 80.586
evented mongrel -c 10 = 82.418
evented mongrel -c 19 = 76.1075
evented mongrel -c 28 = 82.0766666666667
evented mongrel -c 37 = 88.45
evented mongrel -c 46 = 69.486
evented mongrel -c 55 = 72.81
evented mongrel -c 64 = 67.07
evented mongrel -c 73 = 67.3566666666667
evented mongrel -c 82 = 65.74
evented mongrel -c 91 = 65.666
evented mongrel -c 100 = 64.388
thin -c 1 = 92.1575
thin -c 10 = 74.284
thin -c 19 = 76.8
thin -c 28 = 91.85
thin -c 37 = 91.55
thin -c 46 = 74.802
thin -c 55 = 74.9
thin -c 64 = 69.886
thin -c 73 = 70.2933333333333
thin -c 82 = 63.6933333333333
thin -c 91 = 70.206
thin -c 100 = 70.262


ry

From luislavena at gmail.com  Tue Jan 22 10:04:39 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 22 Jan 2008 13:04:39 -0200
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <3ae7f4480801220700h71dbd7cbl9563b4772bdf4f4d@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<20080121165825.c84cb82f.zedshaw@zedshaw.com>
	<3ae7f4480801211411y312cc064y165e18fac34b2387@mail.gmail.com>
	<36D6000A-F8EB-4323-983E-69DB5107BA2F@airbladesoftware.com>
	<3ae7f4480801220700h71dbd7cbl9563b4772bdf4f4d@mail.gmail.com>
Message-ID: <71166b3b0801220704p7415bf56j21f2f515258354ae@mail.gmail.com>

On Jan 22, 2008 1:00 PM, ry dahl <ry at tinyclouds.org> wrote:
> > I see what you're saying but unfortunately without numbers on the
> > ordinate -- specifically without knowing where zero is -- it's
> > impossible to evaluate even the relative differences.
>
> Oh yeah, sorry, zero is at the the bottom. yes, the graph could be
> clearer.. below is my data - each line is an average of multiple runs
> of ab with -n 1000.

Great data Ry, thanks for it.

For sake of completeness, can you compare it with plain mongrel?

> (in truth, i avoid exposing my numbers because i'm a bit embarrassed
> of my ancient computer. i think if you run them on a modern computer,
> these numbers will be in the thousands.)
>

You shouldn't!

I was doing the first test compatibility for mongrel back in 2006 from
a P3 800Mhz 512MB RAM computer!

Not mention that first version of mongrel_service was created on that computer!

So: don't be hard on you ;-)

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From wyhaines at gmail.com  Tue Jan 22 10:07:17 2008
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 22 Jan 2008 08:07:17 -0700
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
Message-ID: <f4cd26df0801220707q50bc8e97qcc19da2502e8a166@mail.gmail.com>

On Jan 22, 2008 7:46 AM, John Almberg <jalmberg at identry.com> wrote:
> I am running a number of Rails apps on a quite powerful server (dual
> quad-core xeons, 8G ram, raid 10) running FreeBSD. I'm using a fairly
> simple software stack: Apache22, mod_proxy, and a single mongrel
> instance for each website. Apache is serving all static content.
.
.
.
> The websites are extremely fast-loading, apparently very stable
> (nothing has failed in the month or so since I've switched over from
> a FastCGI setup), and I love the simplicity.

I concur.

> My question: This was supposed to be a first step towards using a
> mongrel cluster, but the single mongrel instance seems to work
> perfectly fine. Can I keep using it, as long as the loads stay at
> modest levels? I don't want to move to a more complex set up just
> because it would be cool or fun to do. If a single instance will do
> the job, then simple is better, IMHO.

You can absolutely keep running things that way.  I've ran the same
sort of sites for years, and the vast majority of them have been done
is exactly that way.  It works just fine, and IMHO, more people should
be deploying Rails apps in that sort of simple manner.

> Am I running any risks with this set up? The one I can think of is
> there is no redundancy: if that single mongrel instance fails, the
> site is down. Has anyone tried monitoring the single instance, and
> restarting it if it fails? Is there anything else I should be
> worrying about?

That's about it.  My sites aren't Rails sites, but having a site down
because of an instance failing just isn't something that happens
unless one has a bug in one's code, in my experience.  To be perfectly
safe, just use monit or something similar to keep an eye on your
processes, as you mentioned.  Depending on your code, you should be
about to handle quite a bit of traffic on each site without having to
worry about switching them to a clustered configuration.


Kirk Haines

From ry at tinyclouds.org  Tue Jan 22 10:35:36 2008
From: ry at tinyclouds.org (ry dahl)
Date: Tue, 22 Jan 2008 16:35:36 +0100
Subject: [Mongrel] [ANN] Ebb Web Server
In-Reply-To: <71166b3b0801220704p7415bf56j21f2f515258354ae@mail.gmail.com>
References: <3ae7f4480801140843t6cc81e9ei968a411ece7592b1@mail.gmail.com>
	<3ae7f4480801211234o7d98de1axc5c2053aa1166591@mail.gmail.com>
	<20080121165825.c84cb82f.zedshaw@zedshaw.com>
	<3ae7f4480801211411y312cc064y165e18fac34b2387@mail.gmail.com>
	<36D6000A-F8EB-4323-983E-69DB5107BA2F@airbladesoftware.com>
	<3ae7f4480801220700h71dbd7cbl9563b4772bdf4f4d@mail.gmail.com>
	<71166b3b0801220704p7415bf56j21f2f515258354ae@mail.gmail.com>
Message-ID: <3ae7f4480801220735o545a8dd6jf4734051e78c6878@mail.gmail.com>

> For sake of completeness, can you compare it with plain mongrel?

Yes, i'll do that in future benchmarks. The monkey patching that
swiftiply does makes it not so easy to run regular mongrel and evented
mongrel from the same script.

Speaking of future benchmarks, I will not make announcements to
mongrel-users about Ebb anymore. Instead I will post on my livejournal
under the tag 'ebb'
  http://four.livejournal.com/tag/ebb
If you would like to exclude my other livejournal dribble and only get
Ebb updates, use this feed:
  http://max.kanat.us/tag-syndicate/?user=four&tag=ebb
The git repo itself also has a feed, which I will try to make interesting
  http://repo.or.cz/w/ebb.git?a=rss

> I was doing the first test compatibility for mongrel back in 2006 from
> a P3 800Mhz 512MB RAM computer!

but that's what i'm running now (eep!)

ry

From matthew.langham at indiginox.com  Tue Jan 22 11:05:34 2008
From: matthew.langham at indiginox.com (Matthew Langham)
Date: Tue, 22 Jan 2008 17:05:34 +0100
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
Message-ID: <7E25AA61-817B-49DC-ABE7-913B2B21A29D@indiginox.com>

Hi John,

> Am I running any risks with this set up? The one I can think of is
> there is no redundancy: if that single mongrel instance fails, the
> site is down. Has anyone tried monitoring the single instance, and
> restarting it if it fails? Is there anything else I should be
> worrying about?
>

We use Monit to monitor our instances and Monit both restarts and  
reports via email if anything fails. We schedule Monit to check every  
60 seconds so having an instance fail is not really noticed.

Matthew Langham

----

Matthew Langham
Gesch?ftsf?hrer / Managing Director
Tel: +49 (0) 5251 6948 293
Mobile: +49 (0)172 5749305


Indiginox GmbH
Frankfurter Weg 6, 33106 Paderborn, Germany
HRB Paderborn 8130
Gesch?ftsf?hrer / Managing Directors:
Matthew Langham / Ashley Steele







From jalmberg at identry.com  Tue Jan 22 16:57:29 2008
From: jalmberg at identry.com (John Almberg)
Date: Tue, 22 Jan 2008 16:57:29 -0500
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <7E25AA61-817B-49DC-ABE7-913B2B21A29D@indiginox.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
	<7E25AA61-817B-49DC-ABE7-913B2B21A29D@indiginox.com>
Message-ID: <4812E407-82A5-4CBA-9BA3-E8ACC651E9DA@identry.com>

Kirk & Mathew,

Thanks for confirming that this config makes sense. I'm going to  
stick with it until one of my clients needs more.

Also, thanks for the lead on monit. I'd been using a home-brew  
restart script, but a quick look at the surprisingly good monit docs  
make me think this is a tool I've been looking for.

Mongrel is great, BTW. One of those programs that just works.

Thanks: John



From boss at airbladesoftware.com  Wed Jan 23 05:12:51 2008
From: boss at airbladesoftware.com (Andrew Stewart)
Date: Wed, 23 Jan 2008 10:12:51 +0000
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <4812E407-82A5-4CBA-9BA3-E8ACC651E9DA@identry.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
	<7E25AA61-817B-49DC-ABE7-913B2B21A29D@indiginox.com>
	<4812E407-82A5-4CBA-9BA3-E8ACC651E9DA@identry.com>
Message-ID: <7EFF77B2-36C9-47D0-BBF9-22423ADCF060@airbladesoftware.com>


On 22 Jan 2008, at 21:57, John Almberg wrote:
> Also, thanks for the lead on monit. I'd been using a home-brew
> restart script, but a quick look at the surprisingly good monit docs
> make me think this is a tool I've been looking for.

John,

You may also like to consider the modestly named God:

http://god.rubyforge.org/

The biggest difference from Monit is that its configuration is  
written in Ruby.

With regards,
Andy Stewart

-------
http://airbladesoftware.com




From lists at ruby-forum.com  Wed Jan 23 06:24:14 2008
From: lists at ruby-forum.com (Emanuele Ricci)
Date: Wed, 23 Jan 2008 12:24:14 +0100
Subject: [Mongrel] Compiling the http 1.1 parser apart issue
Message-ID: <6b0c64e6bd3ed7fc66fa2123d393e466@ruby-forum.com>

I do need to install mongrel on an embedded device which cannot compile
so I do have to cross compile the http 1.1 parser separately.
I get a lot of errors during compilation trying to do so.
Has anyone experience of a similar situation?
-- 
Posted via http://www.ruby-forum.com/.

From bettheriver at gmail.com  Wed Jan 23 07:04:40 2008
From: bettheriver at gmail.com (Stephen C)
Date: Wed, 23 Jan 2008 06:04:40 -0600
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <7EFF77B2-36C9-47D0-BBF9-22423ADCF060@airbladesoftware.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
	<7E25AA61-817B-49DC-ABE7-913B2B21A29D@indiginox.com>
	<4812E407-82A5-4CBA-9BA3-E8ACC651E9DA@identry.com>
	<7EFF77B2-36C9-47D0-BBF9-22423ADCF060@airbladesoftware.com>
Message-ID: <e47b92bd0801230404y79b0707aj8100a81b7c2c56ff@mail.gmail.com>

This 'god' thing looks promising. :-)
I'm curious if anyone has seen anything similar for a windows environment
(rails monitoring software for windows). I'd be interested to hear any other
suggestions for more generalized monitoring software for windows servers.
Open source is preferable, but I might consider a commercial product if it
seems like a good fit. Has anyone heard anything about this:
http://fiveruns.com/products - seems to be the only google result.
Sorry this is kind of off-topic. Please feel free to e-mail me privately so
this won't spam the rest of the list and I'll post the replies later for
anyone who is interested. Also I'm using Mongrel, so I can tie it in that
way. ;-)

Cheers, Stephen

On Jan 23, 2008 4:12 AM, Andrew Stewart <boss at airbladesoftware.com> wrote:

>
> On 22 Jan 2008, at 21:57, John Almberg wrote:
> > Also, thanks for the lead on monit. I'd been using a home-brew
> > restart script, but a quick look at the surprisingly good monit docs
> > make me think this is a tool I've been looking for.
>
> John,
>
> You may also like to consider the modestly named God:
>
> http://god.rubyforge.org/
>
> The biggest difference from Monit is that its configuration is
> written in Ruby.
>
> With regards,
> Andy Stewart
>
> -------
> http://airbladesoftware.com
>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080123/90c93081/attachment.html 

From seanmichaelbrown at gmail.com  Wed Jan 23 10:08:38 2008
From: seanmichaelbrown at gmail.com (Sean Brown)
Date: Wed, 23 Jan 2008 10:08:38 -0500
Subject: [Mongrel] Apache, Mongrel, Authentication
Message-ID: <1086fb5f0801230708v2c10dc54q590203113f855888@mail.gmail.com>

A question about mongrel, apache and authentication.

I've got a Rails site with I think a very typical setup:  a mongrel
cluster behind an Apache proxy.  So Apache's handling the static stuff
and it hands off dynamic content to mongrel.  I want to put the site
temporarily behind Apache's basic authentication.  What I get when I
do this is that is a password prompt which prevents all of the images,
stylesheets and other static files from being loaded unless
authenication passes, but anything mongrel handles is not.
Specifically, a user can just keep hitting "Cancel" at the
browser-generated password prompt and he/she will see that rails
generated content without ever entering any credentials.  No styling
and no images, but they do see content.  How can I fix it?  Mongrel
does not seem to be honoring the authentication (and frankly, I don't
know if it can).  Here's my apache config:


<VirtualHost *:80>
  ServerAdmin me at mysite.com
  DocumentRoot /www/mysite/current/public
  ServerName www.mysite.com
  ErrorLog  /www/mysite/logs/mysite.error.log
  CustomLog  /www/mysite/logs/mysite.access.log combined

  <Directory "/www/mysite/current/public">
      Options FollowSymLinks
      AllowOverride AuthConfig Limit
      Order allow,deny
      Allow from all

      AuthType Basic
      AuthName "Restricted"
      AuthBasicProvider file
      AuthUserFile /www/mysite/users/userdb
      Require valid-user

  </Directory>

  RewriteEngine On

  # Check for maintenance file and redirect all requests
  #  ( this is for use with Capistrano's disable_web task )
  RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
  RewriteCond %{SCRIPT_FILENAME} !maintenance.html
  RewriteRule ^.*$ /system/maintenance.html [L]

  # Rewrite index to check for static
  RewriteRule ^/$ /index.html [QSA]

  # Rewrite to check for Rails cached page
  RewriteRule ^([^.]+)$ $1.html [QSA]

  # Redirect all non-static requests to cluster
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

  # Deflate
  AddOutputFilterByType DEFLATE text/html text/plain text/css
  # ... text/xml application/xml application/xhtml+xml text/javascript
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

  <Proxy balancer://mongrel_cluster>
  BalancerMember http://127.0.0.1:8000
  BalancerMember http://127.0.0.1:8001
  BalancerMember http://127.0.0.1:8002

  </Proxy>
</VirtualHost>

From will at hotgazpacho.com  Wed Jan 23 10:21:50 2008
From: will at hotgazpacho.com (Will Green)
Date: Wed, 23 Jan 2008 10:21:50 -0500 (EST)
Subject: [Mongrel] Apache, Mongrel, Authentication
Message-ID: <1201101709.21977@hotgazpacho.com>

You are only protecting your public directory with basic authentication.

Try moving the Auth* and Require directives out of the scope of the public directory, and into the scope of the Virtual Host.

Sean Brown wrote ..
> A question about mongrel, apache and authentication.
> 
> I've got a Rails site with I think a very typical setup:  a mongrel
> cluster behind an Apache proxy.  So Apache's handling the static stuff
> and it hands off dynamic content to mongrel.  I want to put the site
> temporarily behind Apache's basic authentication.  What I get when I
> do this is that is a password prompt which prevents all of the images,
> stylesheets and other static files from being loaded unless
> authenication passes, but anything mongrel handles is not.
> Specifically, a user can just keep hitting "Cancel" at the
> browser-generated password prompt and he/she will see that rails
> generated content without ever entering any credentials.  No styling
> and no images, but they do see content.  How can I fix it?  Mongrel
> does not seem to be honoring the authentication (and frankly, I don't
> know if it can).  Here's my apache config:
> 
> 
> <VirtualHost *:80>
>   ServerAdmin me at mysite.com
>   DocumentRoot /www/mysite/current/public
>   ServerName www.mysite.com
>   ErrorLog  /www/mysite/logs/mysite.error.log
>   CustomLog  /www/mysite/logs/mysite.access.log combined
> 
>   <Directory "/www/mysite/current/public">
>       Options FollowSymLinks
>       AllowOverride AuthConfig Limit
>       Order allow,deny
>       Allow from all
> 
>       AuthType Basic
>       AuthName "Restricted"
>       AuthBasicProvider file
>       AuthUserFile /www/mysite/users/userdb
>       Require valid-user
> 
>   </Directory>
> 
>   RewriteEngine On
> 
>   # Check for maintenance file and redirect all requests
>   #  ( this is for use with Capistrano's disable_web task )
>   RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
>   RewriteCond %{SCRIPT_FILENAME} !maintenance.html
>   RewriteRule ^.*$ /system/maintenance.html [L]
> 
>   # Rewrite index to check for static
>   RewriteRule ^/$ /index.html [QSA]
> 
>   # Rewrite to check for Rails cached page
>   RewriteRule ^([^.]+)$ $1.html [QSA]
> 
>   # Redirect all non-static requests to cluster
>   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
>   RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]
> 
>   # Deflate
>   AddOutputFilterByType DEFLATE text/html text/plain text/css
>   # ... text/xml application/xml application/xhtml+xml text/javascript
>   BrowserMatch ^Mozilla/4 gzip-only-text/html
>   BrowserMatch ^Mozilla/4.0[678] no-gzip
>   BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
> 
>   <Proxy balancer://mongrel_cluster>
>   BalancerMember http://127.0.0.1:8000
>   BalancerMember http://127.0.0.1:8001
>   BalancerMember http://127.0.0.1:8002
> 
>   </Proxy>
> </VirtualHost>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 

From rgo at aspgems.com  Wed Jan 23 10:23:47 2008
From: rgo at aspgems.com (Rafael G.)
Date: Wed, 23 Jan 2008 16:23:47 +0100
Subject: [Mongrel] Apache, Mongrel, Authentication
In-Reply-To: <1086fb5f0801230708v2c10dc54q590203113f855888@mail.gmail.com>
References: <1086fb5f0801230708v2c10dc54q590203113f855888@mail.gmail.com>
Message-ID: <47975C03.6030807@aspgems.com>

You need put password directives in proxy balancer:

  <Proxy balancer://mongrel_cluster>
  BalancerMember http://127.0.0.1:8000
  BalancerMember http://127.0.0.1:8001
  BalancerMember http://127.0.0.1:8002
      AuthType Basic
      AuthName "Restricted"
      AuthBasicProvider file
      AuthUserFile /www/mysite/users/userdb
      Require valid-user


  </Proxy>

Regards

Sean Brown escribi?:
> A question about mongrel, apache and authentication.
>
> I've got a Rails site with I think a very typical setup:  a mongrel
> cluster behind an Apache proxy.  So Apache's handling the static stuff
> and it hands off dynamic content to mongrel.  I want to put the site
> temporarily behind Apache's basic authentication.  What I get when I
> do this is that is a password prompt which prevents all of the images,
> stylesheets and other static files from being loaded unless
> authenication passes, but anything mongrel handles is not.
> Specifically, a user can just keep hitting "Cancel" at the
> browser-generated password prompt and he/she will see that rails
> generated content without ever entering any credentials.  No styling
> and no images, but they do see content.  How can I fix it?  Mongrel
> does not seem to be honoring the authentication (and frankly, I don't
> know if it can).  Here's my apache config:
>
>
> <VirtualHost *:80>
>   ServerAdmin me at mysite.com
>   DocumentRoot /www/mysite/current/public
>   ServerName www.mysite.com
>   ErrorLog  /www/mysite/logs/mysite.error.log
>   CustomLog  /www/mysite/logs/mysite.access.log combined
>
>   <Directory "/www/mysite/current/public">
>       Options FollowSymLinks
>       AllowOverride AuthConfig Limit
>       Order allow,deny
>       Allow from all
>
>       AuthType Basic
>       AuthName "Restricted"
>       AuthBasicProvider file
>       AuthUserFile /www/mysite/users/userdb
>       Require valid-user
>
>   </Directory>
>
>   RewriteEngine On
>
>   # Check for maintenance file and redirect all requests
>   #  ( this is for use with Capistrano's disable_web task )
>   RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
>   RewriteCond %{SCRIPT_FILENAME} !maintenance.html
>   RewriteRule ^.*$ /system/maintenance.html [L]
>
>   # Rewrite index to check for static
>   RewriteRule ^/$ /index.html [QSA]
>
>   # Rewrite to check for Rails cached page
>   RewriteRule ^([^.]+)$ $1.html [QSA]
>
>   # Redirect all non-static requests to cluster
>   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
>   RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]
>
>   # Deflate
>   AddOutputFilterByType DEFLATE text/html text/plain text/css
>   # ... text/xml application/xml application/xhtml+xml text/javascript
>   BrowserMatch ^Mozilla/4 gzip-only-text/html
>   BrowserMatch ^Mozilla/4.0[678] no-gzip
>   BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
>
>   <Proxy balancer://mongrel_cluster>
>   BalancerMember http://127.0.0.1:8000
>   BalancerMember http://127.0.0.1:8001
>   BalancerMember http://127.0.0.1:8002
>
>   </Proxy>
> </VirtualHost>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>   


-- 
Rafael Garcia Ortega

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rgo.vcf
Type: text/x-vcard
Size: 241 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20080123/dd56ccad/attachment.vcf 

From simon.santoro at gmail.com  Wed Jan 23 14:18:10 2008
From: simon.santoro at gmail.com (Simon Santoro)
Date: Wed, 23 Jan 2008 20:18:10 +0100
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
Message-ID: <200801232018.11019.simon.santoro@gmail.com>

Hello all.
I too found out that I sometimes have some action that can take up to 10 
seconds in my rails application. I've read all arguments Zed made about 
polling/and inbox strategies, and I think I just can't work around my feeling 
that a "wrong" request that takes up too much time should be able to lock 
subsequent requests in mongrels queue. That's what I have a balancer for, 
right? :)
So I tried Robert Melas hint[1] and used
BalancerMember http://foo max=1 acquire=100
to see if that helps. But I may have hit a bug[2], and this does not work for 
me.
Does this work for someone? With what version of Apache? I am running 2.2.4. 
Or do all of you have only very fast requests that do not take more than a 
few seconds max to complete? Or do you run a different load balancer? 
HAProxy?
I also think that the overall speed of the application would incerase even 
with relatively fast requests, because the balancer would forward the 
requests always to a free mongrel that has nothing to do, and can handle the 
request immediately.

BTW, it looks like the acquire parameter is not in seconds, but in 
milliseconds, so I tried acquire=100 as well, but no difference.
From[2]
        /* Acquire timeout in milliseconds.
         * If set this will be the maximum time to
         * wait for a free connection.
         */

Maybe this belongs to the Apache ml and not to mongrel, but I think maybe some 
of you hit this problem and solved it somehow.


Another issue: on my system, 
mongrel_rails --version
Mongrel Web Server 1.1.3 (installed as a gem)
the --num-procs parameter does not seem to work. To debug the problem I added
STDERR.puts "TEST: #{worker_list.length}  #{@num_processors}"
on line 279 of /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb, and 
to my surprise it looks like the parameter is ignored. If I run it

$ mongrel_rails start -a 127.0.0.1 -p 8999 --num-procs 1 &
[1] 18617
** Starting Mongrel listening at 127.0.0.1:8999
** Starting Rails with development environment...
config/boot.rb:28:Warning: require_gem is obsolete.  Use gem instead.
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not 
work well.
** Mongrel 1.1.3 available at 127.0.0.1:8999
** Use CTRL-C to stop.

and then:

$ w3m -dump http://localhost:8999/test >/dev/null
TEST: 0  950
$

So it looks like @num_processors is still at the default value of 950, and not 
1 as I told it on the command line. Does the deprecation warning maybe have 
something to do with this (I don't think so, but you never know...)?


Thank you!
Simon

[1]http://rubyforge.org/pipermail/mongrel-users/2007-October/004145.html
[2]http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c?revision=608189&view=markup

From alexey.verkhovsky at gmail.com  Wed Jan 23 15:36:39 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 23 Jan 2008 13:36:39 -0700
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <200801232018.11019.simon.santoro@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
Message-ID: <3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>

On Jan 23, 2008 12:18 PM, Simon Santoro <simon.santoro at gmail.com> wrote:
> Or do you run a different load balancer [for limiting the number of outstanding requests].

Many people do it with HAProxy. EngineYard built an Nginx plugin that
does the same (don't think they released it yet).

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

From simon.santoro at gmail.com  Wed Jan 23 16:23:45 2008
From: simon.santoro at gmail.com (Simon Santoro)
Date: Wed, 23 Jan 2008 22:23:45 +0100
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>
Message-ID: <200801232223.45241.simon.santoro@gmail.com>

On Wednesday 23 January 2008 21:36:39 Alexey Verkhovsky wrote:
> Many people do it with HAProxy. EngineYard built an Nginx plugin that
> does the same (don't think they released it yet).

Thanks for your replay. At least now I know that someone understood my poor 
English :)

From filipe at icewall.org  Wed Jan 23 16:07:45 2008
From: filipe at icewall.org (Filipe)
Date: Wed, 23 Jan 2008 19:07:45 -0200 (BRST)
Subject: [Mongrel] Again: Workaround found for request queuing vs.
 num_processors, accept/close
In-Reply-To: <200801232018.11019.simon.santoro@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
Message-ID: <Pine.LNX.4.64.0801231906280.3722@sophie.icewall.org>

On Wed, 23 Jan 2008, Simon Santoro wrote:

> ...
> So it looks like @num_processors is still at the default value of 950, and not
> 1 as I told it on the command line. Does the deprecation warning maybe have
> something to do with this (I don't think so, but you never know...)?


hum.. this seems like a bug. Could you please open a ticket for it?

Cheers,

filipe {
  @              icewall.org
  GPG         1024D/A6BA423E
  http://filipe.icewall.org/
}



From ezmobius at gmail.com  Wed Jan 23 17:03:21 2008
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Wed, 23 Jan 2008 14:03:21 -0800
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>
Message-ID: <EB75EC5D-4E2F-47A5-9523-4193260950D2@gmail.com>


On Jan 23, 2008, at 12:36 PM, Alexey Verkhovsky wrote:

> On Jan 23, 2008 12:18 PM, Simon Santoro <simon.santoro at gmail.com>  
> wrote:
>> Or do you run a different load balancer [for limiting the number of  
>> outstanding requests].
>
> Many people do it with HAProxy. EngineYard built an Nginx plugin that
> does the same (don't think they released it yet).


	Actually the nginx fair balancer has been released for a while. You  
can read up on it and get it here:

http://wiki.codemongers.com/NginxHttpUpstreamFairModule

Cheers-
- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ezra at engineyard.com
-- EngineYard.com


From simon.santoro at gmail.com  Wed Jan 23 17:11:31 2008
From: simon.santoro at gmail.com (Simon Santoro)
Date: Wed, 23 Jan 2008 23:11:31 +0100
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <Pine.LNX.4.64.0801231906280.3722@sophie.icewall.org>
References: <200801232018.11019.simon.santoro@gmail.com>
	<Pine.LNX.4.64.0801231906280.3722@sophie.icewall.org>
Message-ID: <200801232311.31620.simon.santoro@gmail.com>

On Wednesday 23 January 2008 22:07:45 Filipe wrote:
> hum.. this seems like a bug. Could you please open a ticket for it?

sure.
http://rubyforge.org/tracker/index.php?func=detail&aid=17428&group_id=1306&atid=5145

From simon.santoro at gmail.com  Wed Jan 23 17:36:34 2008
From: simon.santoro at gmail.com (Simon Santoro)
Date: Wed, 23 Jan 2008 23:36:34 +0100
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <EB75EC5D-4E2F-47A5-9523-4193260950D2@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>
	<EB75EC5D-4E2F-47A5-9523-4193260950D2@gmail.com>
Message-ID: <200801232336.34774.simon.santoro@gmail.com>

On Wednesday 23 January 2008 23:03:21 Ezra Zygmuntowicz wrote:
> Actually the nginx fair balancer has been released for a while. You ?
> can read up on it and get it here:
>
> http://wiki.codemongers.com/NginxHttpUpstreamFairModule

Hmmm. I can't use a no-name web server with a load balancer that is a set of 
patches for that server on our intranet production server. At the first 
problem I would lose my job.

From ezmobius at gmail.com  Wed Jan 23 17:45:43 2008
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Wed, 23 Jan 2008 14:45:43 -0800
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <200801232336.34774.simon.santoro@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>
	<EB75EC5D-4E2F-47A5-9523-4193260950D2@gmail.com>
	<200801232336.34774.simon.santoro@gmail.com>
Message-ID: <CF0652A3-6549-4D32-AB69-83F1648F62E4@gmail.com>


On Jan 23, 2008, at 2:36 PM, Simon Santoro wrote:

> On Wednesday 23 January 2008 23:03:21 Ezra Zygmuntowicz wrote:
>> Actually the nginx fair balancer has been released for a while. You
>> can read up on it and get it here:
>>
>> http://wiki.codemongers.com/NginxHttpUpstreamFairModule
>
> Hmmm. I can't use a no-name web server with a load balancer that is  
> a set of
> patches for that server on our intranet production server. At the  
> first
> problem I would lose my job.


	That's too bad then, you will have to suffer on with apache i guess.  
Nginx is a lot more solid then apache is in stability and performance.  
I'm personally running over 1000 nginx daemons with absolutely no  
problems to speak of with it.

Cheers-
- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ezra at engineyard.com
-- EngineYard.com


From simon.santoro at gmail.com  Wed Jan 23 17:57:07 2008
From: simon.santoro at gmail.com (Simon Santoro)
Date: Wed, 23 Jan 2008 23:57:07 +0100
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <CF0652A3-6549-4D32-AB69-83F1648F62E4@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<200801232336.34774.simon.santoro@gmail.com>
	<CF0652A3-6549-4D32-AB69-83F1648F62E4@gmail.com>
Message-ID: <200801232357.07611.simon.santoro@gmail.com>

On Wednesday 23 January 2008 23:45:43 Ezra Zygmuntowicz wrote:
> That's too bad then, you will have to suffer on with apache i guess.

Probably.

> Nginx is a lot more solid then apache is in stability and performance. ?
> I'm personally running over 1000 nginx daemons with absolutely no ?
> problems to speak of with it.

Do you have your architecture documented somewhere online? Can I read it?
I need Apache for kerberos for SSO, and I don't think nginx supports that 
(could not find it). I could put Apache in front of nginx balancing the 
mongrels, but at that point it's maybe better to use haproxy like the the 
rubyworks guys suggest[1] (no need for patches).
I'm open for suggestions.

[1]http://rubyworks.rubyforge.org/manual/haproxy.html

From ezmobius at gmail.com  Wed Jan 23 18:42:05 2008
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Wed, 23 Jan 2008 15:42:05 -0800
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <200801232357.07611.simon.santoro@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<200801232336.34774.simon.santoro@gmail.com>
	<CF0652A3-6549-4D32-AB69-83F1648F62E4@gmail.com>
	<200801232357.07611.simon.santoro@gmail.com>
Message-ID: <F8D06A3F-CE03-4FFC-A778-038550566444@gmail.com>


On Jan 23, 2008, at 2:57 PM, Simon Santoro wrote:

> On Wednesday 23 January 2008 23:45:43 Ezra Zygmuntowicz wrote:
>> That's too bad then, you will have to suffer on with apache i guess.
>
> Probably.
>
>> Nginx is a lot more solid then apache is in stability and  
>> performance.
>> I'm personally running over 1000 nginx daemons with absolutely no
>> problems to speak of with it.
>
> Do you have your architecture documented somewhere online? Can I  
> read it?
> I need Apache for kerberos for SSO, and I don't think nginx supports  
> that
> (could not find it). I could put Apache in front of nginx balancing  
> the
> mongrels, but at that point it's maybe better to use haproxy like  
> the the
> rubyworks guys suggest[1] (no need for patches).
> I'm open for suggestions.
>
> [1]http://rubyworks.rubyforge.org/manual/haproxy.html


Hey Simon-

	I don't have any whitepapers about our architecture currently  
available. But the 50,000 ft view is like this:

Http request from client ->  LVS redundant load balancers -> Nginx ->  
mongrel_cluster.

	The nginx and mongrel clusters run on the same Xen VM. with multiple  
VM's behind the LVS load balancers.

	You are correct that nginx does not support kerberos so you will need  
to keep apache. Haproxy is probably a good solution for you in this  
case.

Cheers-

- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ezra at engineyard.com
-- EngineYard.com


From alexey.verkhovsky at gmail.com  Wed Jan 23 19:12:04 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 23 Jan 2008 17:12:04 -0700
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <F8D06A3F-CE03-4FFC-A778-038550566444@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<200801232336.34774.simon.santoro@gmail.com>
	<CF0652A3-6549-4D32-AB69-83F1648F62E4@gmail.com>
	<200801232357.07611.simon.santoro@gmail.com>
	<F8D06A3F-CE03-4FFC-A778-038550566444@gmail.com>
Message-ID: <3945c4270801231612w17f12d75k3535b6c784c2edca@mail.gmail.com>

On Jan 23, 2008 4:42 PM, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> You are correct that nginx does not support kerberos so you will need
> to keep apache. Haproxy is probably a good solution for you in this
> case.

+1

About Nginx: besides EngineYard and a lot of other Rails deployments,
Nginx serves something like one-fourth of Russian internet traffic,
IIRC. It's not exactly no-name, just hasn't been discovered by the
rest of the world until recently.

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

From zedshaw at zedshaw.com  Wed Jan 23 20:43:14 2008
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 23 Jan 2008 20:43:14 -0500
Subject: [Mongrel] Again: Workaround found for request queuing vs.
 num_processors, accept/close
In-Reply-To: <200801232336.34774.simon.santoro@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>
	<EB75EC5D-4E2F-47A5-9523-4193260950D2@gmail.com>
	<200801232336.34774.simon.santoro@gmail.com>
Message-ID: <20080123204314.e33514f5.zedshaw@zedshaw.com>

On Wed, 23 Jan 2008 23:36:34 +0100
Simon Santoro <simon.santoro at gmail.com> wrote:

> On Wednesday 23 January 2008 23:03:21 Ezra Zygmuntowicz wrote:
> > Actually the nginx fair balancer has been released for a while. You ?
> > can read up on it and get it here:
> >
> > http://wiki.codemongers.com/NginxHttpUpstreamFairModule
> 
> Hmmm. I can't use a no-name web server with a load balancer that is a set of 
> patches for that server on our intranet production server. At the first 
> problem I would lose my job.

Uh, but, Apache is quite literally "a patchy" version of NCSA httpd. :-)

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From zedshaw at zedshaw.com  Wed Jan 23 20:46:41 2008
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 23 Jan 2008 20:46:41 -0500
Subject: [Mongrel] Again: Workaround found for request queuing vs.
 num_processors, accept/close
In-Reply-To: <CF0652A3-6549-4D32-AB69-83F1648F62E4@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>
	<EB75EC5D-4E2F-47A5-9523-4193260950D2@gmail.com>
	<200801232336.34774.simon.santoro@gmail.com>
	<CF0652A3-6549-4D32-AB69-83F1648F62E4@gmail.com>
Message-ID: <20080123204641.258ce7c8.zedshaw@zedshaw.com>

On Wed, 23 Jan 2008 14:45:43 -0800
Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:

> 	That's too bad then, you will have to suffer on with apache i guess.  
> Nginx is a lot more solid then apache is in stability and performance.  
> I'm personally running over 1000 nginx daemons with absolutely no  
> problems to speak of with it.

Yep, a *single* nginx server on a 256M virtual machine with just 2
workers handled a simultaneous Redditing, TechCrunch, TechMeme, and
Slashdotting without so much as a hitch in performance.  That's 170k
uniq visitors in 3 days.

To put this into perspective, I had people ask me to take links off my
pages because the trail-off onto their pages was killing their server.

Of course, I did do some special tuning, but that's another story.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From lists at ruby-forum.com  Thu Jan 24 04:01:39 2008
From: lists at ruby-forum.com (Chris Gers32)
Date: Thu, 24 Jan 2008 10:01:39 +0100
Subject: [Mongrel] ERROR RUNNING 'cluster::configure': Plugin
	/cluster::con
In-Reply-To: <20071109172726.GF6740@malaprop.org>
References: <20071109172726.GF6740@malaprop.org>
Message-ID: <a1314cff9bb65db95691a59532b4bad9@ruby-forum.com>

I have a similar problem, trying to create a Mongrel Server, running as 
a Windows Service :

ERROR RUNNING 'service::install': Plugin /service::install does not 
exist in category /commands

Although I don't use mongrel_cluster, I manage a cluster of Mongrel 
Services from within Apache2.2. I never had this problem before (Win XP, 
Vista), until I tried installing on a Win 2003 Server ; I don't know if 
it's related...

Have you solved your problem?

Chris.
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Thu Jan 24 04:07:01 2008
From: lists at ruby-forum.com (Chris Gers32)
Date: Thu, 24 Jan 2008 10:07:01 +0100
Subject: [Mongrel] ERROR RUNNING 'service::install'
Message-ID: <cd34e0869385bca926b7f4d4491ca780@ruby-forum.com>

Hi,

I'm trying to start a Mongrel (1.1.3) Server, running as a Windows
Service, via

mongrel_rails service::install -N FDS_Server_4001 -p 4001 -e production

But I get the following error message :

ERROR RUNNING 'service::install': Plugin /service::install does not
exist in category /commands

I never had this problem before (Win XP, Vista), until I tried
installing on a Win 2003 Server ; I don't know if it's related...

Does anyone know what causes this? A search in Google for this error
message yields nothing...

Chris.
-- 
Posted via http://www.ruby-forum.com/.

From simon.santoro at gmail.com  Thu Jan 24 04:44:13 2008
From: simon.santoro at gmail.com (Simon Santoro)
Date: Thu, 24 Jan 2008 10:44:13 +0100
Subject: [Mongrel] Again: Workaround found for request queuing
 vs.	num_processors, accept/close
In-Reply-To: <F8D06A3F-CE03-4FFC-A778-038550566444@gmail.com>
References: <200801232018.11019.simon.santoro@gmail.com>	<200801232336.34774.simon.santoro@gmail.com>	<CF0652A3-6549-4D32-AB69-83F1648F62E4@gmail.com>	<200801232357.07611.simon.santoro@gmail.com>
	<F8D06A3F-CE03-4FFC-A778-038550566444@gmail.com>
Message-ID: <47985DED.8070001@gmail.com>

Ezra Zygmuntowicz wrote:
> Hey Simon-
> 
> 	I don't have any whitepapers about our architecture currently  
> available. But the 50,000 ft view is like this:
> 
> Http request from client ->  LVS redundant load balancers -> Nginx ->  
> mongrel_cluster.
> 
> 	The nginx and mongrel clusters run on the same Xen VM. with multiple  
> VM's behind the LVS load balancers.

Cool, good to know. This setup would be a bit overkill to me, but good 
to know how you set things up and how they work.

> 	You are correct that nginx does not support kerberos so you will need  
> to keep apache. Haproxy is probably a good solution for you in this  
> case.

All right. I've set up apache as reverse-/proxy serving haproxy 
balancing the mongrels.
Just to help someone who would like to go down the same road, this is my 
apache site config:

<Virtualhost *:80>
   ServerName whatever
   DocumentRoot /home/myhome/MyHome/public/


   ProxyPass /images !
   ProxyPass /stylesheets !
   ProxyPass /javascripts !

   Alias /images /home/myhome/MyHome/public/images
   Alias /stylesheets /home/myhome/MyHome/public/stylesheets
   Alias /javascripts /home/myhome/MyHome/public/javascripts

   ProxyPass / http://127.0.0.1:8000/
   ProxyPassReverse / http://127.0.0.1:8000
   ProxyPreserveHost on

   <Directory /home/myhome/MyHome/public>
      Options ExecCGI FollowSymLinks
      AllowOverride all
      Order allow,deny
      Allow from all
   </Directory>
</Virtualhost>

and my haproxy.cfg file (took it from rubyworks):

global
web server
   maxconn 500
socket, therefore
   log   127.0.0.1       local0
   user nobody
   group nogroup
defaults
   log global
   mode http
   balance roundrobin
   maxconn 500
   option httplog
   option abortonclose
   retries 3
   redispatch
   clitimeout 120000
   contimeout 120000
   srvtimeout 120000
listen rails :8000
   server rails-1 localhost:8001 maxconn 1 check
   server rails-2 localhost:8002 maxconn 1 check
   server rails-3 localhost:8003 maxconn 1 check


to test I set the clitimeout, contimeout and srvtimeout to high numbers, 
so I can see how long actions/requests get handled.
The "maxconn 1" parameter does exactly what it says (one request per 
mongrel).
I have to test this setup a bit more, and see what haproxy does if a 
mongrel goes down or is disabled.

Thank you all for your feedback.

Simon

From saimonmoore at gmail.com  Thu Jan 24 07:13:38 2008
From: saimonmoore at gmail.com (Saimon Moore)
Date: Thu, 24 Jan 2008 13:13:38 +0100
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails to force
	mongrel not to serve static files
Message-ID: <07CC5FCB-4E9A-47EB-A386-8D85F77A194E@gmail.com>

Hi all,

I've just added a patch that I'd appreciate some feedback on:

http://rubyforge.org/tracker/index.php?func=detail&aid=17446&group_id=1306&atid=5147

Regards,

Saimon
-- 
Saimon Moore
Freelance Web Developer
(Available for hire - For details visit http://saimonmoore.net)

Skype: saimonmoore
Yahoo IM: saimonmoore
Google IM: saimonmoore



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080124/4c8c3427/attachment.html 

From igor at pokelondon.com  Thu Jan 24 08:09:01 2008
From: igor at pokelondon.com (Igor Clark)
Date: Thu, 24 Jan 2008 13:09:01 +0000
Subject: [Mongrel] Again: Workaround found for request queuing vs.
	num_processors, accept/close
In-Reply-To: <20080123204641.258ce7c8.zedshaw@zedshaw.com>
References: <200801232018.11019.simon.santoro@gmail.com>
	<3945c4270801231236u10fd94d9g8babd9c61188b096@mail.gmail.com>
	<EB75EC5D-4E2F-47A5-9523-4193260950D2@gmail.com>
	<200801232336.34774.simon.santoro@gmail.com>
	<CF0652A3-6549-4D32-AB69-83F1648F62E4@gmail.com>
	<20080123204641.258ce7c8.zedshaw@zedshaw.com>
Message-ID: <92CDD9BF-E86D-46F5-BA7E-4875209930F2@pokelondon.com>

On 24 Jan 2008, at 01:46, Zed A. Shaw wrote:

> On Wed, 23 Jan 2008 14:45:43 -0800
> Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
>> 	That's too bad then, you will have to suffer on with apache i guess.
>> Nginx is a lot more solid then apache is in stability and  
>> performance.
>> I'm personally running over 1000 nginx daemons with absolutely no
>> problems to speak of with it.
>
> Yep, a *single* nginx server on a 256M virtual machine with just 2
> workers handled a simultaneous Redditing, TechCrunch, TechMeme, and
> Slashdotting without so much as a hitch in performance.  That's 170k
> uniq visitors in 3 days.
>
> To put this into perspective, I had people ask me to take links off my
> pages because the trail-off onto their pages was killing their server.

Just a "me too" post - nginx is solid. We ran a site with a ~1Mb  
homepage weight (once all the graphics and video clips all over it had  
loaded - yeah, I know ...) on nginx with 2 workers, and it took 570k  
PIs across 65k unique visitors in one day, and that mostly in a 5-hour  
period. OK, it was a dedicated dual Xeon with 4GB RAM and not much on  
it apart from CentOS base + nginx, but I kept a close eye and I didn't  
see it go above 500Mb, and the process load was low enough to make a  
brave man weep.

> Of course, I did do some special tuning, but that's another story.

A story you might be happy to share, perhaps?

i

--
Igor Clark // POKE // 10 Redchurch Street // E2 7DD // +44 (0)20 7749  
5355 // www.pokelondon.com





From luislavena at gmail.com  Thu Jan 24 09:25:53 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 24 Jan 2008 12:25:53 -0200
Subject: [Mongrel] ERROR RUNNING 'service::install'
In-Reply-To: <cd34e0869385bca926b7f4d4491ca780@ruby-forum.com>
References: <cd34e0869385bca926b7f4d4491ca780@ruby-forum.com>
Message-ID: <71166b3b0801240625v78e444f1i6431449caeb42e9a@mail.gmail.com>

On Jan 24, 2008 7:07 AM, Chris Gers32 <lists at ruby-forum.com> wrote:
> Hi,
>
> I'm trying to start a Mongrel (1.1.3) Server, running as a Windows
> Service, via
>
> mongrel_rails service::install -N FDS_Server_4001 -p 4001 -e production
>
> But I get the following error message :
>
> ERROR RUNNING 'service::install': Plugin /service::install does not
> exist in category /commands
>
> I never had this problem before (Win XP, Vista), until I tried
> installing on a Win 2003 Server ; I don't know if it's related...
>
> Does anyone know what causes this? A search in Google for this error
> message yields nothing...
>

What version of mongrel_service are you installing?

if you do just "mongrel_rails" only, you will see the list of
available commands, I bet you will have a "windows::service::install"
set of commands instead of just "service::install"

This was due some changes in the win32-service gem introduced in 0.6.x series.

This issue was fixed in latest (0.3.4) release of mongrel_service.

gem install mongrel_service -v '0.3.4'

HTH,
-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From lists at ruby-forum.com  Thu Jan 24 10:24:21 2008
From: lists at ruby-forum.com (Chris Gers32)
Date: Thu, 24 Jan 2008 16:24:21 +0100
Subject: [Mongrel] [SOLVED] Re: ERROR RUNNING 'service::install'
In-Reply-To: <71166b3b0801240625v78e444f1i6431449caeb42e9a@mail.gmail.com>
References: <cd34e0869385bca926b7f4d4491ca780@ruby-forum.com>
	<71166b3b0801240625v78e444f1i6431449caeb42e9a@mail.gmail.com>
Message-ID: <542835f67263d096b17a1f57908157b0@ruby-forum.com>

Luis Lavena wrote:
> This issue was fixed in latest (0.3.4) release of mongrel_service.
> 
> gem install mongrel_service -v '0.3.4'

You're right: I upgraded mongrel_service and now see the 
service::install command. Unfortunately, I got a new error message when 
I tried creating the Mongrel Service:

C:\web\FDS_Server>mongrel_rails service::install -N FDS_Server_4001 -p 
4001 -e production
c:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:379:in 
`report_activate_error': Could not find RubyGem win32-service (>= 0.5.2, 
< 0.6.0) (Gem::LoadError)

Finally, installing win32-service 0.5.2 did the trick... But the current 
version is 0.6.1 ; will mongrel_service be compatible with it in the 
future?

Thanks for your help, once again,

Chris.
-- 
Posted via http://www.ruby-forum.com/.

From luislavena at gmail.com  Thu Jan 24 10:31:36 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 24 Jan 2008 13:31:36 -0200
Subject: [Mongrel] [SOLVED] Re: ERROR RUNNING 'service::install'
In-Reply-To: <542835f67263d096b17a1f57908157b0@ruby-forum.com>
References: <cd34e0869385bca926b7f4d4491ca780@ruby-forum.com>
	<71166b3b0801240625v78e444f1i6431449caeb42e9a@mail.gmail.com>
	<542835f67263d096b17a1f57908157b0@ruby-forum.com>
Message-ID: <71166b3b0801240731q6f2c98e0sef25f9007fafe37e@mail.gmail.com>

On Jan 24, 2008 1:24 PM, Chris Gers32 <lists at ruby-forum.com> wrote:
> Luis Lavena wrote:
> > This issue was fixed in latest (0.3.4) release of mongrel_service.
> >
> > gem install mongrel_service -v '0.3.4'
>
> You're right: I upgraded mongrel_service and now see the
> service::install command. Unfortunately, I got a new error message when
> I tried creating the Mongrel Service:
>
> C:\web\FDS_Server>mongrel_rails service::install -N FDS_Server_4001 -p
> 4001 -e production
> c:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:379:in
> `report_activate_error': Could not find RubyGem win32-service (>= 0.5.2,
> < 0.6.0) (Gem::LoadError)
>
> Finally, installing win32-service 0.5.2 did the trick... But the current
> version is 0.6.1 ; will mongrel_service be compatible with it in the
> future?
>

mongrel_service only use win32-service to register/unregister the service.

Is not possible maintain compatibility with both releases 0.5.x or
0.6.x due some API changes.

The dependency on win32-service is planned to be removed completely.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From njvack at wisc.edu  Thu Jan 24 10:42:45 2008
From: njvack at wisc.edu (Nathan Vack)
Date: Thu, 24 Jan 2008 09:42:45 -0600
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails to
	force	mongrel not to serve static files
In-Reply-To: <07CC5FCB-4E9A-47EB-A386-8D85F77A194E@gmail.com>
References: <07CC5FCB-4E9A-47EB-A386-8D85F77A194E@gmail.com>
Message-ID: <569EB13E-E7CE-4FE5-AA1F-6215C340E6EA@wisc.edu>

On Jan 24, 2008, at 6:13 AM, Saimon Moore wrote:

> Hi all,
>
> I've just added a patch that I'd appreciate some feedback on:
>
> http://rubyforge.org/tracker/index.php? 
> func=detail&aid=17446&group_id=1306&atid=5147

I'll admit by cold-addled brain isn't following logic perfectly this  
morning, but I feel like this really would be better handled by the  
upstream HTTP handler giving enough information to your app so it  
serves the right cached file (or runs the right controller, or  
whatever).

I think passing the Host: header along with the request_routing  
plugin (assuming you're on Rails) will make everything happy:

http://agilewebdevelopment.com/plugins/request_routing

Or am I missing something?

-Nate

From johnjosephbachir at gmail.com  Thu Jan 24 11:45:23 2008
From: johnjosephbachir at gmail.com (John Joseph Bachir)
Date: Thu, 24 Jan 2008 11:45:23 -0500
Subject: [Mongrel] writing pid file earlier
Message-ID: <4a3752180801240845n630ee43die1f32dcbab1d24f7@mail.gmail.com>

I'm using god* to monitor my mongrels. God looks at pid files to know
the status of the cluster. It seems as though mongrel does not write a
pid file until it has loaded the entire rails/project environment,
which in my case, takes upwards of 90 seconds. Meanwhile, god is
freaking out because it thinks that there aren't mongrels running, and
it tries to start them. Thankfully I can set god's "grace period" to 5
minutes, so I only get one false restart, but it would be nice to have
a different solution.

Short of patching god the only thing I can think of is some sort of
wrapper shell or ruby script that writes the pid ahead of time, but
even then, the pid would conflict with when mongrel wants to write a
pid-- I can't think of a good way to delete the initial pid "just in
time".

Any ideas are appreciated, or if the mongrel team is open to a patch
to write the pid much earlier, I can try to put that together.

Cheers,
John

* http://god.rubyforge.org/

-- 
John Joseph Bachir
http://blog.johnjosephbachir.org
http://lyceum.ibiblio.org
http://dissent.cc
http://jjb.cc

From will at hotgazpacho.com  Thu Jan 24 13:43:03 2008
From: will at hotgazpacho.com (Will Green)
Date: Thu, 24 Jan 2008 13:43:03 -0500 (EST)
Subject: [Mongrel] writing pid file earlier
Message-ID: <1201200183.19860@hotgazpacho.com>

Lets say you alter the code.

What happens if the PID file is written, but Mongrel dies kicking off the Rails app (because you have a problem with your Rails code)? Won't god* then think that your process is running when it isn't? Isn't this false positiver worse than a couple false negatives?

Seems to me that if you can't tell god* to wait long enough for your process to start, maybe god* isn't the answer...

==
Will Green

John Joseph Bachir wrote ..
> I'm using god* to monitor my mongrels. God looks at pid files to know
> the status of the cluster. It seems as though mongrel does not write a
> pid file until it has loaded the entire rails/project environment,
> which in my case, takes upwards of 90 seconds. Meanwhile, god is
> freaking out because it thinks that there aren't mongrels running, and
> it tries to start them. Thankfully I can set god's "grace period" to 5
> minutes, so I only get one false restart, but it would be nice to have
> a different solution.
> 
> Short of patching god the only thing I can think of is some sort of
> wrapper shell or ruby script that writes the pid ahead of time, but
> even then, the pid would conflict with when mongrel wants to write a
> pid-- I can't think of a good way to delete the initial pid "just in
> time".
> 
> Any ideas are appreciated, or if the mongrel team is open to a patch
> to write the pid much earlier, I can try to put that together.
> 
> Cheers,
> John
> 
> * http://god.rubyforge.org/
> 
> -- 
> John Joseph Bachir
> http://blog.johnjosephbachir.org
> http://lyceum.ibiblio.org
> http://dissent.cc
> http://jjb.cc
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 

From wyhaines at gmail.com  Thu Jan 24 13:49:04 2008
From: wyhaines at gmail.com (Kirk Haines)
Date: Thu, 24 Jan 2008 11:49:04 -0700
Subject: [Mongrel] writing pid file earlier
In-Reply-To: <1201200183.19860@hotgazpacho.com>
References: <1201200183.19860@hotgazpacho.com>
Message-ID: <f4cd26df0801241049m7aac89f6j7170fe7ef8481265@mail.gmail.com>

On Jan 24, 2008 11:43 AM, Will Green <will at hotgazpacho.com> wrote:
> Lets say you alter the code.
>
> What happens if the PID file is written, but Mongrel dies kicking off the Rails app (because you have a problem with your Rails code)? Won't god* then think that your process is running when it isn't? Isn't this false positiver worse than a couple false negatives?

Well, IMHO, mongrel should write the pid file early, and clean the pid
file up when it dies, for whatever reason short of something
untrappable like a segfault.


Kirk Haines

From saimonmoore at gmail.com  Thu Jan 24 21:21:53 2008
From: saimonmoore at gmail.com (Saimon Moore)
Date: Fri, 25 Jan 2008 03:21:53 +0100
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails to
	force	mongrel not to serve static files
In-Reply-To: <569EB13E-E7CE-4FE5-AA1F-6215C340E6EA@wisc.edu>
References: <07CC5FCB-4E9A-47EB-A386-8D85F77A194E@gmail.com>
	<569EB13E-E7CE-4FE5-AA1F-6215C340E6EA@wisc.edu>
Message-ID: <4FE2C4AC-7A5C-4834-8760-23C25510DE5A@gmail.com>

Hi Nathan,

The problem is that mongrel is serving the static file long before  
rails knows anything about it.

e.g. As I mention in the patch, you have a web server setup with  
multiple virtual hosts each mapped to a separate doc root.

example.com => /var/www/apps/example.com/public

es.example.com => /var/www/apps/example.com/public/es

Rails is using page caching and the cache is clean.

1st request:

http://example.com =>

1. web server looks for /var/www/apps/example.com/public/index.html
2. passes request to mongrel which does the same thing, doesn't find  
it and calls rails to render it.
3. Now /var/www/apps/example.com/public/index.html exists as was  
cached by rails.

2nd request:

http://es.example.com =>

1. web server looks for /var/www/apps/example.com/public/es/index.html
2. passes request to mongrel which looks for /var/www/apps/example.com/ 
public/index.html
(which unlike the web server, has only one doc root),
finds the file under /var/www/apps/example.com/public/index.html   
(from the previous request) and serves that back before rails has even  
got a chance to know about it. It has served the wrong file.

I hope this example makes it clearer.

With the ability to force mongrel to forward all requests it receives  
to rails, on the second request rails (using the host info) would then  
cache the index.html file into /var/www/apps/example.com/public/es/ 
index.html.

As I was writing this, I just thought of another possibility being  
writing a custom mongrel handler, but as mongrel_rails is a handler  
itself, it seems a bit pointless so I still think my patch has merits.

Thoughts?

Regards,

Saimon


On Jan 24, 2008, at 4:42 PM, Nathan Vack wrote:

> On Jan 24, 2008, at 6:13 AM, Saimon Moore wrote:
>
>> Hi all,
>>
>> I've just added a patch that I'd appreciate some feedback on:
>>
>> http://rubyforge.org/tracker/index.php?
>> func=detail&aid=17446&group_id=1306&atid=5147
>
> I'll admit by cold-addled brain isn't following logic perfectly this
> morning, but I feel like this really would be better handled by the
> upstream HTTP handler giving enough information to your app so it
> serves the right cached file (or runs the right controller, or
> whatever).
>
> I think passing the Host: header along with the request_routing
> plugin (assuming you're on Rails) will make everything happy:
>
> http://agilewebdevelopment.com/plugins/request_routing
>
> Or am I missing something?
>
> -Nate
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- 
Saimon Moore
Freelance Web Developer
(Available for hire - For details visit http://saimonmoore.net)

Skype: saimonmoore
Yahoo IM: saimonmoore
Google IM: saimonmoore




From lists at ruby-forum.com  Thu Jan 24 21:36:47 2008
From: lists at ruby-forum.com (Bbq Plate)
Date: Fri, 25 Jan 2008 03:36:47 +0100
Subject: [Mongrel] hi, can someone explain to me backgroundrb and mongrel?
Message-ID: <4ec59202d27a18a8a6b910334d4b4266@ruby-forum.com>

hi,
i am trying to grasp some concepts about mongrel, rails, and
backgroundrb on how they all work in terms of threads and such. is there
a book about distributed ruby and processes? i havent seen any on amazon
yet...

from my blog reading, i have some questions....


rails can handle 1 request at a time and can buffer to a certain extent?

when mongrel instances are created, a copy of the rails app is loaded
into each mongrel instance's memory space?


these mongrel instances can read and write to the mysql database
simultaneously?

the middleman of backgroundrb, is he on his own thread outside the rails
app or is he using a mongrel instance?

how about the middleman's workers, are they on their own thread outside
the rails app or would they be working with a mongrels instance?


thanks for any help! my main goal is to create a scalable video service
or other fun things!
-- 
Posted via http://www.ruby-forum.com/.

From kraemer at webit.de  Fri Jan 25 07:54:45 2008
From: kraemer at webit.de (Jens Kraemer)
Date: Fri, 25 Jan 2008 13:54:45 +0100
Subject: [Mongrel] hi,
	can someone explain to me backgroundrb and	mongrel?
In-Reply-To: <4ec59202d27a18a8a6b910334d4b4266@ruby-forum.com>
References: <4ec59202d27a18a8a6b910334d4b4266@ruby-forum.com>
Message-ID: <20080125125445.GA507@cordoba.webit.de>

Hi!

On Fri, Jan 25, 2008 at 03:36:47AM +0100, Bbq Plate wrote:
[..]
> rails can handle 1 request at a time and can buffer to a certain extent?

Rails doesn't do the buffering, it's the Server running it (i.e.
Mongrel) that delivers requests one at a time to Rails. To distribute
requests across multiple Mongrel instances you need some additional
piece of software, i.e. Apache's mod_proxy_balancer.

> when mongrel instances are created, a copy of the rails app is loaded
> into each mongrel instance's memory space?

exactly.

> these mongrel instances can read and write to the mysql database
> simultaneously?

yes. Each Mongrel instance is a separate independent process.

> the middleman of backgroundrb, is he on his own thread outside the rails
> app or is he using a mongrel instance?

the middleman is just a handle to access the backgrounDRb server, which
is running in a separate process outside of Rails and the Mongrels.

> how about the middleman's workers, are they on their own thread outside
> the rails app or would they be working with a mongrels instance?

The workers are running in separate threads inside the DRb server
process. In fact that's the whole point of backgrounDRb - free up the
Mongrel processes from having to handle long-running tasks.

Cheers,
Jens


-- 
Jens Kr?mer
webit! Gesellschaft f?r neue Medien mbH
Schnorrstra?e 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
kraemer at webit.de | www.webit.de
 
Amtsgericht Dresden | HRB 15422
GF Sven Haubold

From will at hotgazpacho.com  Fri Jan 25 09:32:55 2008
From: will at hotgazpacho.com (Will Green)
Date: Fri, 25 Jan 2008 09:32:55 -0500 (EST)
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails
	to	force	mongrel not to serve static files
In-Reply-To: <4FE2C4AC-7A5C-4834-8760-23C25510DE5A@gmail.com>
Message-ID: <1201271575.9263@hotgazpacho.com>

SO, it sounds like you have Apache (or another web server) in front of a pack of Mongrels, which should be serving static files. It sounds like your front-end web server is passing requests back to mongrel when this is not your intent. If so, it sounds like you have a misconfiguration in your front-end web server configuration.

Is this the case?

==
Will Green

Saimon Moore wrote ..
> Hi Nathan,
> 
> The problem is that mongrel is serving the static file long before  
> rails knows anything about it.
> 
> e.g. As I mention in the patch, you have a web server setup with  
> multiple virtual hosts each mapped to a separate doc root.
> 
> example.com => /var/www/apps/example.com/public
> 
> es.example.com => /var/www/apps/example.com/public/es
> 
> Rails is using page caching and the cache is clean.
> 
> 1st request:
> 
> http://example.com =>
> 
> 1. web server looks for /var/www/apps/example.com/public/index.html
> 2. passes request to mongrel which does the same thing, doesn't find  
> it and calls rails to render it.
> 3. Now /var/www/apps/example.com/public/index.html exists as was  
> cached by rails.
> 
> 2nd request:
> 
> http://es.example.com =>
> 
> 1. web server looks for /var/www/apps/example.com/public/es/index.html
> 2. passes request to mongrel which looks for /var/www/apps/example.com/ 
> public/index.html
> (which unlike the web server, has only one doc root),
> finds the file under /var/www/apps/example.com/public/index.html   
> (from the previous request) and serves that back before rails has even  
> got a chance to know about it. It has served the wrong file.
> 
> I hope this example makes it clearer.
> 
> With the ability to force mongrel to forward all requests it receives  
> to rails, on the second request rails (using the host info) would then  
> cache the index.html file into /var/www/apps/example.com/public/es/ 
> index.html.
> 
> As I was writing this, I just thought of another possibility being  
> writing a custom mongrel handler, but as mongrel_rails is a handler  
> itself, it seems a bit pointless so I still think my patch has merits.
> 
> Thoughts?
> 
> Regards,
> 
> Saimon
> 
> 
> On Jan 24, 2008, at 4:42 PM, Nathan Vack wrote:
> 
> > On Jan 24, 2008, at 6:13 AM, Saimon Moore wrote:
> >
> >> Hi all,
> >>
> >> I've just added a patch that I'd appreciate some feedback on:
> >>
> >> http://rubyforge.org/tracker/index.php?
> >> func=detail&aid=17446&group_id=1306&atid=5147
> >
> > I'll admit by cold-addled brain isn't following logic perfectly this
> > morning, but I feel like this really would be better handled by the
> > upstream HTTP handler giving enough information to your app so it
> > serves the right cached file (or runs the right controller, or
> > whatever).
> >
> > I think passing the Host: header along with the request_routing
> > plugin (assuming you're on Rails) will make everything happy:
> >
> > http://agilewebdevelopment.com/plugins/request_routing
> >
> > Or am I missing something?
> >
> > -Nate
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> 
> -- 
> Saimon Moore
> Freelance Web Developer
> (Available for hire - For details visit http://saimonmoore.net)
> 
> Skype: saimonmoore
> Yahoo IM: saimonmoore
> Google IM: saimonmoore
> 
> 
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 

From gethemant at gmail.com  Fri Jan 25 10:24:58 2008
From: gethemant at gmail.com (hemant)
Date: Fri, 25 Jan 2008 20:54:58 +0530
Subject: [Mongrel] hi,
	can someone explain to me backgroundrb and mongrel?
In-Reply-To: <20080125125445.GA507@cordoba.webit.de>
References: <4ec59202d27a18a8a6b910334d4b4266@ruby-forum.com>
	<20080125125445.GA507@cordoba.webit.de>
Message-ID: <fb283d5e0801250724pa714674m7324b8f7c931da07@mail.gmail.com>

On Fri, Jan 25, 2008 at 6:24 PM, Jens Kraemer <kraemer at webit.de> wrote:
> Hi!
>
>  On Fri, Jan 25, 2008 at 03:36:47AM +0100, Bbq Plate wrote:
>  [..]
>
> > rails can handle 1 request at a time and can buffer to a certain extent?
>
>  Rails doesn't do the buffering, it's the Server running it (i.e.
>  Mongrel) that delivers requests one at a time to Rails. To distribute
>  requests across multiple Mongrel instances you need some additional
>  piece of software, i.e. Apache's mod_proxy_balancer.
>
>
>  > when mongrel instances are created, a copy of the rails app is loaded
>  > into each mongrel instance's memory space?
>
>  exactly.
>
>
>  > these mongrel instances can read and write to the mysql database
>  > simultaneously?
>
>  yes. Each Mongrel instance is a separate independent process.
>
>
>  > the middleman of backgroundrb, is he on his own thread outside the rails
>  > app or is he using a mongrel instance?
>
>  the middleman is just a handle to access the backgrounDRb server, which
>  is running in a separate process outside of Rails and the Mongrels.

Thats right MiddleMan is just a client to the BackgrounDRb server. Its
connected to BackgrounDRb server through TCP Socket.

>
>
>  > how about the middleman's workers, are they on their own thread outside
>  > the rails app or would they be working with a mongrels instance?
>
>  The workers are running in separate threads inside the DRb server
>  process. In fact that's the whole point of backgrounDRb - free up the
>  Mongrel processes from having to handle long-running tasks.

Thanks Jens, but just to correct a bit, workers run in their own process.

-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org

From saimonmoore at gmail.com  Fri Jan 25 10:34:23 2008
From: saimonmoore at gmail.com (Saimon Moore)
Date: Fri, 25 Jan 2008 16:34:23 +0100
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails
	to	force	mongrel not to serve static files
In-Reply-To: <1201271575.9263@hotgazpacho.com>
References: <1201271575.9263@hotgazpacho.com>
Message-ID: <3E97E4C5-DCBF-4F39-97F6-D38D3FE4AD6B@gmail.com>

Will,

Yes it's the case that a front-end web server (nginx) is sitting in  
front of the mongrels but no it's not the case that it is misconfigured.

As I hoped my example was illustrating, the web server knows about  
different virtual hosts but mongrel doesn't.


Let me try and give another example with even more detail:


Assume:

* Mongrel (without patch), which serves any static files it finds in  
it's doc root (RAILS_ROOT/public)

* Web server  (WS) virtual host mapping:

*    example.com => /var/www/apps/example.com/public             (web  
server's doc root for virtual host 1)

*    es.example.com => /var/www/apps/example.com/public/es  (web  
server's doc root for virtual host 2)


directory structure (DS) when cache is cleared:

RAILS_ROOT/public
RAILS_ROOT/public/es


Steps on 1st request: http://example.com

1. WS: can't find index.html in /var/www/apps/example.com/public
2. WS forwards request to mongrel process (M)
3. M can't find index.html in /var/www/apps/example.com/public
4. Mongrel creates a rails process to handle request for /
5. Rails, sees example.com host and / path and renders index.html in / 
var/www/apps/example.com/public
6. Mongrel serves /var/www/apps/example.com/public/index.html back

There's no problem at this point. But bear with me...

DS is now:

RAILS_ROOT/public
RAILS_ROOT/public/index.html
RAILS_ROOT/public/es

Steps on 2nd request: http://example.com

1. WS: finds index.html in /var/www/apps/example.com/public
2. WS serves request

Again, no problem...just served up previously cached file from same  
domain.


DS is still:

RAILS_ROOT/public
RAILS_ROOT/public/index.html
RAILS_ROOT/public/es


Steps on 3rd request: http://es.example.com

1. WS: can't find index.html in /var/www/apps/example.com/public/es <=  
Note the doc root is different
2. WS forwards request to mongrel process (M)
3. M finds index.html in /var/www/apps/example.com/public
4. Mongrel serves /var/www/apps/example.com/public/index.html which is  
the page associated with the http://example.com domain.
5. This is NOT the required behaviour as it's serving the cached file  
for http://example.com rather than http://es.example.com as was  
requested.

DS is still:

RAILS_ROOT/public
RAILS_ROOT/public/index.html
RAILS_ROOT/public/es


Alternative 3rd request (http://es.example.com) with * patched mongrel  
* (mongrel set NOT to serve any static files):

1. WS: can't find index.html in /var/www/apps/example.com/public/es
2. WS forwards request to mongrel process (M)
3. M ignores index.html in /var/www/apps/example.com/public as it  
directly forwards request to rails
4. Mongrel creates a rails process to handle request
5. Rails, sees es.example.com host and / path and renders index.html  
in /var/www/apps/example.com/public/es
6. Mongrel serves /var/www/apps/example.com/public/es/index.html back

DS is now:

RAILS_ROOT/public
RAILS_ROOT/public/index.html
RAILS_ROOT/public/es
RAILS_ROOT/public/es/index.html

Note: Now the right page has been served for the right domain. After  
the file has been cached for http://es.example.com, the WS will  
happily serve that up.

Phew, I hope this finally illustrates the problem with more clarity.

:)

Regards,

Saimon

On Jan 25, 2008, at 3:32 PM, Will Green wrote:

> SO, it sounds like you have Apache (or another web server) in front  
> of a pack of Mongrels, which should be serving static files. It  
> sounds like your front-end web server is passing requests back to  
> mongrel when this is not your intent. If so, it sounds like you have  
> a misconfiguration in your front-end web server configuration.
>
> Is this the case?
>
> ==
> Will Green
>
> Saimon Moore wrote ..
>> Hi Nathan,
>>
>> The problem is that mongrel is serving the static file long before
>> rails knows anything about it.
>>
>> e.g. As I mention in the patch, you have a web server setup with
>> multiple virtual hosts each mapped to a separate doc root.
>>
>> example.com => /var/www/apps/example.com/public
>>
>> es.example.com => /var/www/apps/example.com/public/es
>>
>> Rails is using page caching and the cache is clean.
>>
>> 1st request:
>>
>> http://example.com =>
>>
>> 1. web server looks for /var/www/apps/example.com/public/index.html
>> 2. passes request to mongrel which does the same thing, doesn't find
>> it and calls rails to render it.
>> 3. Now /var/www/apps/example.com/public/index.html exists as was
>> cached by rails.
>>
>> 2nd request:
>>
>> http://es.example.com =>
>>
>> 1. web server looks for /var/www/apps/example.com/public/es/ 
>> index.html
>> 2. passes request to mongrel which looks for /var/www/apps/ 
>> example.com/
>> public/index.html
>> (which unlike the web server, has only one doc root),
>> finds the file under /var/www/apps/example.com/public/index.html
>> (from the previous request) and serves that back before rails has  
>> even
>> got a chance to know about it. It has served the wrong file.
>>
>> I hope this example makes it clearer.
>>
>> With the ability to force mongrel to forward all requests it receives
>> to rails, on the second request rails (using the host info) would  
>> then
>> cache the index.html file into /var/www/apps/example.com/public/es/
>> index.html.
>>
>> As I was writing this, I just thought of another possibility being
>> writing a custom mongrel handler, but as mongrel_rails is a handler
>> itself, it seems a bit pointless so I still think my patch has  
>> merits.
>>
>> Thoughts?
>>
>> Regards,
>>
>> Saimon
>>
>>
>> On Jan 24, 2008, at 4:42 PM, Nathan Vack wrote:
>>
>>> On Jan 24, 2008, at 6:13 AM, Saimon Moore wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've just added a patch that I'd appreciate some feedback on:
>>>>
>>>> http://rubyforge.org/tracker/index.php?
>>>> func=detail&aid=17446&group_id=1306&atid=5147
>>>
>>> I'll admit by cold-addled brain isn't following logic perfectly this
>>> morning, but I feel like this really would be better handled by the
>>> upstream HTTP handler giving enough information to your app so it
>>> serves the right cached file (or runs the right controller, or
>>> whatever).
>>>
>>> I think passing the Host: header along with the request_routing
>>> plugin (assuming you're on Rails) will make everything happy:
>>>
>>> http://agilewebdevelopment.com/plugins/request_routing
>>>
>>> Or am I missing something?
>>>
>>> -Nate
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>> -- 
>> Saimon Moore
>> Freelance Web Developer
>> (Available for hire - For details visit http://saimonmoore.net)
>>
>> Skype: saimonmoore
>> Yahoo IM: saimonmoore
>> Google IM: saimonmoore
>>
>>
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- 
Saimon Moore
Freelance Web Developer
(Available for hire - For details visit http://saimonmoore.net)

Skype: saimonmoore
Yahoo IM: saimonmoore
Google IM: saimonmoore




From kraemer at webit.de  Fri Jan 25 10:37:09 2008
From: kraemer at webit.de (Jens Kraemer)
Date: Fri, 25 Jan 2008 16:37:09 +0100
Subject: [Mongrel] hi,
	can someone explain to me backgroundrb and	mongrel?
In-Reply-To: <fb283d5e0801250724pa714674m7324b8f7c931da07@mail.gmail.com>
References: <4ec59202d27a18a8a6b910334d4b4266@ruby-forum.com>
	<20080125125445.GA507@cordoba.webit.de>
	<fb283d5e0801250724pa714674m7324b8f7c931da07@mail.gmail.com>
Message-ID: <20080125153709.GE507@cordoba.webit.de>

On Fri, Jan 25, 2008 at 08:54:58PM +0530, hemant wrote:
[..]
> >  > how about the middleman's workers, are they on their own thread outside
> >  > the rails app or would they be working with a mongrels instance?
> >
> >  The workers are running in separate threads inside the DRb server
> >  process. In fact that's the whole point of backgrounDRb - free up the
> >  Mongrel processes from having to handle long-running tasks.
> 
> Thanks Jens, but just to correct a bit, workers run in their own process.

Ah, thanks for pointing that out. I didn't follow the recent development
of backgrounDRb, I guess that's one thing that has changed with it's
rewrite?

Jens

-- 
Jens Kr?mer
webit! Gesellschaft f?r neue Medien mbH
Schnorrstra?e 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
kraemer at webit.de | www.webit.de
 
Amtsgericht Dresden | HRB 15422
GF Sven Haubold

From will at hotgazpacho.com  Fri Jan 25 10:53:10 2008
From: will at hotgazpacho.com (Will Green)
Date: Fri, 25 Jan 2008 10:53:10 -0500 (EST)
Subject: [Mongrel] #17446 [PATCH] Add option to
	mongrel_rails	to	force	mongrel not to serve static files
In-Reply-To: <3E97E4C5-DCBF-4F39-97F6-D38D3FE4AD6B@gmail.com>
Message-ID: <1201276389.12391@hotgazpacho.com>

Ah, so you have Rails generating a static file.

It looks like you have the same Rails app mounted at two locations. If so, you need to have a way for Nginx to tell Mongrel "hey, this is the same app, but now I need it in Spanish".

Investigate having Nginx pass an environment variable (HTTP header) back to Mongrel. Then create a custom Mongrel handler that searches for the correct index.html file based on that header.

No need to patch Mongrel directly, just extend the existing DirHandler (or write a new one based on the existing one), and register it with Mongrel.

Saimon Moore wrote ..
> Will,
> 
> Yes it's the case that a front-end web server (nginx) is sitting in  
> front of the mongrels but no it's not the case that it is misconfigured.
> 
> As I hoped my example was illustrating, the web server knows about  
> different virtual hosts but mongrel doesn't.
> 
> 
> Let me try and give another example with even more detail:
> 
> 
> Assume:
> 
> * Mongrel (without patch), which serves any static files it finds in  
> it's doc root (RAILS_ROOT/public)
> 
> * Web server  (WS) virtual host mapping:
> 
> *    example.com => /var/www/apps/example.com/public             (web  
> server's doc root for virtual host 1)
> 
> *    es.example.com => /var/www/apps/example.com/public/es  (web  
> server's doc root for virtual host 2)
> 
> 
> directory structure (DS) when cache is cleared:
> 
> RAILS_ROOT/public
> RAILS_ROOT/public/es
> 
> 
> Steps on 1st request: http://example.com
> 
> 1. WS: can't find index.html in /var/www/apps/example.com/public
> 2. WS forwards request to mongrel process (M)
> 3. M can't find index.html in /var/www/apps/example.com/public
> 4. Mongrel creates a rails process to handle request for /
> 5. Rails, sees example.com host and / path and renders index.html in / 
> var/www/apps/example.com/public
> 6. Mongrel serves /var/www/apps/example.com/public/index.html back
> 
> There's no problem at this point. But bear with me...
> 
> DS is now:
> 
> RAILS_ROOT/public
> RAILS_ROOT/public/index.html
> RAILS_ROOT/public/es
> 
> Steps on 2nd request: http://example.com
> 
> 1. WS: finds index.html in /var/www/apps/example.com/public
> 2. WS serves request
> 
> Again, no problem...just served up previously cached file from same  
> domain.
> 
> 
> DS is still:
> 
> RAILS_ROOT/public
> RAILS_ROOT/public/index.html
> RAILS_ROOT/public/es
> 
> 
> Steps on 3rd request: http://es.example.com
> 
> 1. WS: can't find index.html in /var/www/apps/example.com/public/es <=  
> Note the doc root is different
> 2. WS forwards request to mongrel process (M)
> 3. M finds index.html in /var/www/apps/example.com/public
> 4. Mongrel serves /var/www/apps/example.com/public/index.html which is  
> the page associated with the http://example.com domain.
> 5. This is NOT the required behaviour as it's serving the cached file  
> for http://example.com rather than http://es.example.com as was  
> requested.
> 
> DS is still:
> 
> RAILS_ROOT/public
> RAILS_ROOT/public/index.html
> RAILS_ROOT/public/es
> 
> 
> Alternative 3rd request (http://es.example.com) with * patched mongrel  
> * (mongrel set NOT to serve any static files):
> 
> 1. WS: can't find index.html in /var/www/apps/example.com/public/es
> 2. WS forwards request to mongrel process (M)
> 3. M ignores index.html in /var/www/apps/example.com/public as it  
> directly forwards request to rails
> 4. Mongrel creates a rails process to handle request
> 5. Rails, sees es.example.com host and / path and renders index.html  
> in /var/www/apps/example.com/public/es
> 6. Mongrel serves /var/www/apps/example.com/public/es/index.html back
> 
> DS is now:
> 
> RAILS_ROOT/public
> RAILS_ROOT/public/index.html
> RAILS_ROOT/public/es
> RAILS_ROOT/public/es/index.html
> 
> Note: Now the right page has been served for the right domain. After  
> the file has been cached for http://es.example.com, the WS will  
> happily serve that up.
> 
> Phew, I hope this finally illustrates the problem with more clarity.
> 
> :)
> 
> Regards,
> 
> Saimon
> 
> On Jan 25, 2008, at 3:32 PM, Will Green wrote:
> 
> > SO, it sounds like you have Apache (or another web server) in front  
> > of a pack of Mongrels, which should be serving static files. It  
> > sounds like your front-end web server is passing requests back to  
> > mongrel when this is not your intent. If so, it sounds like you have  
> > a misconfiguration in your front-end web server configuration.
> >
> > Is this the case?
> >
> > ==
> > Will Green
> >
> > Saimon Moore wrote ..
> >> Hi Nathan,
> >>
> >> The problem is that mongrel is serving the static file long before
> >> rails knows anything about it.
> >>
> >> e.g. As I mention in the patch, you have a web server setup with
> >> multiple virtual hosts each mapped to a separate doc root.
> >>
> >> example.com => /var/www/apps/example.com/public
> >>
> >> es.example.com => /var/www/apps/example.com/public/es
> >>
> >> Rails is using page caching and the cache is clean.
> >>
> >> 1st request:
> >>
> >> http://example.com =>
> >>
> >> 1. web server looks for /var/www/apps/example.com/public/index.html
> >> 2. passes request to mongrel which does the same thing, doesn't find
> >> it and calls rails to render it.
> >> 3. Now /var/www/apps/example.com/public/index.html exists as was
> >> cached by rails.
> >>
> >> 2nd request:
> >>
> >> http://es.example.com =>
> >>
> >> 1. web server looks for /var/www/apps/example.com/public/es/ 
> >> index.html
> >> 2. passes request to mongrel which looks for /var/www/apps/ 
> >> example.com/
> >> public/index.html
> >> (which unlike the web server, has only one doc root),
> >> finds the file under /var/www/apps/example.com/public/index.html
> >> (from the previous request) and serves that back before rails has  
> >> even
> >> got a chance to know about it. It has served the wrong file.
> >>
> >> I hope this example makes it clearer.
> >>
> >> With the ability to force mongrel to forward all requests it receives
> >> to rails, on the second request rails (using the host info) would  
> >> then
> >> cache the index.html file into /var/www/apps/example.com/public/es/
> >> index.html.
> >>
> >> As I was writing this, I just thought of another possibility being
> >> writing a custom mongrel handler, but as mongrel_rails is a handler
> >> itself, it seems a bit pointless so I still think my patch has  
> >> merits.
> >>
> >> Thoughts?
> >>
> >> Regards,
> >>
> >> Saimon
> >>
> >>
> >> On Jan 24, 2008, at 4:42 PM, Nathan Vack wrote:
> >>
> >>> On Jan 24, 2008, at 6:13 AM, Saimon Moore wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> I've just added a patch that I'd appreciate some feedback on:
> >>>>
> >>>> http://rubyforge.org/tracker/index.php?
> >>>> func=detail&aid=17446&group_id=1306&atid=5147
> >>>
> >>> I'll admit by cold-addled brain isn't following logic perfectly this
> >>> morning, but I feel like this really would be better handled by the
> >>> upstream HTTP handler giving enough information to your app so it
> >>> serves the right cached file (or runs the right controller, or
> >>> whatever).
> >>>
> >>> I think passing the Host: header along with the request_routing
> >>> plugin (assuming you're on Rails) will make everything happy:
> >>>
> >>> http://agilewebdevelopment.com/plugins/request_routing
> >>>
> >>> Or am I missing something?
> >>>
> >>> -Nate
> >>> _______________________________________________
> >>> Mongrel-users mailing list
> >>> Mongrel-users at rubyforge.org
> >>> http://rubyforge.org/mailman/listinfo/mongrel-users
> >>
> >> -- 
> >> Saimon Moore
> >> Freelance Web Developer
> >> (Available for hire - For details visit http://saimonmoore.net)
> >>
> >> Skype: saimonmoore
> >> Yahoo IM: saimonmoore
> >> Google IM: saimonmoore
> >>
> >>
> >>
> >> _______________________________________________
> >> Mongrel-users mailing list
> >> Mongrel-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/mongrel-users
> >>
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> 
> -- 
> Saimon Moore
> Freelance Web Developer
> (Available for hire - For details visit http://saimonmoore.net)
> 
> Skype: saimonmoore
> Yahoo IM: saimonmoore
> Google IM: saimonmoore
> 
> 
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 

From david at vrensk.com  Fri Jan 25 11:01:51 2008
From: david at vrensk.com (David Vrensk)
Date: Fri, 25 Jan 2008 17:01:51 +0100
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails to force
	mongrel not to serve static files
In-Reply-To: <3E97E4C5-DCBF-4F39-97F6-D38D3FE4AD6B@gmail.com>
References: <1201271575.9263@hotgazpacho.com>
	<3E97E4C5-DCBF-4F39-97F6-D38D3FE4AD6B@gmail.com>
Message-ID: <81b453920801250801t72045547j767450e6437fb10c@mail.gmail.com>

Saimon,

I think you were clear enough the first time, and I don't think anyone can
have missed your point now.

I think your patch is a good idea, and not only because it solves your
problem.  As Zed has pointed out very succinctly a few times, having the app
container serve files is a bad, bad, bad idea.  I daresay that most of us
don't let it do that, or at least we intend to not let it do that, but we
might have made a mistake somewhere.  Now, if your patch was accepted, I
would certainly upgrade my production mongrel configurations to say "do not
serve files", and if I had made a mistake somewhere, I would find out soon
enough.  Fail early, as the Prags would say.

That being said, I haven't checked your actual implementation, so I cannot
vouch for it (as if I could anyway).  But I think it should be (possibly
rewritten and) included in trunk.

Also, there may be another solution to your problem, but I think it's silly:
instead of having the root for example.com be /public, make it /public/com.
Then make your app always use a sub-directory for the generated files.  I
bet it would work, but I like that patch approach better.

Best regards,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080125/ee17bf04/attachment.html 

From saimonmoore at gmail.com  Fri Jan 25 11:09:06 2008
From: saimonmoore at gmail.com (Saimon Moore)
Date: Fri, 25 Jan 2008 17:09:06 +0100
Subject: [Mongrel] #17446 [PATCH] Add option to
	mongrel_rails	to	force	mongrel not to serve static files
In-Reply-To: <1201276389.12391@hotgazpacho.com>
References: <1201276389.12391@hotgazpacho.com>
Message-ID: <CD23AED7-8D82-4DA4-9D2B-936D7FED6CA9@gmail.com>

Yep,you got it.

Since I sent in the ticket I had been thinking about the possibility  
to write a custom mongrel handler (And in fact I'll probably do it)  
but I still think that this patch is of value. If only, to avoid  
people having to write their own custom handlers for each use case  
(though I can't think of any others right now).

Also mongrel_rails is a custom mongrel handler of sorts, so I guess I  
see it as just a patch on that.

But I can live with writing a custon mongrel handler, I just thought  
this tiny patch may come in handy (and save them some time) for others  
when confronted with the same problem.

Regards,

Saimon

On Jan 25, 2008, at 4:53 PM, Will Green wrote:

> Ah, so you have Rails generating a static file.
>
> It looks like you have the same Rails app mounted at two locations.  
> If so, you need to have a way for Nginx to tell Mongrel "hey, this  
> is the same app, but now I need it in Spanish".
>
> Investigate having Nginx pass an environment variable (HTTP header)  
> back to Mongrel. Then create a custom Mongrel handler that searches  
> for the correct index.html file based on that header.
>
> No need to patch Mongrel directly, just extend the existing  
> DirHandler (or write a new one based on the existing one), and  
> register it with Mongrel.
>
> Saimon Moore wrote ..
>> Will,
>>
>> Yes it's the case that a front-end web server (nginx) is sitting in
>> front of the mongrels but no it's not the case that it is  
>> misconfigured.
>>
>> As I hoped my example was illustrating, the web server knows about
>> different virtual hosts but mongrel doesn't.
>>
>>
>> Let me try and give another example with even more detail:
>>
>>
>> Assume:
>>
>> * Mongrel (without patch), which serves any static files it finds in
>> it's doc root (RAILS_ROOT/public)
>>
>> * Web server  (WS) virtual host mapping:
>>
>> *    example.com => /var/www/apps/example.com/public             (web
>> server's doc root for virtual host 1)
>>
>> *    es.example.com => /var/www/apps/example.com/public/es  (web
>> server's doc root for virtual host 2)
>>
>>
>> directory structure (DS) when cache is cleared:
>>
>> RAILS_ROOT/public
>> RAILS_ROOT/public/es
>>
>>
>> Steps on 1st request: http://example.com
>>
>> 1. WS: can't find index.html in /var/www/apps/example.com/public
>> 2. WS forwards request to mongrel process (M)
>> 3. M can't find index.html in /var/www/apps/example.com/public
>> 4. Mongrel creates a rails process to handle request for /
>> 5. Rails, sees example.com host and / path and renders index.html  
>> in /
>> var/www/apps/example.com/public
>> 6. Mongrel serves /var/www/apps/example.com/public/index.html back
>>
>> There's no problem at this point. But bear with me...
>>
>> DS is now:
>>
>> RAILS_ROOT/public
>> RAILS_ROOT/public/index.html
>> RAILS_ROOT/public/es
>>
>> Steps on 2nd request: http://example.com
>>
>> 1. WS: finds index.html in /var/www/apps/example.com/public
>> 2. WS serves request
>>
>> Again, no problem...just served up previously cached file from same
>> domain.
>>
>>
>> DS is still:
>>
>> RAILS_ROOT/public
>> RAILS_ROOT/public/index.html
>> RAILS_ROOT/public/es
>>
>>
>> Steps on 3rd request: http://es.example.com
>>
>> 1. WS: can't find index.html in /var/www/apps/example.com/public/es  
>> <=
>> Note the doc root is different
>> 2. WS forwards request to mongrel process (M)
>> 3. M finds index.html in /var/www/apps/example.com/public
>> 4. Mongrel serves /var/www/apps/example.com/public/index.html which  
>> is
>> the page associated with the http://example.com domain.
>> 5. This is NOT the required behaviour as it's serving the cached file
>> for http://example.com rather than http://es.example.com as was
>> requested.
>>
>> DS is still:
>>
>> RAILS_ROOT/public
>> RAILS_ROOT/public/index.html
>> RAILS_ROOT/public/es
>>
>>
>> Alternative 3rd request (http://es.example.com) with * patched  
>> mongrel
>> * (mongrel set NOT to serve any static files):
>>
>> 1. WS: can't find index.html in /var/www/apps/example.com/public/es
>> 2. WS forwards request to mongrel process (M)
>> 3. M ignores index.html in /var/www/apps/example.com/public as it
>> directly forwards request to rails
>> 4. Mongrel creates a rails process to handle request
>> 5. Rails, sees es.example.com host and / path and renders index.html
>> in /var/www/apps/example.com/public/es
>> 6. Mongrel serves /var/www/apps/example.com/public/es/index.html back
>>
>> DS is now:
>>
>> RAILS_ROOT/public
>> RAILS_ROOT/public/index.html
>> RAILS_ROOT/public/es
>> RAILS_ROOT/public/es/index.html
>>
>> Note: Now the right page has been served for the right domain. After
>> the file has been cached for http://es.example.com, the WS will
>> happily serve that up.
>>
>> Phew, I hope this finally illustrates the problem with more clarity.
>>
>> :)
>>
>> Regards,
>>
>> Saimon
>>
>> On Jan 25, 2008, at 3:32 PM, Will Green wrote:
>>
>>> SO, it sounds like you have Apache (or another web server) in front
>>> of a pack of Mongrels, which should be serving static files. It
>>> sounds like your front-end web server is passing requests back to
>>> mongrel when this is not your intent. If so, it sounds like you have
>>> a misconfiguration in your front-end web server configuration.
>>>
>>> Is this the case?
>>>
>>> ==
>>> Will Green
>>>
>>> Saimon Moore wrote ..
>>>> Hi Nathan,
>>>>
>>>> The problem is that mongrel is serving the static file long before
>>>> rails knows anything about it.
>>>>
>>>> e.g. As I mention in the patch, you have a web server setup with
>>>> multiple virtual hosts each mapped to a separate doc root.
>>>>
>>>> example.com => /var/www/apps/example.com/public
>>>>
>>>> es.example.com => /var/www/apps/example.com/public/es
>>>>
>>>> Rails is using page caching and the cache is clean.
>>>>
>>>> 1st request:
>>>>
>>>> http://example.com =>
>>>>
>>>> 1. web server looks for /var/www/apps/example.com/public/index.html
>>>> 2. passes request to mongrel which does the same thing, doesn't  
>>>> find
>>>> it and calls rails to render it.
>>>> 3. Now /var/www/apps/example.com/public/index.html exists as was
>>>> cached by rails.
>>>>
>>>> 2nd request:
>>>>
>>>> http://es.example.com =>
>>>>
>>>> 1. web server looks for /var/www/apps/example.com/public/es/
>>>> index.html
>>>> 2. passes request to mongrel which looks for /var/www/apps/
>>>> example.com/
>>>> public/index.html
>>>> (which unlike the web server, has only one doc root),
>>>> finds the file under /var/www/apps/example.com/public/index.html
>>>> (from the previous request) and serves that back before rails has
>>>> even
>>>> got a chance to know about it. It has served the wrong file.
>>>>
>>>> I hope this example makes it clearer.
>>>>
>>>> With the ability to force mongrel to forward all requests it  
>>>> receives
>>>> to rails, on the second request rails (using the host info) would
>>>> then
>>>> cache the index.html file into /var/www/apps/example.com/public/es/
>>>> index.html.
>>>>
>>>> As I was writing this, I just thought of another possibility being
>>>> writing a custom mongrel handler, but as mongrel_rails is a handler
>>>> itself, it seems a bit pointless so I still think my patch has
>>>> merits.
>>>>
>>>> Thoughts?
>>>>
>>>> Regards,
>>>>
>>>> Saimon
>>>>
>>>>
>>>> On Jan 24, 2008, at 4:42 PM, Nathan Vack wrote:
>>>>
>>>>> On Jan 24, 2008, at 6:13 AM, Saimon Moore wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I've just added a patch that I'd appreciate some feedback on:
>>>>>>
>>>>>> http://rubyforge.org/tracker/index.php?
>>>>>> func=detail&aid=17446&group_id=1306&atid=5147
>>>>>
>>>>> I'll admit by cold-addled brain isn't following logic perfectly  
>>>>> this
>>>>> morning, but I feel like this really would be better handled by  
>>>>> the
>>>>> upstream HTTP handler giving enough information to your app so it
>>>>> serves the right cached file (or runs the right controller, or
>>>>> whatever).
>>>>>
>>>>> I think passing the Host: header along with the request_routing
>>>>> plugin (assuming you're on Rails) will make everything happy:
>>>>>
>>>>> http://agilewebdevelopment.com/plugins/request_routing
>>>>>
>>>>> Or am I missing something?
>>>>>
>>>>> -Nate
>>>>> _______________________________________________
>>>>> Mongrel-users mailing list
>>>>> Mongrel-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>
>>>> -- 
>>>> Saimon Moore
>>>> Freelance Web Developer
>>>> (Available for hire - For details visit http://saimonmoore.net)
>>>>
>>>> Skype: saimonmoore
>>>> Yahoo IM: saimonmoore
>>>> Google IM: saimonmoore
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mongrel-users mailing list
>>>> Mongrel-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>> -- 
>> Saimon Moore
>> Freelance Web Developer
>> (Available for hire - For details visit http://saimonmoore.net)
>>
>> Skype: saimonmoore
>> Yahoo IM: saimonmoore
>> Google IM: saimonmoore
>>
>>
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- 
Saimon Moore
Freelance Web Developer
(Available for hire - For details visit http://saimonmoore.net)

Skype: saimonmoore
Yahoo IM: saimonmoore
Google IM: saimonmoore




From njvack at wisc.edu  Fri Jan 25 11:39:50 2008
From: njvack at wisc.edu (Nathan Vack)
Date: Fri, 25 Jan 2008 10:39:50 -0600
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails	to	force
	mongrel not to serve static files
In-Reply-To: <3E97E4C5-DCBF-4F39-97F6-D38D3FE4AD6B@gmail.com>
References: <1201271575.9263@hotgazpacho.com>
	<3E97E4C5-DCBF-4F39-97F6-D38D3FE4AD6B@gmail.com>
Message-ID: <9087B47A-1946-4961-978A-4D1DC2CFC2D4@wisc.edu>

On Jan 25, 2008, at 9:34 AM, Saimon Moore wrote:

> Steps on 3rd request: http://es.example.com
>
> 1. WS: can't find index.html in /var/www/apps/example.com/public/es <=
> Note the doc root is different
> 2. WS forwards request to mongrel process (M)
> 3. M finds index.html in /var/www/apps/example.com/public
> 4. Mongrel serves /var/www/apps/example.com/public/index.html which is
> the page associated with the http://example.com domain.
> 5. This is NOT the required behaviour as it's serving the cached file
> for http://example.com rather than http://es.example.com as was
> requested.

Wait... my brain is still missing something; I apologize.

Why isn't nginx sending the stuff from es.example.com to  
mongrel.example.com/es? You don't *need* to send your proxied  
requests to mongrel's root... do you?

I guess you'd need to override the behavior of Rails's url_for() or  
generate routes asymmetrically, which would suck.

My gut (as a non-devteam-member) is that you're doing something a  
little strange, so a custom handler is more sane than patching a  
switch onto Mongrel.

A more interesting proposal would be to say "Mongrel is ONLY an app  
server and doesn't serve static files AT ALL" -- to make it do so  
would require a custom handler. That, however, would be a Big Scary  
Change (TM) and I think users would be... unhappy.

-Nate

From lists at ruby-forum.com  Fri Jan 25 12:06:42 2008
From: lists at ruby-forum.com (Koloa Poipu)
Date: Fri, 25 Jan 2008 18:06:42 +0100
Subject: [Mongrel]
	=?utf-8?q?hi=2C_can_someone_explain_to_me_backgroundrb_?=
	=?utf-8?q?and=09mongrel=3F?=
In-Reply-To: <20080125125445.GA507@cordoba.webit.de>
References: <4ec59202d27a18a8a6b910334d4b4266@ruby-forum.com>
	<20080125125445.GA507@cordoba.webit.de>
Message-ID: <1b92b3369807e7c823c4cb060e22e7ec@ruby-forum.com>

thanks Jens Kraemer and Hemant Kumar!!!

more questions and clarifications if i may...

apache mod proxy balancer buffers requests to pass to the rails app or 
does the proxy pass requests to each mongrel instance? im thinking 
basically when running mongrels, i should be thinking of instances of a 
rails app where there is no root rails app right?

memcache, the cache is loaded in memory, outside the rails app, and not 
duplicated by mongrel instances. each mongrel instance can read from 
that cache?

can workers of the middleman exist on a different physical machine? so 
if the middleman is on his own handler, he can pass off jobs to workers 
someplace else?

to determine how many workers i can have on a box, i would have to 
determine how much load i would like the workers to handle, and how cpu 
intensive is the particular job for the worker?

the middleman buffers jobs in a queue to pass to the next available 
worker?

big question about video site!

a form with a few text fields and a file field for video. when this form 
is submitted, it would be submitted to my rails app and data would be 
saved(title, author, text, video etc...). i then would like to pass the 
video file off to the middleman so he can scedule a worker to 
convert/store the video. now this video, as it is being transferred from 
the client to rails app, is it being uploaded to a rails app directory 
(hence tieing up a mongrel process), or can mongrel pass that incoming 
file quickly to the middleman and then the incoming download is now 
outside the mongrel process so the middleman can start work? ive read 
the mongrel tutorial and i know the conversion can be outside mongrel, 
but i am not too sure about the actual client upload to server 
process...wouldnt that tie up a mongrel?

thanks


















-- 
Posted via http://www.ruby-forum.com/.

From public at misuse.org  Fri Jan 25 12:42:14 2008
From: public at misuse.org (Steve Midgley)
Date: Fri, 25 Jan 2008 09:42:14 -0800
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails to force
 mongrel not to serve static files
In-Reply-To: <mailman.208.1201277360.27928.mongrel-users@rubyforge.org>
References: <mailman.208.1201277360.27928.mongrel-users@rubyforge.org>
Message-ID: <20080125174902.D993415B8022@rubyforge.org>

At 08:09 AM 1/25/2008, mongrel-users-request at rubyforge.org wrote:
>Date: Fri, 25 Jan 2008 17:09:06 +0100
>From: Saimon Moore <saimonmoore at gmail.com>
>Subject: Re: [Mongrel] #17446 [PATCH] Add option 
>to     mongrel_rails   to
>         force   mongrel not to serve static files
>To: mongrel-users at rubyforge.org
>
>Yep,you got it.
>
>Since I sent in the ticket I had been thinking about the possibility
>to write a custom mongrel handler (And in fact I'll probably do it)
>but I still think that this patch is of value. If only, to avoid
>people having to write their own custom handlers for each use case
>(though I can't think of any others right now).
>
>Also mongrel_rails is a custom mongrel handler of sorts, so I guess 
>I
>see it as just a patch on that.
>
>But I can live with writing a custon mongrel handler, I just thought
>this tiny patch may come in handy (and save them some time) for 
>others
>when confronted with the same problem.
>
>Regards,
>
>Saimon

Hi Saimon,

Maybe I'm totally missing the boat here, but couldn't you solve this on 
the Rails end instead? David Vrensk approached this point in his reply 
but maybe I can extend it a bit.

Couldn't you configure your Rails app to become "cache-folder-specific" 
depending on your language locale? So at the top of your Rails app you 
detect what language you're in (based on the incoming site, the route 
or whatever else) and you set your root caching folder appropriately 
from within Rails? So instead of having a default page cache be written 
into:

[rails_root]/public

and a spanish cache written to

[rails_root]/public/es

Why not move the default page cache to (assuming en is default):

[rails_root]/public/en

That way, Mongrel will never find "index.html" in your public root and 
so will just not interfere? You just program nginx to look in 
"[rails_root]/public/en" for your default "www.site.com" hosts and to 
"../public/es" for "es.site.com" - etc..

Am I missing something? I usually am. :) I hope this helps anyway.

Steve

p.s. I don't think your ideas for a Mongrel patch are wrong in any way, 
but I'm just wondering if you can solve this with nginx.conf and Rails 
and leave the Mongrel container out of it completely?


From public at misuse.org  Fri Jan 25 12:42:14 2008
From: public at misuse.org (Steve Midgley)
Date: Fri, 25 Jan 2008 09:42:14 -0800
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails to force
 mongrel not to serve static files
In-Reply-To: <mailman.208.1201277360.27928.mongrel-users@rubyforge.org>
References: <mailman.208.1201277360.27928.mongrel-users@rubyforge.org>
Message-ID: <20080125174902.D68BD15B8021@rubyforge.org>

At 08:09 AM 1/25/2008, mongrel-users-request at rubyforge.org wrote:
>Date: Fri, 25 Jan 2008 17:09:06 +0100
>From: Saimon Moore <saimonmoore at gmail.com>
>Subject: Re: [Mongrel] #17446 [PATCH] Add option 
>to     mongrel_rails   to
>         force   mongrel not to serve static files
>To: mongrel-users at rubyforge.org
>
>Yep,you got it.
>
>Since I sent in the ticket I had been thinking about the possibility
>to write a custom mongrel handler (And in fact I'll probably do it)
>but I still think that this patch is of value. If only, to avoid
>people having to write their own custom handlers for each use case
>(though I can't think of any others right now).
>
>Also mongrel_rails is a custom mongrel handler of sorts, so I guess 
>I
>see it as just a patch on that.
>
>But I can live with writing a custon mongrel handler, I just thought
>this tiny patch may come in handy (and save them some time) for 
>others
>when confronted with the same problem.
>
>Regards,
>
>Saimon

Hi Saimon,

Maybe I'm totally missing the boat here, but couldn't you solve this on 
the Rails end instead? David Vrensk approached this point in his reply 
but maybe I can extend it a bit.

Couldn't you configure your Rails app to become "cache-folder-specific" 
depending on your language locale? So at the top of your Rails app you 
detect what language you're in (based on the incoming site, the route 
or whatever else) and you set your root caching folder appropriately 
from within Rails? So instead of having a default page cache be written 
into:

[rails_root]/public

and a spanish cache written to

[rails_root]/public/es

Why not move the default page cache to (assuming en is default):

[rails_root]/public/en

That way, Mongrel will never find "index.html" in your public root and 
so will just not interfere? You just program nginx to look in 
"[rails_root]/public/en" for your default "www.site.com" hosts and to 
"../public/es" for "es.site.com" - etc..

Am I missing something? I usually am. :) I hope this helps anyway.

Steve

p.s. I don't think your ideas for a Mongrel patch are wrong in any way, 
but I'm just wondering if you can solve this with nginx.conf and Rails 
and leave the Mongrel container out of it completely?


From simon.santoro at gmail.com  Fri Jan 25 13:30:44 2008
From: simon.santoro at gmail.com (Simon Santoro)
Date: Fri, 25 Jan 2008 19:30:44 +0100
Subject: [Mongrel] Apache, proxypass and REMOTE_USER
Message-ID: <200801251930.44299.simon.santoro@gmail.com>

Hello, still trying to get things going.
With proxypass the REMOTE_USER variable set by mod_auth_* is not passed to 
mongrel. I found another admin that has the same problem[1], but no solution. 
Did someone here solve this problem?

[1]http://mail-archives.apache.org/mod_mbox/httpd-users/200610.mbox/<323a37200610021509k6142cb08q6e6b0642e3261c6d%40mail.gmail.com>

From simon.santoro at gmail.com  Fri Jan 25 13:37:57 2008
From: simon.santoro at gmail.com (Simon Santoro)
Date: Fri, 25 Jan 2008 19:37:57 +0100
Subject: [Mongrel] Apache, proxypass and REMOTE_USER
In-Reply-To: <200801251930.44299.simon.santoro@gmail.com>
References: <200801251930.44299.simon.santoro@gmail.com>
Message-ID: <200801251937.57403.simon.santoro@gmail.com>

On Friday 25 January 2008 19:30:44 Simon Santoro wrote:
> Hello, still trying to get things going.
> With proxypass the REMOTE_USER variable set by mod_auth_* is not passed to
> mongrel. I found another admin that has the same problem[1], but no
> solution. Did someone here solve this problem?
>
> [1]http://mail-archives.apache.org/mod_mbox/httpd-users/200610.mbox/<323a37
>200610021509k6142cb08q6e6b0642e3261c6d%40mail.gmail.com>

Sorry for the spam.
http://www.ruby-forum.com/topic/83067

From neongrau at gmail.com  Fri Jan 25 13:40:19 2008
From: neongrau at gmail.com (Ralf Vitasek)
Date: Fri, 25 Jan 2008 19:40:19 +0100
Subject: [Mongrel] Apache, proxypass and REMOTE_USER
In-Reply-To: <200801251930.44299.simon.santoro@gmail.com>
References: <200801251930.44299.simon.santoro@gmail.com>
Message-ID: <CF4DE266-8F6C-4438-8EEB-2E3F42CEE838@gmail.com>


Am 25.01.2008 um 19:30 schrieb Simon Santoro:

> Hello, still trying to get things going.
> With proxypass the REMOTE_USER variable set by mod_auth_* is not  
> passed to
> mongrel. I found another admin that has the same problem[1], but no  
> solution.
> Did someone here solve this problem?
>
> [1]http://mail-archives.apache.org/mod_mbox/httpd-users/200610.mbox/ 
> <323a37200610021509k6142cb08q6e6b0642e3261c6d%40mail.gmail.com>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

hi!

i had the same problem about a year ago, after some looooong research  
i found a working solution (well hidden in the depths of google).

add this to your httpd.conf (within the <proxy> block)


     RewriteEngine On
     RewriteCond %{REMOTE_USER} (.+)
     RewriteRule . - [E=RU:%1]
     RequestHeader set REMOTE_USER %{RU}e


this will add the header to the request that gets forwarded to the  
mongrels.

cheers
ralf


From bostjan at idejaplus.si  Mon Jan 28 09:00:26 2008
From: bostjan at idejaplus.si (Bostjan Potocnik)
Date: Mon, 28 Jan 2008 15:00:26 +0100
Subject: [Mongrel] memory leak ?
Message-ID: <1201528826.1054.5.camel@brain.netio.si>

Hi all,

my mongrel cluster worked as charm for last 3 months, but in last days
some processes are taking all available memory. It goes up to 440Mb per
process. Few hours after restart memory usage starts to climb up and
cluster became unresponsive. 

I'm using rails 2.0.2 and mysql server on freebsd 6.2.

Any ideas why is that happening ?

Thanks,
Bostjan


From lists at ruby-forum.com  Mon Jan 28 10:42:53 2008
From: lists at ruby-forum.com (Anusha Vinod)
Date: Mon, 28 Jan 2008 16:42:53 +0100
Subject: [Mongrel] mongrel_rails not starting
In-Reply-To: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com>
References: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com>
Message-ID: <9d33458ed1ad8a6edd8d510cfaf094d3@ruby-forum.com>

Greg Willits wrote:
> os x 10.4.10
> 
> used gem to install mongrel 1.0.1. seemed to go w/o errors.
> 
> "mongrel_rails start -d" spits out this error
> 
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/http11.bundle:
> Failed to load
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/http11.bundle
> (LoadError)
>         from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `require'
>         from
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:11
>         from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `gem_original_require'
>         from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `require'
>         from
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:9
>         from /usr/local/bin/mongrel_rails:16:in `load'
>         from /usr/local/bin/mongrel_rails:16
> 
> installed again with --include-dependencies
> 
> still getting same error.
> 
> lost. need a flashlight.
> 
> -- gw



Hi,

Im a newbie to ruby and rails. I installed mongrel using the command:

sudo gem install mongrel --include-dependencies

When i try to start mongrel with

mongrel_rails start -d, its throwing the same error as it did to you:


/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in 
`gem_original_require': no such file to load -- http11 (LoadError)
        from 
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in 
`require'
        from 
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.3-java/lib/mongrel.rb:12
        from 
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in 
`gem_original_require'
        from 
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in 
`require'
        from 
/usr/local/lib/ruby/gems/1.8/gems/swiftiply-0.6.1.1/bin/mongrel_rails:17
        from /usr/local/bin/mongrel_rails:19:in `load'
        from /usr/local/bin/mongrel_rails:19


Can you please share some thoughts/experiences...Im not too sure where i 
should be looking into.

Thanks
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Mon Jan 28 11:07:45 2008
From: lists at ruby-forum.com (Anusha Vinod)
Date: Mon, 28 Jan 2008 17:07:45 +0100
Subject: [Mongrel] mongrel_rails not starting
Message-ID: <1a9d37f43d217a1fc71cf4975c556b07@ruby-forum.com>

Hi,

Im a newbie to ruby and rails. I installed mongrel using the command:

sudo gem install mongrel --include-dependencies

When i try to start mongrel with

mongrel_rails start -d, its throwing the same error as it did to you:


/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
`gem_original_require': no such file to load -- http11 (LoadError)
        from
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
`require'
        from
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.3-java/lib/mongrel.rb:12
        from
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
`gem_original_require'
        from
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
`require'
        from
/usr/local/lib/ruby/gems/1.8/gems/swiftiply-0.6.1.1/bin/mongrel_rails:17
        from /usr/local/bin/mongrel_rails:19:in `load'
        from /usr/local/bin/mongrel_rails:19


Can you please share some thoughts/experiences...Im not too sure where i
should be looking into.Any pointers will be greatly appreciated.

Thanks
-- 
Posted via http://www.ruby-forum.com/.

From leccine at gmail.com  Mon Jan 28 15:51:20 2008
From: leccine at gmail.com (Istvan Szukacs)
Date: Mon, 28 Jan 2008 21:51:20 +0100
Subject: [Mongrel] memory leak ?
In-Reply-To: <1201528826.1054.5.camel@brain.netio.si>
References: <1201528826.1054.5.camel@brain.netio.si>
Message-ID: <479E4048.5000004@gmail.com>

hi!

"systat -vmstat" and "vmstat 5" commands could be useful
if this is a mongrel issu we had to know it before,
i guess you have problem in your rails code somewhere

check the changes what did you do in the last days, the answer is there

cheers,
istvan
http://weho.st

Bostjan Potocnik wrote:
> Hi all,
>
> my mongrel cluster worked as charm for last 3 months, but in last days
> some processes are taking all available memory. It goes up to 440Mb per
> process. Few hours after restart memory usage starts to climb up and
> cluster became unresponsive. 
>
> I'm using rails 2.0.2 and mysql server on freebsd 6.2.
>
> Any ideas why is that happening ?
>
> Thanks,
> Bostjan
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>   


From leccine at gmail.com  Mon Jan 28 15:59:27 2008
From: leccine at gmail.com (Istvan Szukacs)
Date: Mon, 28 Jan 2008 21:59:27 +0100
Subject: [Mongrel] mongrel_rails not starting
In-Reply-To: <1a9d37f43d217a1fc71cf4975c556b07@ruby-forum.com>
References: <1a9d37f43d217a1fc71cf4975c556b07@ruby-forum.com>
Message-ID: <479E422F.7030408@gmail.com>

hi!

#gem list mongrel

*** LOCAL GEMS ***

mongrel (1.1.3, 1.1.2, 1.1.1, 1.0.1)
mongrel_cluster (1.0.5)

could you paste here your "gem list mongrel" output

btw. i start my mongrel cluster with mongrel_rails cluster::start
there is a configuration folder in the rails application folder
//this is a sample!
root at dev:rails.app#cat config/mongrel_cluster.yml
---
user: www
cwd: /home/somebody/rails/rails.app
log_file: log/mongrel.log
port: "3002"
environment: production
group: www
address: 127.1.0.3
pid_file: tmp/pids/mongrel.pid
servers: 1

you need something like this

cheeers,
istvan
http://weho.st

Anusha Vinod wrote:
> Hi,
>
> Im a newbie to ruby and rails. I installed mongrel using the command:
>
> sudo gem install mongrel --include-dependencies
>
> When i try to start mongrel with
>
> mongrel_rails start -d, its throwing the same error as it did to you:
>
>
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `gem_original_require': no such file to load -- http11 (LoadError)
>         from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `require'
>         from
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.3-java/lib/mongrel.rb:12
>         from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `gem_original_require'
>         from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `require'
>         from
> /usr/local/lib/ruby/gems/1.8/gems/swiftiply-0.6.1.1/bin/mongrel_rails:17
>         from /usr/local/bin/mongrel_rails:19:in `load'
>         from /usr/local/bin/mongrel_rails:19
>
>
> Can you please share some thoughts/experiences...Im not too sure where i
> should be looking into.Any pointers will be greatly appreciated.
>
> Thanks
>   


From lists at ruby-forum.com  Mon Jan 28 16:35:52 2008
From: lists at ruby-forum.com (Anusha Vinod)
Date: Mon, 28 Jan 2008 22:35:52 +0100
Subject: [Mongrel] mongrel_rails not starting
In-Reply-To: <479E422F.7030408@gmail.com>
References: <1a9d37f43d217a1fc71cf4975c556b07@ruby-forum.com>
	<479E422F.7030408@gmail.com>
Message-ID: <a769ecea856465a6126e9b8107ad4195@ruby-forum.com>

Hi Istvan,

Thanks a lot for replying. I reinstalled mongrel from the link:

http://rubyosx.rubyforge.org

Now when i try to start mongrel, by using script/server, it seems to 
work fine.
And when i say gem list mongrel, i get this output:

*** LOCAL GEMS ***

mongrel (1.1.3, 1.0.1). I do not seem to have the mongrel_cluster gem.


Thanks,
Anusha



Istvan Szukacs wrote:
> hi!
> 
> #gem list mongrel
> 
> *** LOCAL GEMS ***
> 
> mongrel (1.1.3, 1.1.2, 1.1.1, 1.0.1)
> mongrel_cluster (1.0.5)
> 
> could you paste here your "gem list mongrel" output
> 
> btw. i start my mongrel cluster with mongrel_rails cluster::start
> there is a configuration folder in the rails application folder
> //this is a sample!
> root at dev:rails.app#cat config/mongrel_cluster.yml
> ---
> user: www
> cwd: /home/somebody/rails/rails.app
> log_file: log/mongrel.log
> port: "3002"
> environment: production
> group: www
> address: 127.1.0.3
> pid_file: tmp/pids/mongrel.pid
> servers: 1
> 
> you need something like this
> 
> cheeers,
> istvan
> http://weho.st

-- 
Posted via http://www.ruby-forum.com/.

From piyush.pr at gmail.com  Tue Jan 29 02:50:45 2008
From: piyush.pr at gmail.com (Piyush Ranjan)
Date: Tue, 29 Jan 2008 13:20:45 +0530
Subject: [Mongrel] mongrel_rails not starting
In-Reply-To: <1a9d37f43d217a1fc71cf4975c556b07@ruby-forum.com>
References: <1a9d37f43d217a1fc71cf4975c556b07@ruby-forum.com>
Message-ID: <325148f70801282350p1df4523bkb578341ad8ca486d@mail.gmail.com>

Hi Anusha

I am not very sure about this but doesn't this line
*/usr/local/lib/ruby/gems/1.8**/gems/mongrel-1.1.3-java/lib/mongrel.rb:12
       from

*suggest that you have accidentally installed  mongrel for java (jruby) ?


On Jan 28, 2008 9:37 PM, Anusha Vinod <lists at ruby-forum.com> wrote:

> Hi,
>
> Im a newbie to ruby and rails. I installed mongrel using the command:
>
> sudo gem install mongrel --include-dependencies
>
> When i try to start mongrel with
>
> mongrel_rails start -d, its throwing the same error as it did to you:
>
>
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `gem_original_require': no such file to load -- http11 (LoadError)
>        from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `require'
>        from
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.3-java/lib/mongrel.rb:12
>        from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `gem_original_require'
>        from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
> `require'
>        from
> /usr/local/lib/ruby/gems/1.8/gems/swiftiply-0.6.1.1/bin/mongrel_rails:17
>        from /usr/local/bin/mongrel_rails:19:in `load'
>        from /usr/local/bin/mongrel_rails:19
>
>
> Can you please share some thoughts/experiences...Im not too sure where i
> should be looking into.Any pointers will be greatly appreciated.
>
> Thanks
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080129/a1eebfb9/attachment.html 

From saimonmoore at gmail.com  Tue Jan 29 07:16:09 2008
From: saimonmoore at gmail.com (Saimon Moore)
Date: Tue, 29 Jan 2008 13:16:09 +0100
Subject: [Mongrel] #17446 [PATCH] Add option to mongrel_rails to force
	mongrel not to serve static files
In-Reply-To: <20080125174902.D68BD15B8021@rubyforge.org>
References: <mailman.208.1201277360.27928.mongrel-users@rubyforge.org>
	<20080125174902.D68BD15B8021@rubyforge.org>
Message-ID: <D0915009-DCE9-496C-8C85-EA4A0070FA73@gmail.com>

Yep Steve,

You're absolutely right. I certainly can do it like that. I'm just  
dumbfounded why I didn't 'see' this obviously easier path.

So much for my 'reason' :)

In any case, I think  David Vrensk brought up a very valid point about  
mongrel not serving static files at all.

Thanks everyone for your feedback.

Regards,

Saimon


On Jan 25, 2008, at 6:42 PM, Steve Midgley wrote:

> At 08:09 AM 1/25/2008, mongrel-users-request at rubyforge.org wrote:
>> Date: Fri, 25 Jan 2008 17:09:06 +0100
>> From: Saimon Moore <saimonmoore at gmail.com>
>> Subject: Re: [Mongrel] #17446 [PATCH] Add option
>> to     mongrel_rails   to
>>        force   mongrel not to serve static files
>> To: mongrel-users at rubyforge.org
>>
>> Yep,you got it.
>>
>> Since I sent in the ticket I had been thinking about the possibility
>> to write a custom mongrel handler (And in fact I'll probably do it)
>> but I still think that this patch is of value. If only, to avoid
>> people having to write their own custom handlers for each use case
>> (though I can't think of any others right now).
>>
>> Also mongrel_rails is a custom mongrel handler of sorts, so I guess
>> I
>> see it as just a patch on that.
>>
>> But I can live with writing a custon mongrel handler, I just thought
>> this tiny patch may come in handy (and save them some time) for
>> others
>> when confronted with the same problem.
>>
>> Regards,
>>
>> Saimon
>
> Hi Saimon,
>
> Maybe I'm totally missing the boat here, but couldn't you solve this  
> on
> the Rails end instead? David Vrensk approached this point in his reply
> but maybe I can extend it a bit.
>
> Couldn't you configure your Rails app to become "cache-folder- 
> specific"
> depending on your language locale? So at the top of your Rails app you
> detect what language you're in (based on the incoming site, the route
> or whatever else) and you set your root caching folder appropriately
> from within Rails? So instead of having a default page cache be  
> written
> into:
>
> [rails_root]/public
>
> and a spanish cache written to
>
> [rails_root]/public/es
>
> Why not move the default page cache to (assuming en is default):
>
> [rails_root]/public/en
>
> That way, Mongrel will never find "index.html" in your public root and
> so will just not interfere? You just program nginx to look in
> "[rails_root]/public/en" for your default "www.site.com" hosts and to
> "../public/es" for "es.site.com" - etc..
>
> Am I missing something? I usually am. :) I hope this helps anyway.
>
> Steve
>
> p.s. I don't think your ideas for a Mongrel patch are wrong in any  
> way,
> but I'm just wondering if you can solve this with nginx.conf and Rails
> and leave the Mongrel container out of it completely?
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- 
Saimon Moore
Freelance Web Developer
(Available for hire - For details visit http://saimonmoore.net)

Skype: saimonmoore
Yahoo IM: saimonmoore
Google IM: saimonmoore




From lists at ruby-forum.com  Tue Jan 29 10:16:33 2008
From: lists at ruby-forum.com (Anusha Vinod)
Date: Tue, 29 Jan 2008 16:16:33 +0100
Subject: [Mongrel] mongrel_rails not starting
In-Reply-To: <325148f70801282350p1df4523bkb578341ad8ca486d@mail.gmail.com>
References: <1a9d37f43d217a1fc71cf4975c556b07@ruby-forum.com>
	<325148f70801282350p1df4523bkb578341ad8ca486d@mail.gmail.com>
Message-ID: <081753b578ecd29a33682bb1d1e56932@ruby-forum.com>

Piyush Ranjan wrote:
> Hi Anusha
> 
> I am not very sure about this but doesn't this line
> */usr/local/lib/ruby/gems/1.8**/gems/mongrel-1.1.3-java/lib/mongrel.rb:12
>        from
> 
> *suggest that you have accidentally installed  mongrel for java (jruby) 
> ?



Hi Piyush,

I'm not sure either! Im a newbie to ruby and rails stuff...when i say
mongrel_rails start from my rails project root, it starts without any 
problems.
Also, can you please let me know what version of mongrel is compatible 
with swiftiply-0.6.1.1 in case you have any idea about it?

I seem to have multiple versions installed

 mongrel-1.0.1
 mongrel-1.1.3
mongrel-1.1.3-java

Thanks,
Anusha


-- 
Posted via http://www.ruby-forum.com/.

From piyush.pr at gmail.com  Tue Jan 29 11:00:44 2008
From: piyush.pr at gmail.com (Piyush Ranjan)
Date: Tue, 29 Jan 2008 21:30:44 +0530
Subject: [Mongrel] mongrel_rails not starting
In-Reply-To: <081753b578ecd29a33682bb1d1e56932@ruby-forum.com>
References: <1a9d37f43d217a1fc71cf4975c556b07@ruby-forum.com>
	<325148f70801282350p1df4523bkb578341ad8ca486d@mail.gmail.com>
	<081753b578ecd29a33682bb1d1e56932@ruby-forum.com>
Message-ID: <325148f70801290800x49c71a00j35590fb628fff38a@mail.gmail.com>

mongrel-1.1.3-java
I think that's where the problem is. Can you uninstall by *gem uninstall
mongrel-1.1.3-java
*I don't have elegant solution right now.


On Jan 29, 2008 8:46 PM, Anusha Vinod <lists at ruby-forum.com> wrote:

> Piyush Ranjan wrote:
> > Hi Anusha
> >
> > I am not very sure about this but doesn't this line
> > */usr/local/lib/ruby/gems/1.8**/gems/mongrel-1.1.3-java
> /lib/mongrel.rb:12
> >        from
> >
> > *suggest that you have accidentally installed  mongrel for java (jruby)
> > ?
>
>
>
> Hi Piyush,
>
> I'm not sure either! Im a newbie to ruby and rails stuff...when i say
> mongrel_rails start from my rails project root, it starts without any
> problems.
> Also, can you please let me know what version of mongrel is compatible
> with swiftiply-0.6.1.1 in case you have any idea about it?
>
> I seem to have multiple versions installed
>
>  mongrel-1.0.1
>  mongrel-1.1.3
> mongrel-1.1.3-java
>
> Thanks,
> Anusha
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080129/5b7e1b7b/attachment.html 

From johnjosephbachir at gmail.com  Tue Jan 29 12:02:08 2008
From: johnjosephbachir at gmail.com (John Joseph Bachir)
Date: Tue, 29 Jan 2008 12:02:08 -0500
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <f4cd26df0801220707q50bc8e97qcc19da2502e8a166@mail.gmail.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
	<f4cd26df0801220707q50bc8e97qcc19da2502e8a166@mail.gmail.com>
Message-ID: <4a3752180801290902u18b2bde3ye78f4d92315b60de@mail.gmail.com>

On Jan 22, 2008 10:07 AM, Kirk Haines <wyhaines at gmail.com> wrote:
> On Jan 22, 2008 7:46 AM, John Almberg <jalmberg at identry.com> wrote:
> > I am running a number of Rails apps on a quite powerful server (dual
> > quad-core xeons, 8G ram, raid 10) running FreeBSD. I'm using a fairly
> > simple software stack: Apache22, mod_proxy, and a single mongrel
> > instance for each website. Apache is serving all static content.
> .
> > The websites are extremely fast-loading, apparently very stable
> > (nothing has failed in the month or so since I've switched over from
> > a FastCGI setup), and I love the simplicity.
>
> I concur.
>
> > My question: This was supposed to be a first step towards using a
> > mongrel cluster, but the single mongrel instance seems to work
> > perfectly fine. Can I keep using it, as long as the loads stay at
> > modest levels? I don't want to move to a more complex set up just
> > because it would be cool or fun to do. If a single instance will do
> > the job, then simple is better, IMHO.
>
> You can absolutely keep running things that way.  I've ran the same
> sort of sites for years, and the vast majority of them have been done
> is exactly that way.  It works just fine, and IMHO, more people should
> be deploying Rails apps in that sort of simple manner.

This is an interesting discussion. The conclusions are a bit confusing
to me. John-- you say that your sites get a few thousand hits a day.
With only one mongrel, can't the system only serve one request at a
time? It seems like, independent of system performance, just the fact
that the requests have to be done sequentially would have a big hit on
the performance on the site.

Is this not the case, that with one mongrel, only one request can be
served at a time?

John


-- 
John Joseph Bachir
http://blog.johnjosephbachir.org
http://lyceum.ibiblio.org
http://dissent.cc
http://jjb.cc

From lists at ruby-forum.com  Tue Jan 29 12:04:48 2008
From: lists at ruby-forum.com (Anusha Vinod)
Date: Tue, 29 Jan 2008 18:04:48 +0100
Subject: [Mongrel] mongrel_rails not starting
In-Reply-To: <325148f70801290800x49c71a00j35590fb628fff38a@mail.gmail.com>
References: <1a9d37f43d217a1fc71cf4975c556b07@ruby-forum.com>
	<325148f70801282350p1df4523bkb578341ad8ca486d@mail.gmail.com>
	<081753b578ecd29a33682bb1d1e56932@ruby-forum.com>
	<325148f70801290800x49c71a00j35590fb628fff38a@mail.gmail.com>
Message-ID: <1ca66680035dda3219c9ffad30ffb8c7@ruby-forum.com>

Piyush Ranjan wrote:
> mongrel-1.1.3-java
> I think that's where the problem is. Can you uninstall by *gem uninstall
> mongrel-1.1.3-java
> *I don't have elegant solution right now.


ok...shall try doing that..
-- 
Posted via http://www.ruby-forum.com/.

From public at misuse.org  Tue Jan 29 12:28:50 2008
From: public at misuse.org (Steve Midgley)
Date: Tue, 29 Jan 2008 09:28:50 -0800
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <mailman.224.1201626130.28292.mongrel-users@rubyforge.org>
References: <mailman.224.1201626130.28292.mongrel-users@rubyforge.org>
Message-ID: <20080129172903.032DD185866A@rubyforge.org>

At 09:02 AM 1/29/2008, mongrel-users-request at rubyforge.org wrote:
> >
> > You can absolutely keep running things that way.  I've ran the same
> > sort of sites for years, and the vast majority of them have been 
> done
> > is exactly that way.  It works just fine, and IMHO, more people 
> should
> > be deploying Rails apps in that sort of simple manner.
>
>This is an interesting discussion. The conclusions are a bit confusing
>to me. John-- you say that your sites get a few thousand hits a day.
>With only one mongrel, can't the system only serve one request at a
>time? It seems like, independent of system performance, just the fact
>that the requests have to be done sequentially would have a big hit on
>the performance on the site.
>
>Is this not the case, that with one mongrel, only one request can be
>served at a time?
>
>John

Hi John,

Rails can only run one request at a time. So if you're running a stack 
that includes Mongrel and Rails, then, yes, Mongrel will be reduced to 
blocking and waiting for Rails to return before sending another request 
through the pipe (effectively making Mongrel single threaded too). If 
you had a truly multi-threaded app framework, then mongrel would 
happily support multiple calls simultaneously into it.

 From my understanding Mongrel is like Apache and Nginx, in that if you 
increase load on it, it will increase performance up to the limits of 
the hardware upon which it runs.

Rails on the other hand has other limitations. :)

Other people with more expertise may have better information but I 
believe that's basically the sitch.

Steve


From wyhaines at gmail.com  Tue Jan 29 12:43:15 2008
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 29 Jan 2008 10:43:15 -0700
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <4a3752180801290902u18b2bde3ye78f4d92315b60de@mail.gmail.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
	<f4cd26df0801220707q50bc8e97qcc19da2502e8a166@mail.gmail.com>
	<4a3752180801290902u18b2bde3ye78f4d92315b60de@mail.gmail.com>
Message-ID: <f4cd26df0801290943u18ee2d74l8a943e2b97d0c89@mail.gmail.com>

On Jan 29, 2008 10:02 AM, John Joseph Bachir <johnjosephbachir at gmail.com> wrote:
> This is an interesting discussion. The conclusions are a bit confusing
> to me. John-- you say that your sites get a few thousand hits a day.
> With only one mongrel, can't the system only serve one request at a
> time? It seems like, independent of system performance, just the fact
> that the requests have to be done sequentially would have a big hit on
> the performance on the site.
>
> Is this not the case, that with one mongrel, only one request can be
> served at a time?

It's not quite as cut and dried an issue as that because while there
are a variety of threaded, nonthreaded, and event based combinations
among different frameworks and app container choices, Ruby 1.8's
threading is via green threads anyway

However, for sake of argument, let's just say that the answer is
"yes".  Only one request can be served at a time.

It becomes a question of how long it takes for an application to serve
a request.  And for, I think, the _vast_ majority of the typical
business oriented dynamic web site, if properly built, the answer
should be "not long at all."

My absolute slowest sites, on my slowest server, still have a capacity
of 6-10 requests/second, and I wouldn't tolerate that performance if I
were building those sites today instead of 5 years ago.

6 requests per second means that if it is pushed to it's limit for
even one hour, it has served more than 21000 requests in that hour.
Even if it were a lethargically slow 1 request/second, that's a
capacity of 3600 requests in an hour, and that capacity easily meets
the needs of the common business site.

The fastest sites on this same slowest server that are 100%
dynamically rendered, and which perform database transactions with
every request can turn about 130 r/s, peak.  This is a several year
old 32 bit Athlon based Linux box proxying through Apache.

And just to prove a point, here are a couple timings from a couple
different sites on one of my faster servers, which is a newer 3.0 Ghz
Xeon based Linux box proxying through Swiftiply:

First, a "normal" business site, with all content and navigation
dynamically rendered (it is managed by a CMS and stored in a database
table):

Requests per second:    436.87 [#/sec] (mean)

Second, a "fast" site.  All of the requests are still dynamic template
renderings, but it has been tuned to be fast:

Requests per second:    1167.21 [#/sec] (mean)


Even if one's app is so slow that it can only render a handful of
pages per second, there is still a vast, expansive forest of sites and
apps where that performance, on a single process, is more than
adequate for even the heaviest traffic that the site will get.  That
performance will still serve thousands to tens of thousands of people
per day.


Kirk Haines

From jalmberg at identry.com  Tue Jan 29 13:48:06 2008
From: jalmberg at identry.com (John Almberg)
Date: Tue, 29 Jan 2008 13:48:06 -0500
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <f4cd26df0801290943u18ee2d74l8a943e2b97d0c89@mail.gmail.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
	<f4cd26df0801220707q50bc8e97qcc19da2502e8a166@mail.gmail.com>
	<4a3752180801290902u18b2bde3ye78f4d92315b60de@mail.gmail.com>
	<f4cd26df0801290943u18ee2d74l8a943e2b97d0c89@mail.gmail.com>
Message-ID: <1FAB03DF-6A5F-46E8-A622-047757C4958A@identry.com>


On Jan 29, 2008, at 12:43 PM, Kirk Haines wrote:

> On Jan 29, 2008 10:02 AM, John Joseph Bachir  
> <johnjosephbachir at gmail.com> wrote:
>> This is an interesting discussion. The conclusions are a bit  
>> confusing
>> to me. John-- you say that your sites get a few thousand hits a day.
>> With only one mongrel, can't the system only serve one request at a
>> time? It seems like, independent of system performance, just the fact
>> that the requests have to be done sequentially would have a big  
>> hit on
>> the performance on the site.
>>
>> Is this not the case, that with one mongrel, only one request can be
>> served at a time?
>
>
> However, for sake of argument, let's just say that the answer is
> "yes".  Only one request can be served at a time.
>
> It becomes a question of how long it takes for an application to serve
> a request.  And for, I think, the _vast_ majority of the typical
> business oriented dynamic web site, if properly built, the answer
> should be "not long at all."
>

Kirk beat me to the answer, but my answer is the same.

While this might be a theoretical problem, it's not an actual  
problem. Particularly since mongrel is only serving up the first  
request of each page view -- the HTML. Apache handles subsequent  
requests for images, javascript, css files, etc.

So even in the rare case of simultaneous page requests, the second  
request would only have to wait milliseconds.

Again, this wouldn't work for eBay, but it works fine for my size  
clients.

-- John


From erik.hetzner at ucop.edu  Tue Jan 29 14:19:12 2008
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Tue, 29 Jan 2008 11:19:12 -0800
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <1FAB03DF-6A5F-46E8-A622-047757C4958A@identry.com>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
	<f4cd26df0801220707q50bc8e97qcc19da2502e8a166@mail.gmail.com>
	<4a3752180801290902u18b2bde3ye78f4d92315b60de@mail.gmail.com>
	<f4cd26df0801290943u18ee2d74l8a943e2b97d0c89@mail.gmail.com>
	<1FAB03DF-6A5F-46E8-A622-047757C4958A@identry.com>
Message-ID: <878x28samn.wl%erik.hetzner@ucop.edu>

At Tue, 29 Jan 2008 13:48:06 -0500,
John Almberg <jalmberg at identry.com> wrote:
> Kirk beat me to the answer, but my answer is the same.
>
> While this might be a theoretical problem, it's not an actual
> problem. Particularly since mongrel is only serving up the first
> request of each page view -- the HTML. Apache handles subsequent
> requests for images, javascript, css files, etc.
>
> So even in the rare case of simultaneous page requests, the second
> request would only have to wait milliseconds.
>
> Again, this wouldn't work for eBay, but it works fine for my size
> clients.

A word of caution. If you are do not test your app in a setup in which
requests are not sequential, you will (will, not might) run into
concurrency issues if you need to transfer to a multiple-process or
multi-threaded setup.

best,
Erik Hetzner
-------------- next part --------------
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20080129/c4f8bed7/attachment.bin 

From jalmberg at identry.com  Tue Jan 29 18:00:54 2008
From: jalmberg at identry.com (John Almberg)
Date: Tue, 29 Jan 2008 18:00:54 -0500
Subject: [Mongrel] Do I really need a cluster?
In-Reply-To: <878x28samn.wl%erik.hetzner@ucop.edu>
References: <4a3752180801211105u12e206ahe81e120b971cfc22@mail.gmail.com>
	<6FF08D29-4A45-4B08-BBFB-859C181C6F33@cheney.net>
	<5BC39FD9-E366-46B1-8BA1-30CFCA587CC5@identry.com>
	<f4cd26df0801220707q50bc8e97qcc19da2502e8a166@mail.gmail.com>
	<4a3752180801290902u18b2bde3ye78f4d92315b60de@mail.gmail.com>
	<f4cd26df0801290943u18ee2d74l8a943e2b97d0c89@mail.gmail.com>
	<1FAB03DF-6A5F-46E8-A622-047757C4958A@identry.com>
	<878x28samn.wl%erik.hetzner@ucop.edu>
Message-ID: <D28086BC-8ED8-42C0-8F6B-B556604CF43A@identry.com>


On Jan 29, 2008, at 2:19 PM, Erik Hetzner wrote:

> At Tue, 29 Jan 2008 13:48:06 -0500,
> John Almberg <jalmberg at identry.com> wrote:
>> Kirk beat me to the answer, but my answer is the same.
>>
>> While this might be a theoretical problem, it's not an actual
>> problem. Particularly since mongrel is only serving up the first
>> request of each page view -- the HTML. Apache handles subsequent
>> requests for images, javascript, css files, etc.
>>
>> So even in the rare case of simultaneous page requests, the second
>> request would only have to wait milliseconds.
>>
>> Again, this wouldn't work for eBay, but it works fine for my size
>> clients.
>
> A word of caution. If you are do not test your app in a setup in which
> requests are not sequential, you will (will, not might) run into
> concurrency issues if you need to transfer to a multiple-process or
> multi-threaded setup.

H'mmm... I'm afraid this is a bit over my head. Can you elaborate?

-- John


From lists at ruby-forum.com  Wed Jan 30 01:35:39 2008
From: lists at ruby-forum.com (Vapor ..)
Date: Wed, 30 Jan 2008 07:35:39 +0100
Subject: [Mongrel] mongrel_service install error
Message-ID: <0b9591814f07b8b58bfaf352f60afde8@ruby-forum.com>

when I run 'gem install mongrel_service'..it gives following error...

Building native extensions.  This could take a while...
ERROR:  Error installing mongrel_service:
        ERROR: Failed to build gem native extension.

c:/ruby/bin/ruby.exe extconf.rb install mongrel_service
checking for RegisterServiceCtrlHandlerEx()... no
checking for EnumServicesStatusEx()... no
checking for QueryServiceStatusEx()... no
creating Makefile


Gem files will remain installed in
c:/ruby/lib/ruby/gems/1.8/gems/win32-service-
0.5.2 for inspection.
Results logged to
c:/ruby/lib/ruby/gems/1.8/gems/win32-service-0.5.2/gem_make.out
-- 
Posted via http://www.ruby-forum.com/.

From luislavena at gmail.com  Wed Jan 30 05:10:23 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 30 Jan 2008 08:10:23 -0200
Subject: [Mongrel] mongrel_service install error
In-Reply-To: <0b9591814f07b8b58bfaf352f60afde8@ruby-forum.com>
References: <0b9591814f07b8b58bfaf352f60afde8@ruby-forum.com>
Message-ID: <71166b3b0801300210o2371b540ye538bd2142125cac@mail.gmail.com>

On Jan 30, 2008 4:35 AM, Vapor .. <lists at ruby-forum.com> wrote:
> when I run 'gem install mongrel_service'..it gives following error...
>
> Building native extensions.  This could take a while...
> ERROR:  Error installing mongrel_service:
>         ERROR: Failed to build gem native extension.
>
> c:/ruby/bin/ruby.exe extconf.rb install mongrel_service
> checking for RegisterServiceCtrlHandlerEx()... no
> checking for EnumServicesStatusEx()... no
> checking for QueryServiceStatusEx()... no
> creating Makefile
>

it seems you're running version 0.9.5 of RubyGems, please update to
1.0.1 and uninstall the offending gems.

I've described this issue in a blog post:

http://blog.mmediasys.com/2007/12/19/latest-rubygems-and-rails-is-a-deadly-combo/

And a few times on ruby-talk:

http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/a594343b8ada2cc3

HTH,
-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

From doctor.jw at gmail.com  Wed Jan 30 17:17:24 2008
From: doctor.jw at gmail.com (John Woodward)
Date: Wed, 30 Jan 2008 16:17:24 -0600
Subject: [Mongrel] Not all mongrel starting (Errno:EEXIST)
In-Reply-To: <92636E8B291DE247A4072BDEE7D20C5C06656A3C@NSTMC104PEX1.ubsw.net>
References: <92636E8B291DE247A4072BDEE7D20C5C06656A3C@NSTMC104PEX1.ubsw.net>
Message-ID: <7f1ee36d0801301417x5bd116b7sfa4a670d0a192c8d@mail.gmail.com>

I'm playing with the mongrel clustering, and am having a problem getting 2
mongrels to start up reliably.

This should be a pretty simple cluster, with just 2 instances running. My
mongrel config (mongrel_cluster.yml) looks like:

cwd: /deployment/installed/myapp/current
log_file: log/mongrel.log
port: "8000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 2

When I start up the pack with the command:

mongrel_rails cluster::start -C
/deployment/installed/myapp/current/config/mongrel_cluster.yml

I see (with a quick ps) two mongrels, one of which then dies with the follow
error in the log file:

** Daemonized, any open files are closed.  Look at tmp/pids/mongrel.8000.pid
and log/mongrel.8000.log for info.
** Starting Mongrel listening at 127.0.0.1:8000
** Starting Rails with production environment...
deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:243:in `mkdir': File
exists - /deployment/installed/myapp/releases/20080130211150/public/bundles
(Errno::EEXIST)

        from /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:243:in
`fu_mkdir'
        from /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:172:in
`mkdir'
        from /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:171:in
`each'
        from /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:171:in
`mkdir'
        from
/deployment/installed/myapp/releases/20080130211150/vendor/plugins/bundled_resource-
0.9/lib/bundled_resource.rb:38:in `create_public_bundle_directory'

        from /deployment/installed/myapp/
/releases/20080130211150/vendor/plugins/bundled_resource-0.9/init.rb:57:in
`evaluate_init_rb'

        from deployment/installed/ruby/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/rails/plugin.rb:79:in
`evaluate_init_rb'
        from
/deployment/installed/ruby/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/core_ext/kernel/reporting.rb:11:in
`silence_warnings'

         ... 21 levels...
        from /deployment/installed/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.3/bin/../lib/mongrel/command.rb:212:in
`run'
        from /deployment/installed/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.3
/bin/mongrel_rails:281
        from /deployment/installed/ruby/bin/mongrel_rails:19:in `load'
        from /deployment/installed/ruby/bin/mongrel_rails:19

It looks to me as if both mongrels are starting up, but the deployment of
the "bundled_resource" from each mongrel is ending up with the app stomping
on itself.

I've not found any indication of a similar problem searching the net, or the
forums (or the bug tracker).
Has anybody else seen similar behavior? Is there  a workaround available?

 Thanks!

john

BTW: my currently isntalled gems include:

bash-2.05b$ gem list

*** LOCAL GEMS ***

actionmailer (2.0.2)
actionpack (2.0.2)
activerecord (2.0.2)
activeresource (2.0.2)
activesupport (2.0.2)
capistrano (2.1.0)
cgi_multipart_eof_fix (2.5.0)
daemons (1.0.9)
fastthread (1.0.1)
gem_plugin (0.2.3)
highline (1.4.0)
mongrel (1.1.3)
mongrel_cluster (1.0.5)
needle (1.3.0)
net-sftp (1.1.0)
net-ssh (1.1.2)
rails (2.0.2)
rake (0.8.1)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080130/b30109e3/attachment-0001.html 

From john.jian.fang at gmail.com  Wed Jan 30 22:01:30 2008
From: john.jian.fang at gmail.com (Jian Fang)
Date: Wed, 30 Jan 2008 22:01:30 -0500
Subject: [Mongrel] Production problem for mongrel
Message-ID: <ebb5a7c40801301901t40baf655o5abc37e53e4a8674@mail.gmail.com>

Hi,

I am working on deplying my Rail app to QA and then move to production.
Since on our QA servers, there is no internet access and also for production
servers, internet access is strictly prohibited.
As a result, there is no way to install mongrel by use "gem install mongrel"
command.

The first option I tried is to put mongrel and all other gems under the
vendor directly in my app, but seems the command "ruby script/server" cannot
find mongrel.

The second option I tried is to download the tar ball and run "ruby
setup.rball". The process finished fine. Type "which mongrel_rails"
and show
"/usr/local/bin/mongrel_rails".
However, when I run the command " mongrel_rails start", it showed  the
following errors:

 /usr/local/bin/mongrel_rails: line 7: require: command not found
/usr/local/bin/mongrel_rails: line 8: require: command not found
/usr/local/bin/mongrel_rails: line 10: .unshift: command not found
/usr/local/bin/mongrel_rails: line 11: require: command not found
/usr/local/bin/mongrel_rails: line 12: require: command not found
/usr/local/bin/mongrel_rails: line 14: Mongrel::Gems.require: command not
found
/usr/local/bin/mongrel_rails: line 19: module: command not found
/usr/local/bin/mongrel_rails: line 20: GemPlugin::Plugin: No such file or
directory
/usr/local/bin/mongrel_rails: line 21: include: command not found
/usr/local/bin/mongrel_rails: line 23: def: command not found
/usr/local/bin/mongrel_rails: line 24: options: command not found
/usr/local/bin/mongrel_rails: line 25: [-e,: command not found
/usr/local/bin/mongrel_rails: line 25: development],: command not found
....

Then, I tried  "ruby script/server". It  showed the following errors:

/opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:489:in
`load': no such file to load -- mongrel_rails (MissingSourceFile)
        from
/opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:489:in
`load'
        from
/opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:342:in
`new_constants_in'
        from
/opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:489:in
`load'
        from
/opt/AddressRubyClient/vendor/rails/railties/lib/commands/servers/mongrel.rb:64
        from
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require'
        from
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from
/opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:496:in
`require'
        from
/opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:342:in
`new_constants_in'
        from
/opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:496:in
`require'
        from
/opt/AddressRubyClient/vendor/rails/railties/lib/commands/server.rb:39
        from script/server:3:in `require'
        from script/server:3


The QA server is running Redhat EL4 X86_64 version of linux. And I installed
Ruby 1.8.6 and rails 2.0.2.

I really appreciate if someone could help me with this issue.

Thanks in advance,

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080130/c160ea78/attachment.html 

From will at hotgazpacho.com  Wed Jan 30 22:17:05 2008
From: will at hotgazpacho.com (Will Green)
Date: Wed, 30 Jan 2008 22:17:05 -0500
Subject: [Mongrel] Not all mongrel starting (Errno:EEXIST)
In-Reply-To: <7f1ee36d0801301417x5bd116b7sfa4a670d0a192c8d@mail.gmail.com>
References: <92636E8B291DE247A4072BDEE7D20C5C06656A3C@NSTMC104PEX1.ubsw.net>
	<7f1ee36d0801301417x5bd116b7sfa4a670d0a192c8d@mail.gmail.com>
Message-ID: <47A13DB1.2030702@hotgazpacho.com>

Sounds like an issue with the bundled_resource plugin, not mongrel.

The plugin should probably be checking for the existence of a directory 
before trying to create it.

==
Will Green

John Woodward wrote:
>
> I'm playing with the mongrel clustering, and am having a problem 
> getting 2 mongrels to start up reliably.
>
> This should be a pretty simple cluster, with just 2 instances running. 
> My mongrel config (mongrel_cluster.yml) looks like:
>
> cwd: /deployment/installed/myapp/current
> log_file: log/mongrel.log
> port: "8000"
> environment: production
> address: 127.0.0.1 <http://127.0.0.1>
> pid_file: tmp/pids/mongrel.pid
> servers: 2
>
> When I start up the pack with the command:
>
> mongrel_rails cluster::start -C 
> /deployment/installed/myapp/current/config/mongrel_cluster.yml
>
> I see (with a quick ps) two mongrels, one of which then dies with the 
> follow error in the log file:
>
>
> ** Daemonized, any open files are closed.  Look at 
> tmp/pids/mongrel.8000.pid and log/mongrel.8000.log for info.
> ** Starting Mongrel listening at 127.0.0.1:8000 <http://127.0.0.1:8000>
> ** Starting Rails with production environment...
> deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:243:in `mkdir': 
> File exists - 
> /deployment/installed/myapp/releases/20080130211150/public/bundles 
> (Errno::EEXIST)
>
>         from 
> /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:243:in `fu_mkdir'
>         from 
> /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:172:in `mkdir'
>         from 
> /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:171:in `each'
>         from 
> /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:171:in `mkdir'
>         from 
> /deployment/installed/myapp/releases/20080130211150/vendor/plugins/bundled_resource-0.9/lib/bundled_resource.rb:38:in 
> `create_public_bundle_directory'
>
>         from 
> /deployment/installed/myapp//releases/20080130211150/vendor/plugins/bundled_resource-0.9/init.rb:57:in 
> `evaluate_init_rb'
>
>         from 
> deployment/installed/ruby/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/rails/plugin.rb:79:in 
> `evaluate_init_rb'
>         from 
> /deployment/installed/ruby/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/core_ext/kernel/reporting.rb:11:in 
> `silence_warnings'
>
>          ... 21 levels...
>         from 
> /deployment/installed/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.3/bin/../lib/mongrel/command.rb:212:in 
> `run'
>         from 
> /deployment/installed/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.3/bin/mongrel_rails:281 
>
>         from /deployment/installed/ruby/bin/mongrel_rails:19:in `load'
>         from /deployment/installed/ruby/bin/mongrel_rails:19
>
>
> It looks to me as if both mongrels are starting up, but the deployment 
> of the "bundled_resource" from each mongrel is ending up with the app 
> stomping on itself.
>
> I've not found any indication of a similar problem searching the net, 
> or the forums (or the bug tracker).
>
> Has anybody else seen similar behavior? Is there  a workaround available?
>
> Thanks!
>
> john
>
>
> BTW: my currently isntalled gems include:
>
> bash-2.05b$ gem list
>
> *** LOCAL GEMS ***
>
> actionmailer (2.0.2)
> actionpack (2.0.2)
> activerecord (2.0.2)
> activeresource (2.0.2)
> activesupport (2.0.2)
> capistrano (2.1.0)
> cgi_multipart_eof_fix (2.5.0)
> daemons (1.0.9)
> fastthread (1.0.1)
> gem_plugin (0.2.3)
> highline (1.4.0)
> mongrel (1.1.3)
> mongrel_cluster (1.0.5)
> needle (1.3.0)
> net-sftp (1.1.0)
> net-ssh (1.1.2)
> rails (2.0.2)
> rake (0.8.1)
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From rgo at aspgems.com  Thu Jan 31 04:21:48 2008
From: rgo at aspgems.com (Rafael G.)
Date: Thu, 31 Jan 2008 10:21:48 +0100
Subject: [Mongrel] Not all mongrel starting (Errno:EEXIST)
In-Reply-To: <7f1ee36d0801301417x5bd116b7sfa4a670d0a192c8d@mail.gmail.com>
References: <92636E8B291DE247A4072BDEE7D20C5C06656A3C@NSTMC104PEX1.ubsw.net>
	<7f1ee36d0801301417x5bd116b7sfa4a670d0a192c8d@mail.gmail.com>
Message-ID: <47A1932C.8060904@aspgems.com>

I used bundled resources sometimes ago and I have same problem (I think).

I read init.rb and I commented lines 54..57 (create bundle directory and 
copy resources).

Regards!

John Woodward escribi?:
>
> I'm playing with the mongrel clustering, and am having a problem 
> getting 2 mongrels to start up reliably.
>
> This should be a pretty simple cluster, with just 2 instances running. 
> My mongrel config (mongrel_cluster.yml) looks like:
>
> cwd: /deployment/installed/myapp/current
> log_file: log/mongrel.log
> port: "8000"
> environment: production
> address: 127.0.0.1 <http://127.0.0.1>
> pid_file: tmp/pids/mongrel.pid
> servers: 2
>
> When I start up the pack with the command:
>
> mongrel_rails cluster::start -C 
> /deployment/installed/myapp/current/config/mongrel_cluster.yml
>
> I see (with a quick ps) two mongrels, one of which then dies with the 
> follow error in the log file:
>
>
> ** Daemonized, any open files are closed.  Look at 
> tmp/pids/mongrel.8000.pid and log/mongrel.8000.log for info.
> ** Starting Mongrel listening at 127.0.0.1:8000 <http://127.0.0.1:8000>
> ** Starting Rails with production environment...
> deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:243:in `mkdir': 
> File exists - 
> /deployment/installed/myapp/releases/20080130211150/public/bundles 
> (Errno::EEXIST)
>
>         from 
> /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:243:in `fu_mkdir'
>         from 
> /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:172:in `mkdir'
>         from 
> /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:171:in `each'
>         from 
> /deployment/installed/ruby/lib/ruby/1.8/fileutils.rb:171:in `mkdir'
>         from 
> /deployment/installed/myapp/releases/20080130211150/vendor/plugins/bundled_resource-0.9/lib/bundled_resource.rb:38:in 
> `create_public_bundle_directory'
>
>         from 
> /deployment/installed/myapp//releases/20080130211150/vendor/plugins/bundled_resource-0.9/init.rb:57:in 
> `evaluate_init_rb'
>
>         from 
> deployment/installed/ruby/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/rails/plugin.rb:79:in 
> `evaluate_init_rb'
>         from 
> /deployment/installed/ruby/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/core_ext/kernel/reporting.rb:11:in 
> `silence_warnings'
>
>          ... 21 levels...
>         from 
> /deployment/installed/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.3/bin/../lib/mongrel/command.rb:212:in 
> `run'
>         from 
> /deployment/installed/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.3/bin/mongrel_rails:281 
>
>         from /deployment/installed/ruby/bin/mongrel_rails:19:in `load'
>         from /deployment/installed/ruby/bin/mongrel_rails:19
>
>
> It looks to me as if both mongrels are starting up, but the deployment 
> of the "bundled_resource" from each mongrel is ending up with the app 
> stomping on itself.
>
> I've not found any indication of a similar problem searching the net, 
> or the forums (or the bug tracker).
>
> Has anybody else seen similar behavior? Is there  a workaround available?
>
> Thanks!
>
> john
>
>
> BTW: my currently isntalled gems include:
>
> bash-2.05b$ gem list
>
> *** LOCAL GEMS ***
>
> actionmailer (2.0.2)
> actionpack (2.0.2)
> activerecord (2.0.2)
> activeresource (2.0.2)
> activesupport (2.0.2)
> capistrano (2.1.0)
> cgi_multipart_eof_fix (2.5.0)
> daemons (1.0.9)
> fastthread (1.0.1)
> gem_plugin (0.2.3)
> highline (1.4.0)
> mongrel (1.1.3)
> mongrel_cluster (1.0.5)
> needle (1.3.0)
> net-sftp (1.1.0)
> net-ssh (1.1.2)
> rails (2.0.2)
> rake (0.8.1)
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


-- 
Rafael Garcia Ortega

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rgo.vcf
Type: text/x-vcard
Size: 241 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20080131/d121ffe3/attachment.vcf 

From doctor.jw at gmail.com  Thu Jan 31 10:17:31 2008
From: doctor.jw at gmail.com (John Woodward)
Date: Thu, 31 Jan 2008 09:17:31 -0600
Subject: [Mongrel] Not all mongrel starting (Errno:EEXIST)
In-Reply-To: <47A1932C.8060904@aspgems.com>
References: <92636E8B291DE247A4072BDEE7D20C5C06656A3C@NSTMC104PEX1.ubsw.net>
	<7f1ee36d0801301417x5bd116b7sfa4a670d0a192c8d@mail.gmail.com>
	<47A1932C.8060904@aspgems.com>
Message-ID: <7f1ee36d0801310717o585b05b9hb79afcef945f8349@mail.gmail.com>

Thanks for the replies; late yesterday, I went digging some more and it
really is an issue with bundle_resources (does anyone still use this? .. I'm
pretty new to Ruby on Rails). bundle_resources attempts to create a
directory and then copy jsps, etc., to that directory, at every startup of
the app. So ... with multiple Mongrel processes, of course it fails on the
second process when it collides with the first. Nasty.

I'll either remove bundle_resources, or apply some sort of patch to it.

Thanks!

john



2008/1/31 Rafael G. <rgo at aspgems.com>:

> I used bundled resources sometimes ago and I have same problem (I think).
>
> I read init.rb and I commented lines 54..57 (create bundle directory and
> copy resources).
>
> Regards!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080131/6f209452/attachment.html 

From john.jian.fang at gmail.com  Thu Jan 31 17:59:06 2008
From: john.jian.fang at gmail.com (Jian Fang)
Date: Thu, 31 Jan 2008 17:59:06 -0500
Subject: [Mongrel] Production problem for mongrel
In-Reply-To: <ebb5a7c40801301901t40baf655o5abc37e53e4a8674@mail.gmail.com>
References: <ebb5a7c40801301901t40baf655o5abc37e53e4a8674@mail.gmail.com>
Message-ID: <ebb5a7c40801311459x318324ddh35710ddc345b770c@mail.gmail.com>

I re-installed the mongrel gem by run

 gem install --platform x86_64-linux mongrel-1.1.3.gem --local

and got the problem solved.


Thanks anyway.


On Jan 30, 2008 10:01 PM, Jian Fang <john.jian.fang at gmail.com> wrote:

> Hi,
>
> I am working on deplying my Rail app to QA and then move to production.
> Since on our QA servers, there is no internet access and also for production
> servers, internet access is strictly prohibited.
> As a result, there is no way to install mongrel by use "gem install
> mongrel" command.
>
> The first option I tried is to put mongrel and all other gems under the
> vendor directly in my app, but seems the command "ruby script/server" cannot
> find mongrel.
>
> The second option I tried is to download the tar ball and run "ruby
> setup.rb all". The process finished fine. Type "which mongrel_rails" and
> show "/usr/local/bin/mongrel_rails".
> However, when I run the command " mongrel_rails start", it showed  the
> following errors:
>
>  /usr/local/bin/mongrel_rails: line 7: require: command not found
> /usr/local/bin/mongrel_rails: line 8: require: command not found
> /usr/local/bin/mongrel_rails: line 10: .unshift: command not found
> /usr/local/bin/mongrel_rails: line 11: require: command not found
> /usr/local/bin/mongrel_rails: line 12: require: command not found
> /usr/local/bin/mongrel_rails: line 14: Mongrel::Gems.require: command not
> found
> /usr/local/bin/mongrel_rails: line 19: module: command not found
> /usr/local/bin/mongrel_rails: line 20: GemPlugin::Plugin: No such file or
> directory
> /usr/local/bin/mongrel_rails: line 21: include: command not found
> /usr/local/bin/mongrel_rails: line 23: def: command not found
> /usr/local/bin/mongrel_rails: line 24: options: command not found
> /usr/local/bin/mongrel_rails: line 25: [-e,: command not found
> /usr/local/bin/mongrel_rails: line 25: development],: command not found
> ....
>
> Then, I tried  "ruby script/server". It  showed the following errors:
>
> /opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:489:in
> `load': no such file to load -- mongrel_rails (MissingSourceFile)
>         from
> /opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:489:in
> `load'
>         from
> /opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:342:in
> `new_constants_in'
>         from
> /opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:489:in
> `load'
>         from
> /opt/AddressRubyClient/vendor/rails/railties/lib/commands/servers/mongrel.rb:64
>         from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require'
>         from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
>         from
> /opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:496:in
> `require'
>         from
> /opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:342:in
> `new_constants_in'
>         from
> /opt/AddressRubyClient/vendor/rails/activesupport/lib/active_support/dependencies.rb:496:in
> `require'
>         from
> /opt/AddressRubyClient/vendor/rails/railties/lib/commands/server.rb:39
>         from script/server:3:in `require'
>         from script/server:3
>
>
> The QA server is running Redhat EL4 X86_64 version of linux. And I
> installed Ruby 1.8.6 and rails 2.0.2.
>
> I really appreciate if someone could help me with this issue.
>
> Thanks in advance,
>
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080131/94ac07eb/attachment-0001.html