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: <b6f68fc60801081928v60ba