From borko.boyanov at gmail.com  Thu Mar  1 00:06:36 2007
From: borko.boyanov at gmail.com (Boril Boyanov)
Date: Thu, 1 Mar 2007 07:06:36 +0200
Subject: [Mongrel] "mongrel-users@rubyforge.org": E-Mail usage:
Message-ID: <90cae7cc0702282106r7553ed44kdaf391547ff1b94a@mail.gmail.com>

Dear Mongrel users,
Usage of the E-Mail is for some PRIVATE communication.
There are other accesses in class definitions:

class Users
{
private:
  my_gal, my_best_buddy, me
protected:
 my_homies
public:
evey dude in the world (can get... what? eliminatted puhleeeeze, riiiiite,
think damnit)
}

...aaaaand some very secure phorums and forums could be used... right?
riiiite :)

So... i suggest using that, and remember, Please Update Mongrel and keep it
ON TOP!
Other suggestions:
We are very pleased we can use Ruby lang now :) :) *kisses* to the Lang!
We are very pleased we can use Ruby Jewel  now :) :) kisses to all

we are very plesaed to announce that soon the work on BHDZ->variant:
Diamandos will start.
YOU checked the access to it? no? ok. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070301/461dcd78/attachment.html 

From chris at codeintensity.com  Thu Mar  1 00:45:20 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Wed, 28 Feb 2007 21:45:20 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <20070228090539.cc7f79b5.zedshaw@zedshaw.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
	<f4cd26df0702271742m444937f4yc0efb7b56a86a3b8@mail.gmail.com>
	<8c8513100702271939h78212753r59633489098b69e1@mail.gmail.com>
	<8c8513100702272202m3969b2f5je6c1070ae23adbba@mail.gmail.com>
	<20070228090539.cc7f79b5.zedshaw@zedshaw.com>
Message-ID: <8c8513100702282145s2603ecd8le946c1f23e9cb7ae@mail.gmail.com>

Ok, thanks.  Yes, it seems that basically things are somewhat as expected.
It's definitely a good exercise in knowing how noticeably certain things
(like sessions, etc.) affect the performance.  At this point I've removed
Apache from the mix, as we wouldn't be using it anyway (we use it in dev as
it's what we have now that allows us to easily run static, and multiple
Rails on a single box and balance across that, etc.  But, I will probably
look at Nginx as an alternative.  For my tests I've now switched to Pen as
that seems the least obtrusive, and is about as simple as we could get
before having no software load balance/closes to hardware LB.

On 2/28/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> On Tue, 27 Feb 2007 22:02:58 -0800
> "Christopher Bailey" <chris at codeintensity.com> wrote:
>
> > Moving forward, I may not understand httperf's num-conns, and rate, as
> > applied to scaling up the number of Mongrels.  Either that, or my server
> has
> > issues.
> >
> > httperf --hog --server lab05 --port 80 --uri /mongrel_alive.html
> --num-conns
> > 4500 --rate 450
> >
> > This gives me back 10 seconds of time, and 450 req/sec, 450 conn/sec.
>
> Try inching that up incrementally until you find the "sweet spot".
> It's probably going to be 450 or near it, but try 500.  You'll know you
> passed the sweet spot when the req/sec crashes suddenly.  I do kind of
> a binary search algo until I find the right number.
>
> > So, now I add a Mongrel into the mix, restart Apache, etc.  I would
> think
> > that I can now use:
> >
> > httperf --hog --server lab05 --port 80 --uri /mongrel_alive.html
> --num-conns
> > 9000 --rate 900
>
> You won't get 900 right away, especially since you have one CPU and are
> maxing them out but if you get 350 req/sec then try again inching it
> down until you get a steady number.  Try 800 to see if that gives you
> 800 req/sec, then further down until you get it, then inch up to see
> where the sweet spot is.
>
> > In my case it starts breaking down with just two Mongrels (and to be
> clear,
> > I was not running top during the tests).  I drop to about 350 req/sec
> > without errors.
>
> Yep, and that's just kind of the way it goes.  In your case, having
> more mongrels isn't going to get you higher performance, so just add
> one more mongrel and use your mongrel processes more to ensure
> concurrency when running Rails.  Also, you haven't even hit testing
> your rails performance yet, do that too and just kind of accept it as
> your speed then plan for it.
>
> --
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> http://mongrel.rubyforge.org/
> http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
> _______________________________________________
> 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/20070228/5535dcac/attachment.html 

From john at swiftshire.org  Thu Mar  1 13:05:00 2007
From: john at swiftshire.org (John Swift)
Date: Thu, 01 Mar 2007 13:05:00 -0500
Subject: [Mongrel] mongrel_cluster
Message-ID: <45E715CC.9090005@swiftshire.org>

Hello,

Apologize if this is a annoying faq but folks here are trying to get a 
cluster going and something odd is happening. When 'mongrel_rails 
cluster::start' is run, the following error is getting returned:

ERROR RUNNING 'cluster::start': Plugin /cluster::start does not exist in 
category /commands


Is this the result of a simple path issue or perhaps a broken mongrel 
install? Curious if anyone has seen this before or has any idea what 
might be the cause.

TIA,
js

From atmos at atmos.org  Thu Mar  1 13:49:51 2007
From: atmos at atmos.org (Corey Donohoe)
Date: Thu, 1 Mar 2007 12:49:51 -0600
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <45E715CC.9090005@swiftshire.org>
References: <45E715CC.9090005@swiftshire.org>
Message-ID: <c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>

sudo gem install mongrel_cluster --source
http://mongrel.rubyforge.org/releases/

On 3/1/07, John Swift <john at swiftshire.org> wrote:
>
> Hello,
>
> Apologize if this is a annoying faq but folks here are trying to get a
> cluster going and something odd is happening. When 'mongrel_rails
> cluster::start' is run, the following error is getting returned:
>
> ERROR RUNNING 'cluster::start': Plugin /cluster::start does not exist in
> category /commands
>
>
> Is this the result of a simple path issue or perhaps a broken mongrel
> install? Curious if anyone has seen this before or has any idea what
> might be the cause.
>
> TIA,
> js
> _______________________________________________
> 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/20070301/61bd756b/attachment.html 

From pberry at gmail.com  Thu Mar  1 14:17:56 2007
From: pberry at gmail.com (Patrick Berry)
Date: Thu, 1 Mar 2007 11:17:56 -0800
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <45E715CC.9090005@swiftshire.org>
References: <45E715CC.9090005@swiftshire.org>
Message-ID: <ef13ff170703011117w472ddb0ds92e8166d3acfcdec@mail.gmail.com>

Do you have multiple gem for mongrel_cluster installed?  I ran into
this and uninstalling the old gems worked for me.

Pat

On 3/1/07, John Swift <john at swiftshire.org> wrote:
> Hello,
>
> Apologize if this is a annoying faq but folks here are trying to get a
> cluster going and something odd is happening. When 'mongrel_rails
> cluster::start' is run, the following error is getting returned:
>
> ERROR RUNNING 'cluster::start': Plugin /cluster::start does not exist in
> category /commands
>
>
> Is this the result of a simple path issue or perhaps a broken mongrel
> install? Curious if anyone has seen this before or has any idea what
> might be the cause.
>
> TIA,
> js
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From matte at ruckuswireless.com  Thu Mar  1 14:47:14 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Thu, 01 Mar 2007 11:47:14 -0800
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <45E715CC.9090005@swiftshire.org>
References: <45E715CC.9090005@swiftshire.org>
Message-ID: <45E72DC2.3030104@ruckuswireless.com>

I'll +1 for what Patrick Berry said.  do a "gem cleanup mongrel_cluster" 
(sudo if you need to) and that should fix it.  I had the same problem 
and that fixed it.

matte

John Swift wrote:
> Hello,
>
> Apologize if this is a annoying faq but folks here are trying to get a 
> cluster going and something odd is happening. When 'mongrel_rails 
> cluster::start' is run, the following error is getting returned:
>
> ERROR RUNNING 'cluster::start': Plugin /cluster::start does not exist in 
> category /commands
>
>
> Is this the result of a simple path issue or perhaps a broken mongrel 
> install? Curious if anyone has seen this before or has any idea what 
> might be the cause.
>
> TIA,
> js
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   



From john at swiftshire.org  Thu Mar  1 15:42:56 2007
From: john at swiftshire.org (John Swift)
Date: Thu, 01 Mar 2007 15:42:56 -0500
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <ef13ff170703011117w472ddb0ds92e8166d3acfcdec@mail.gmail.com>
References: <45E715CC.9090005@swiftshire.org>
	<ef13ff170703011117w472ddb0ds92e8166d3acfcdec@mail.gmail.com>
Message-ID: <45E73AD0.7060202@swiftshire.org>

Patrick Berry wrote:
> Do you have multiple gem for mongrel_cluster installed?  I ran into
> this and uninstalling the old gems worked for me.
> 
> Pat
> 

Thanks Pat (and Corey). The install was done completely from scratch 
with just the following:

   gem install mongrel_cluster -y


Starting over and trying Corey's suggestion now.

js

From lawver at gmail.com  Thu Mar  1 15:42:33 2007
From: lawver at gmail.com (Kevin Lawver)
Date: Thu, 01 Mar 2007 15:42:33 -0500
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>
References: <45E715CC.9090005@swiftshire.org>
	<c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>
Message-ID: <45E73AB9.5080006@gmail.com>

This worked like a charm, thanks everybody!  (yes, I'm the guy John was 
talking about)

Cheers,
Kevin Lawver

Corey Donohoe wrote:
> sudo gem install mongrel_cluster --source 
> http://mongrel.rubyforge.org/releases/
> 



From john at swiftshire.org  Thu Mar  1 15:45:02 2007
From: john at swiftshire.org (John Swift)
Date: Thu, 01 Mar 2007 15:45:02 -0500
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>
References: <45E715CC.9090005@swiftshire.org>
	<c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>
Message-ID: <45E73B4E.1010407@swiftshire.org>

Corey Donohoe wrote:
> sudo gem install mongrel_cluster --source 
> http://mongrel.rubyforge.org/releases/
>

Yep, that did it. Things are copacetic. Thanks very much.

js

From pberry at gmail.com  Thu Mar  1 18:44:00 2007
From: pberry at gmail.com (Patrick Berry)
Date: Thu, 1 Mar 2007 15:44:00 -0800
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <45E73AD0.7060202@swiftshire.org>
References: <45E715CC.9090005@swiftshire.org>
	<ef13ff170703011117w472ddb0ds92e8166d3acfcdec@mail.gmail.com>
	<45E73AD0.7060202@swiftshire.org>
Message-ID: <ef13ff170703011544g28d29bcdr1712fc9d526d9c8e@mail.gmail.com>

On 3/1/07, John Swift <john at swiftshire.org> wrote:
> Patrick Berry wrote:
> > Do you have multiple gem for mongrel_cluster installed?  I ran into
> > this and uninstalling the old gems worked for me.
> >
> > Pat
> >
>
> Thanks Pat (and Corey). The install was done completely from scratch
> with just the following:
>
>    gem install mongrel_cluster -y
>
>
> Starting over and trying Corey's suggestion now.
>

It should be noted that this will install a "pre-release" version of
mongrel_cluster.  That being said, we're running it in production
right now (what better test could you ask for, right?).  We also have
the luxury of having very small audiences.

Pat

From tomawng at yahoo.fr  Thu Mar  1 18:45:15 2007
From: tomawng at yahoo.fr (tom wang)
Date: Fri, 2 Mar 2007 00:45:15 +0100 (CET)
Subject: [Mongrel] RE : Re:  Deployement options
In-Reply-To: <14adac440702281958p2752125bpb75c0adf64790024@mail.gmail.com>
Message-ID: <749645.56945.qm@web23413.mail.ird.yahoo.com>

Thanks a lot everybody for the answer,  I'm going to
use nginx together with a pack of mongrels....
I hadn't thought there was so much difference between
the different web framework on ruby (ie. why isn't
rails threadsafe? ) but since I'm going to go with
rails, I'll have to have more mongrels process if I
understand correctly....


A bit offtopic, what do you people think of grids like
applogic (http://www.3tera.com/applogic.html,
http://www.thegridlayer.com/index.php), is it a good
solution to scale the system has more and more
requests are being made? Has anybody ever tried using
it?

Another question I had is what do you think of using
gentoo for the server, I have a lot of experience in
using it as my primary desktop operating system
(before I switched to mac) but I wonder if it's a good
idea on a server.... The tendency to have problems
when a gentoo installation had not been updated for a
long time and you suddenly update worries me.


Again, thanks 
and thanks Zed for developing mongrel


--- Craig Kuhns <craigkuhns at gmail.com> a ?crit?:

> I would definitely check out using nginx.  I have
> set it up a number
> of times for production sites using rails and nginx
> and mongrel and it
> has performed incredibly well.  If you want a good
> walkthrough
> installing and configuring it with rails and several
> mongrels check
> out Kyle Kochis's blog - kyledev.blogspot.com.
> 
> Craig Kuhns
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 



	

	
		
___________________________________________________________________________ 
D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions ! 
Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses 
http://fr.answers.yahoo.com

From alexey.verkhovsky at gmail.com  Fri Mar  2 15:49:22 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Fri, 2 Mar 2007 14:49:22 -0600
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
Message-ID: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>

Dear all,

I am researching solutions for "how do you squeeze as many Rails apps as you
can on a cluster" problem.

Environment constraints are as follows:

* 4 commodity web servers (2 CPUs, 8 Gb of RAM each)
* shared file storage and database (big, fast, not a bottleneck)
* multiple Rails apps running on it
* normally, the load is insignificant, but from time to time any of these
apps can have a big, unpredictable spike in load, that takes (say) 8
Mongrels to handle.

The bottleneck, apparently, is RAM. At 100 Mb per Mongrel process, you can
only put 320 Mongrel processes on those boxes, and under specified
parameters you can only handle 40 apps on the hardware described above. PHP
can handle thousands of sites under the same set of constraints.

We could use lighty + FastCGI combo, but it has a bad reputation. I wonder
if it's because of bugs in implementation, or it's just not designed for
these scenarios (if not, what's the limitation, and can it be fixed?)

If anybody knows a ready-made solution to this problem, please let me know.
The last thing I want to do is reinvent the wheel.

If anybody knows a load balancer smart enough to start and kill multiple
processes across the entire cluster, based on demand per application, please
let me know about that, too.

Finally, I've been thinking about making Rails execution within Mongrel
concurrent by spawning multiple Rails processes as children of Mongrel, and
talking to them through local pipes (just like FastCGI does, but a
Ruby-specific solution). This may allow a single Mongrel to scale 3-4 times
better than now, and also to scale down if no requests are coming in the
last, say, 10 minutes. A "blank" Ruby process only takes 7Mb of RAM, perhaps
a "blank" Mongrel is not much more (haven't checked yet). Wonder if this
makes sense, or am I just crazy.

I think, we can implement (and open-source) any solution that needs weeks
rather than years of effort.

Thoughts?

Best regards,
Alex Verkhovsky
ThoughtWorks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070302/fbe5d764/attachment.html 

From jamie at dangosaur.us  Sun Mar  4 00:18:46 2007
From: jamie at dangosaur.us (Jamie Orchard-Hays)
Date: Sun, 4 Mar 2007 00:18:46 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
Message-ID: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>

I'm running the latest mongrel (1.0.1) and the latest mongrel_cluster  
(1.0.1.1) on FreeBSD 6.1.

When I use capistrano to try to stop or restart my cluster I get this  
(partial) output:

ps: Process environment requires procfs(5)

And my Mongrel processes haven't stopped.

Any ideas?

Thanks,

Jamie

From jw at innerewut.de  Sun Mar  4 04:17:22 2007
From: jw at innerewut.de (Jonathan Weiss)
Date: Sun, 04 Mar 2007 10:17:22 +0100
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
Message-ID: <45EA8EA2.9010307@innerewut.de>

Jamie Orchard-Hays wrote:
> I'm running the latest mongrel (1.0.1) and the latest mongrel_cluster  
> (1.0.1.1) on FreeBSD 6.1.
> 
> When I use capistrano to try to stop or restart my cluster I get this  
> (partial) output:
> 
> ps: Process environment requires procfs(5)
> 
> And my Mongrel processes haven't stopped.
> 
> Any ideas?

The message means that you need the procfs virtual filesystem mounted. 
Normally you do not need this under FreeBSD.

I use Mongrel 1.0.1 + mongrel_cluster (0.2.1) on FreeBSD 6.2 without any 
glitches, so maybe mongrel_cluster 1.0.1.1 introduces some 
Linux-specific ps syntax that requires procfs.

I will try to upgrade my mongrel_cluster version and see if I get the 
same message.

> 
> Thanks,
> 
> Jamie

Jonathan

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

From wyhaines at gmail.com  Sun Mar  4 10:12:59 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Sun, 4 Mar 2007 08:12:59 -0700
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
In-Reply-To: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
Message-ID: <f4cd26df0703040712w311ffc94hc894fccf04dcd513@mail.gmail.com>

On 3/2/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> Dear all,
>
> I am researching solutions for "how do you squeeze as many Rails apps as you
> can on a cluster" problem.
>
> Environment constraints are as follows:
>
> * 4 commodity web servers (2 CPUs, 8 Gb of RAM each)
> * shared file storage and database (big, fast, not a bottleneck)
> * multiple Rails apps running on it
> * normally, the load is insignificant, but from time to time any of these
> apps can have a big, unpredictable spike in load, that takes (say) 8
> Mongrels to handle.
>
> The bottleneck, apparently, is RAM. At 100 Mb per Mongrel process, you can
> only put 320 Mongrel processes on those boxes, and under specified
> parameters you can only handle 40 apps on the hardware described above. PHP
> can handle thousands of sites under the same set of constraints.

Do you have a sense for how many requests/second capacity represents a
rate that can survive slashdotting?  i.e. you are assuming 8
mongrels/app.  So what capacity do those 8 mongrels represent?

> If anybody knows a load balancer smart enough to start and kill multiple
> processes across the entire cluster, based on demand per application, please
> let me know about that, too.

I have developed a clustering proxy from scratch (the first fledgling
release of it should be today) that is in a good position for feature
requests.  Having a single load balancer starting and stopping
processes across a cluster, though, calls for quite a bit of
complexity.  A compromise, that would just manage backends on the same
machine that the proxy is running on, could have potential.  Something
would proxy requests out to nodes, and the local proxy on each node
would manage it's pack of backend processes.  The friction of having
two layers of proxying might create too much throughput entropy,
through.

> Finally, I've been thinking about making Rails execution within Mongrel
> concurrent by spawning multiple Rails processes as children of Mongrel, and
> talking to them through local pipes (just like FastCGI does, but a
> Ruby-specific solution). This may allow a single Mongrel to scale 3-4 times
> better than now, and also to scale down if no requests are coming in the
> last, say, 10 minutes. A "blank" Ruby process only takes 7Mb of RAM, perhaps
> a "blank" Mongrel is not much more (haven't checked yet). Wonder if this
> makes sense, or am I just crazy.

This sounds like a way to implement something similar to what I described above.


Kirk Haines

From jamie at dangosaur.us  Sun Mar  4 10:44:25 2007
From: jamie at dangosaur.us (Jamie Orchard-Hays)
Date: Sun, 4 Mar 2007 10:44:25 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <45EA8EA2.9010307@innerewut.de>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
	<45EA8EA2.9010307@innerewut.de>
Message-ID: <79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>

Thanks. I'd found a bit about that after I sent the message. Things  
worked fine with 0.2.1--except that mongrel_cluster's restart did not  
work properly if nothing was running, which cost me an hour a day  
earlier before I realized what was wrong. That's was my motivation to  
upgrade.

If you have any simple instructions about how to get this working on  
FreeBSD, I'll be very grateful!

Jamie

On Mar 4, 2007, at 4:17 AM, Jonathan Weiss wrote:

> The message means that you need the procfs virtual filesystem mounted.
> Normally you do not need this under FreeBSD.
>
> I use Mongrel 1.0.1 + mongrel_cluster (0.2.1) on FreeBSD 6.2  
> without any
> glitches, so maybe mongrel_cluster 1.0.1.1 introduces some
> Linux-specific ps syntax that requires procfs.
>
> I will try to upgrade my mongrel_cluster version and see if I get the
> same message.


From jamie at dangosaur.us  Sun Mar  4 11:17:32 2007
From: jamie at dangosaur.us (Jamie Orchard-Hays)
Date: Sun, 4 Mar 2007 11:17:32 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
	<45EA8EA2.9010307@innerewut.de>
	<79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>
Message-ID: <4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>

Kirk, I followed the instructions on the following link, but no love.  
I seem to have mounted fine, but I'm getting the same error reported  
back from mongrel_cluster_ctl.

http://os.newsforge.com/os/06/03/22/1531252.shtml?tid=8&tid=2

Jamie

On Mar 4, 2007, at 10:44 AM, Jamie Orchard-Hays wrote:

> Thanks. I'd found a bit about that after I sent the message. Things
> worked fine with 0.2.1--except that mongrel_cluster's restart did not
> work properly if nothing was running, which cost me an hour a day
> earlier before I realized what was wrong. That's was my motivation to
> upgrade.
>
> If you have any simple instructions about how to get this working on
> FreeBSD, I'll be very grateful!
>
> Jamie
>
> On Mar 4, 2007, at 4:17 AM, Jonathan Weiss wrote:
>
>> The message means that you need the procfs virtual filesystem  
>> mounted.
>> Normally you do not need this under FreeBSD.
>>
>> I use Mongrel 1.0.1 + mongrel_cluster (0.2.1) on FreeBSD 6.2
>> without any
>> glitches, so maybe mongrel_cluster 1.0.1.1 introduces some
>> Linux-specific ps syntax that requires procfs.
>>
>> I will try to upgrade my mongrel_cluster version and see if I get the
>> same message.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From pberry at gmail.com  Sun Mar  4 11:36:28 2007
From: pberry at gmail.com (Patrick Berry)
Date: Sun, 4 Mar 2007 08:36:28 -0800
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
	<45EA8EA2.9010307@innerewut.de>
	<79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>
	<4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>
Message-ID: <ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>

On 3/4/07, Jamie Orchard-Hays <jamie at dangosaur.us> wrote:
> Kirk, I followed the instructions on the following link, but no love.
> I seem to have mounted fine, but I'm getting the same error reported
> back from mongrel_cluster_ctl.
>
> http://os.newsforge.com/os/06/03/22/1531252.shtml?tid=8&tid=2
>
> Jamie
>

It is a ps command problem.  I ran into the same issue when testing
locally on OS X.  Options are to wait for another *pre-release* of
mongrel_cluster or making the following mod to line 164 of init.rb in
the check_process method:

old:   ps_output = `ps -o args= -p #{pid}`
new: ps_output = `ps -o command= -p #{pid}`

Pat

From jamie at dangosaur.us  Sun Mar  4 12:47:38 2007
From: jamie at dangosaur.us (Jamie Orchard-Hays)
Date: Sun, 4 Mar 2007 12:47:38 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
	<45EA8EA2.9010307@innerewut.de>
	<79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>
	<4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>
	<ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>
Message-ID: <0D15D6D1-98E9-4A2C-8FAC-529639A8575C@dangosaur.us>

Patrick, I assume you mean the gem file on the remote server. This  
didn't change the error I get, or cause restart to work.

Thanks,
Jamie

On Mar 4, 2007, at 11:36 AM, Patrick Berry wrote:

> It is a ps command problem.  I ran into the same issue when testing
> locally on OS X.  Options are to wait for another *pre-release* of
> mongrel_cluster or making the following mod to line 164 of init.rb in
> the check_process method:
>
> old:   ps_output = `ps -o args= -p #{pid}`
> new: ps_output = `ps -o command= -p #{pid}`
>
> Pat


From bradley at railsmachine.com  Sun Mar  4 13:19:55 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Sun, 04 Mar 2007 13:19:55 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>	<45EA8EA2.9010307@innerewut.de>	<79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>	<4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>
	<ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>
Message-ID: <45EB0DCB.5050902@railsmachine.com>

This 'ps' syntax is really annoying. If my score-keeping is correct:

Linux and FreeBSD seem to support both 'args' and 'command'.
Darwin/MacOSX doesn't support 'args'.
Solaris doesn't support 'command'.

I guess I need to resort to platform checks. I was hoping to avoid this 
by using the 'standard format specifiers'. The great thing about 
standards is that there are so many to choose from.

Bradley

Patrick Berry wrote:
> On 3/4/07, Jamie Orchard-Hays <jamie at dangosaur.us> wrote:
>> Kirk, I followed the instructions on the following link, but no love.
>> I seem to have mounted fine, but I'm getting the same error reported
>> back from mongrel_cluster_ctl.
>>
>> http://os.newsforge.com/os/06/03/22/1531252.shtml?tid=8&tid=2
>>
>> Jamie
>>
> 
> It is a ps command problem.  I ran into the same issue when testing
> locally on OS X.  Options are to wait for another *pre-release* of
> mongrel_cluster or making the following mod to line 164 of init.rb in
> the check_process method:
> 
> old:   ps_output = `ps -o args= -p #{pid}`
> new: ps_output = `ps -o command= -p #{pid}`
> 
> Pat
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From alexey.verkhovsky at gmail.com  Sun Mar  4 14:36:31 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Sun, 4 Mar 2007 13:36:31 -0600
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
In-Reply-To: <f4cd26df0703040712w311ffc94hc894fccf04dcd513@mail.gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
	<f4cd26df0703040712w311ffc94hc894fccf04dcd513@mail.gmail.com>
Message-ID: <3945c4270703041136l39fd677aree0424ff84382b92@mail.gmail.com>

On 3/4/07, Kirk Haines <wyhaines at gmail.com> wrote:
>
> Do you have a sense for how many requests/second capacity represents a
> rate that can survive slashdotting?


"Survive slashdotting" is just a phrase. The target is ~100 requests/sec for
dynamic page rendering,

I have developed a clustering proxy from scratch (the first fledgling
> release of it should be today) that is in a good position for feature
> requests.

If it's free, open source, and done well, I am in a good position to give
you those feature requests. Even lend a hand in implementing them, probably.
Let's continue this conversation off the list.

Having a single load balancer starting and stopping
> processes across a cluster, though, calls for quite a bit of
> complexity.

Yeah. Hopefully, it will prove unnecessary.

A compromise, that would just manage backends on the same
> machine that the proxy is running on, could have potential.


Litespeed and mod_fcgid both do this fairly well. But proxy to Mongrels
seems wiser, because Mongrel is a de-facto standard development environment.
Little extra CPU time for avoiding deployment pains is always a good deal.

Best regards,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070304/527bc894/attachment.html 

From dee.zsombor at gmail.com  Mon Mar  5 02:10:09 2007
From: dee.zsombor at gmail.com (Dee Zsombor)
Date: Mon, 05 Mar 2007 09:10:09 +0200
Subject: [Mongrel] Multiple apps on the same server,
 all should be able to survive slashdotting
In-Reply-To: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
Message-ID: <45EBC251.2060807@gmail.com>

Alexey Verkhovsky wrote:
> We could use lighty + FastCGI combo, but it has a bad reputation. I 
> wonder if it's because of bugs in implementation, or it's just not 
> designed for these scenarios (if not, what's the limitation, and can it 
> be fixed?)

My personal experience points to the contrary, using FCGI listeners (if 
you have the option of dumping apache for lighttpd) works well. Just spawn 
the fcgi listeners externally from script/process/spinner, then tell only 
the ports to lighty where fcgi listeners run:

>  fastcgi.server              = ( ".fcgi" =>
>                                   ( "localhost-7000" => ( "host" => "127.0.0.1", "port" => 7001 ) ),
>                                   ( "localhost-7001" => ( "host" => "127.0.0.1", "port" => 7002 ) ),
>                                   ( "localhost-7002" => ( "host" => "127.0.0.1", "port" => 7003 ) )
>                                 )

Apache with fcgi is a pain true, but not with lighttpd.

Zsombor
-- 
Company  - http://primalgrasp.com
Thoughts - http://deezsombor.blogspot.com

From brianpdoyle at gmail.com  Mon Mar  5 15:30:30 2007
From: brianpdoyle at gmail.com (Brian Doyle)
Date: Mon, 5 Mar 2007 13:30:30 -0700
Subject: [Mongrel] mongrel goes out to lunch for about 5 - 10 minutes
Message-ID: <a2c7a60e0703051230q4be25e79n86b6f61b36568ff5@mail.gmail.com>

Not sure if this is the list for posting questions like this but please let
me know.  We are using Mongrel 0.13.4, Mongrel Cluster 0.2.1  with Rails
1.2.2 with 3 different mongrel processes running in the cluster.  All
appears to be well for hours and then one of the mongrel processes appears
to hang and all incoming requests to that process timeout.  The requests are
not logged in the rails log, (production.log) and we do not see anything in
the mongrel.log so it is making it a bit hard to debug.  I know we can do
more debug logging for mongrel but we were attempting to wait to do that
until further investigation.

Eventually that mongrel process will "come back to life" and continue
serving requests again like nothing ever happened.  Nothing in any logs to
indicate the problem.  When I say eventually it appears anywhere from 5 to
10 minutes of time.  We are in the process of doing more debugging like
monitoring the network, database, etc. but just wondering if there is
something else we should be on the lookout for.   It appears that all
previous requests to that mongrel process are successful with no errors.
We are monitoring the 3 mongrel processes using Big Brother hitting the same
page.  This page doesn't require hits to the db, mail servers or memcache
(all services we use for other parts of the website.)  Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070305/455d9d3a/attachment.html 

From jaywhy at gmail.com  Mon Mar  5 17:10:06 2007
From: jaywhy at gmail.com (Jason Yates)
Date: Mon, 5 Mar 2007 17:10:06 -0500
Subject: [Mongrel] cluster with environment variables
In-Reply-To: <4cbfccd70702231233g5b4defdy80981ae109c7d0d5@mail.gmail.com>
References: <4cbfccd70702231233g5b4defdy80981ae109c7d0d5@mail.gmail.com>
Message-ID: <4cbfccd70703051410n61e2332dm8ff551a6743dca2b@mail.gmail.com>

I should have responded earlier to myself.  Just in case others have
similar problems in the future.

The problem wasn't mongrel at all.  However, the issue seemed to be
coming from mongrel, because for whatever reason an error from Rjb
wasn't getting logged

The problem was Java was eating up all the available memory.  Because
each mongrel instance would start its own Java process. The first one
would steal all the available memory. Then the second couldn't even
start because no memory was available.  Hence one mongrel instance
would work the other wouldn't

The JRE does this because it checks for available system memory and
allocates a portion of it.  Which is fine, however in my case I'm
using a virtual server.  So I only had a 256mb portion of the 4gbs
Java thought it had to play with.

Anyways I blogged about it.  If anyone cares.

http://jaywhy.wordpress.com/2007/03/05/pdf-templates-via-rails/

On 2/23/07, Jason Yates <jaywhy at gmail.com> wrote:
> In production I've setup a mongrel cluster of 2 servers.  Now I'm
> using RJB(ruby java bridge).  So I need certain java environment
> variables set before mongrel starts.
>
> So I set them:
>
> export LD_LIBRARY_PATH=/usr/java/jdk1.6.0/jre/lib/i386/:/usr/java/jdk1.6.0/jre/lib/i386/client/:./
> export JAVA_HOME=/usr/java/jdk1.6.0/
>
> Then I run "mongrel_rails cluster::start".
>
> Now for whatever reason only the first server in the cluster seems
> have the environment variables set.  Like as if the environment is
> getting blanked out after the first server starts but before the
> second.
>
> So I on the page using RJB.  I end up with this weird refresh problem.
>  Where it works, then errors, works, error, etc.
>
> I'm using rails 1.2.1 and mongrel 1.0.1 and cluster 0.2.1.  If that helps.
>
> --
> Jason Yates
> jaywhy at gmail.com
>


-- 
Jason Yates
jaywhy at gmail.com

From luislavena at gmail.com  Mon Mar  5 17:41:28 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 5 Mar 2007 19:41:28 -0300
Subject: [Mongrel] cluster with environment variables
In-Reply-To: <4cbfccd70703051410n61e2332dm8ff551a6743dca2b@mail.gmail.com>
References: <4cbfccd70702231233g5b4defdy80981ae109c7d0d5@mail.gmail.com>
	<4cbfccd70703051410n61e2332dm8ff551a6743dca2b@mail.gmail.com>
Message-ID: <71166b3b0703051441u798537c6l37c9ff6bd6b1ab12@mail.gmail.com>

On 3/5/07, Jason Yates <jaywhy at gmail.com> wrote:
> I should have responded earlier to myself.  Just in case others have
> similar problems in the future.
>
> The problem wasn't mongrel at all.  However, the issue seemed to be
> coming from mongrel, because for whatever reason an error from Rjb
> wasn't getting logged
>
> The problem was Java was eating up all the available memory.  Because
> each mongrel instance would start its own Java process. The first one
> would steal all the available memory. Then the second couldn't even
> start because no memory was available.  Hence one mongrel instance
> would work the other wouldn't
>

You should have used BackgrounDrb and some queue/method to communicate
with your mongrel_cluster instead, that way, only one java process
will be running.

> The JRE does this because it checks for available system memory and
> allocates a portion of it.  Which is fine, however in my case I'm
> using a virtual server.  So I only had a 256mb portion of the 4gbs
> Java thought it had to play with.
>
> Anyways I blogged about it.  If anyone cares.
>
> http://jaywhy.wordpress.com/2007/03/05/pdf-templates-via-rails/
>

Still long-running process or process that eat a lot of resources from
your web application is wise, injecting them into the whole web
serving experience is a pain to debug.

Good to knwo you solved this.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From 2828628 at gmail.com  Tue Mar  6 00:11:17 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 13:11:17 +0800
Subject: [Mongrel] Memory leaks in my site
Message-ID: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>

Hi all,

My environment is ruby-1.8.4, rails 1.2.2, mongrel 1.0.1, linux 2.6. Now, i
have a problem on memory leaks with mongrel. My site is running 5 mongrel
processes on a 2G RAM machine, the memory of each process grows from about
20M to about 250M, but it never recover to the initial 20M, so i had to
restart the mongrel processes once per day. The load is about 1M hits per
day.

Waiting for your help, thanks.

Ken.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/584bf2c7/attachment-0001.html 

From luislavena at gmail.com  Tue Mar  6 00:45:07 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 6 Mar 2007 02:45:07 -0300
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
Message-ID: <71166b3b0703052145l7c08731s23b4a66a8d51cd9a@mail.gmail.com>

On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> Hi all,
>
> My environment is ruby-1.8.4, rails 1.2.2, mongrel 1.0.1, linux 2.6. Now, i
> have a problem on memory leaks with mongrel. My site is running 5 mongrel
> processes on a 2G RAM machine, the memory of each process grows from about
> 20M to about 250M, but it never recover to the initial 20M, so i had to
> restart the mongrel processes once per day. The load is about 1M hits per
> day.
>

Hello Ken,

A few things you share about your site are:

1) Using RMagick? or perform any other image manupulation/thumbnailing?
2) have fastthread gem installed?
3) perform file uploads thru rails? Or use send_file or file sending
of dynamic files from rails.

With that information other users on the list could share their
experiences, since every application uses different gem, libraries or
utilities, and offer a generic answer without deeper knowledge of the
problem is impossible.

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From jeremy at bitsweat.net  Tue Mar  6 00:53:30 2007
From: jeremy at bitsweat.net (Jeremy Kemper)
Date: Mon, 5 Mar 2007 21:53:30 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
Message-ID: <69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>

On 3/5/07, Ken Wei <2828628 at gmail.com> wrote:
>
> My environment is ruby-1.8.4, rails 1.2.2, mongrel 1.0.1, linux 2.6. Now,
> i have a problem on memory leaks with mongrel. My site is running 5 mongrel
> processes on a 2G RAM machine, the memory of each process grows from about
> 20M to about 250M, but it never recover to the initial 20M, so i had to
> restart the mongrel processes once per day. The load is about 1M hits per
> day.


Are you running in production or development mode?

jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070305/4742b397/attachment.html 

From 2828628 at gmail.com  Tue Mar  6 01:23:17 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 14:23:17 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
Message-ID: <2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>

Hi,

First of all thanks everyone for their responses.

> 1) Using RMagick? or perform any other image manupulation/thumbnailing?
nope

> 2) have fastthread gem installed?
yes, installed fastthread (0.6.4.1)

> 3) perform file uploads thru rails? Or use send_file or file sending of
dynamic files from rails.
nope

and, i'm running on production mode.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/b33dc2ed/attachment.html 

From 2828628 at gmail.com  Tue Mar  6 01:26:59 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 14:26:59 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
Message-ID: <2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>

installed MySQL/Ruby (2.7)
OS is CentOS release 4.2 (Final)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/4dd5e12d/attachment.html 

From 2828628 at gmail.com  Tue Mar  6 01:33:12 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 14:33:12 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
Message-ID: <2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>

Even test only a single url which reads a few records from mysql and then
display, the memory usage still keep growing and never recover again.

The test tool is httperf, this is the command i used:
httperf --server 192.168.1.1 --port 81 --rate 15 --uri /user/ken --num-call
1 --num-conn 1000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/a3f08d05/attachment.html 

From carl.lerche at gmail.com  Tue Mar  6 02:39:56 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Mon, 5 Mar 2007 23:39:56 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
Message-ID: <ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>

Do you use ferret at all? I found that ferret (and acts_as_ferret)
cause the memory usage to grow to ~200MB a process. Can you list all
your installed gems or at least all the gems that you are using?

-carl


On 3/5/07, Ken Wei <2828628 at gmail.com> wrote:
> Even test only a single url which reads a few records from mysql and then
> display, the memory usage still keep growing and never recover again.
>
> The test tool is httperf, this is the command i used:
>  httperf --server 192.168.1.1 --port 81 --rate 15 --uri /user/ken --num-call
> 1 --num-conn 1000
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From 2828628 at gmail.com  Tue Mar  6 02:50:56 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 15:50:56 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
Message-ID: <2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>

*** LOCAL GEMS ***

actionmailer (1.3.2, 1.2.5, 1.1.5)
    Service layer for easy email delivery and testing.

actionpack (1.13.2, 1.12.5, 1.11.2)
    Web-flow and rendering framework putting the VC in MVC.

actionwebservice (1.2.2, 1.1.6, 1.0.0)
    Web service support for Action Pack.

activerecord (1.15.2, 1.14.4, 1.13.2)
    Implements the ActiveRecord pattern for ORM.

activesupport (1.4.1, 1.3.1, 1.2.5)
    Support and utility classes used by the Rails framework.

cgi_multipart_eof_fix (2.1)
    Fix an exploitable bug in CGI multipart parsing which affects Ruby
    <= 1.8.5 when multipart boundary attribute contains a non-halting
    regular expression string.

daemons (1.0.5, 0.4.4)
    A toolkit to create and control daemons in different ways

fastthread (0.6.4.1)
    Optimized replacement for thread.rb primitives

gem_plugin (0.2.2, 0.2.1)
    A plugin system based only on rubygems that uses dependencies only

hoe (1.1.7)
    Hoe is a way to write Rakefiles much easier and cleaner.

hpricot (0.5)
    a swift, liberal HTML parser with a fantastic library

htmltokenizer (1.0)
    A class to tokenize HTML.

mechanize (0.6.4)
    Mechanize provides automated web-browsing

memcache-client (1.2.0, 1.0.3)
    A Ruby memcached client

mongrel (1.0.1)
    A small fast HTTP library and server that runs Rails, Camping, Nitro
    and Iowa apps.

mongrel_cluster (0.2.1)
    Mongrel plugin that provides commands and Capistrano tasks for
    managing multiple Mongrel processes.

mysql (2.7)
    MySQL/Ruby provides the same functions for Ruby programs that the
    MySQL C API provides for C programs.

rails (1.2.2, 1.1.6, 1.0.0)
    Web-application framework with template engine, control-flow layer,
    and ORM.

rake (0.7.1, 0.7.0)
    Ruby based make-like utility.

rubyforge (0.4.0)
    A simplistic script which automates a limited set of rubyforge
    operations

rubyzip (0.9.1)
    rubyzip is a ruby module for reading and writing zip files

sources (0.0.1)
    This package provides download sources for remote gem installation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/85452c99/attachment.html 

From wayneeseguin at gmail.com  Tue Mar  6 06:31:46 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 6 Mar 2007 06:31:46 -0500
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
Message-ID: <C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>

If you are able try doing a

 > gem cleanup

to remove old versions of gems.

I've seen one case where that fixed such an issue.

   ~Wayne

On Mar 06, 2007, at 02:50 , Ken Wei wrote:

> *** LOCAL GEMS ***
>
> actionmailer (1.3.2, 1.2.5, 1.1.5)
>     Service layer for easy email delivery and testing.
>
> actionpack (1.13.2, 1.12.5, 1.11.2)
>     Web-flow and rendering framework putting the VC in MVC.
>
> actionwebservice (1.2.2, 1.1.6, 1.0.0)
>     Web service support for Action Pack.
>
> activerecord (1.15.2, 1.14.4, 1.13.2)
>     Implements the ActiveRecord pattern for ORM.
>
> activesupport (1.4.1, 1.3.1 , 1.2.5)
>     Support and utility classes used by the Rails framework.
>
> cgi_multipart_eof_fix (2.1)
>     Fix an exploitable bug in CGI multipart parsing which affects Ruby
>     <= 1.8.5 when multipart boundary attribute contains a non-halting
>     regular expression string.
>
> daemons (1.0.5, 0.4.4)
>     A toolkit to create and control daemons in different ways
>
> fastthread (0.6.4.1)
>     Optimized replacement for thread.rb primitives
>
> gem_plugin (0.2.2, 0.2.1)
>     A plugin system based only on rubygems that uses dependencies only
>
> hoe (1.1.7)
>     Hoe is a way to write Rakefiles much easier and cleaner.
>
> hpricot (0.5 )
>     a swift, liberal HTML parser with a fantastic library
>
> htmltokenizer (1.0)
>     A class to tokenize HTML.
>
> mechanize (0.6.4)
>     Mechanize provides automated web-browsing
>
> memcache-client ( 1.2.0, 1.0.3)
>     A Ruby memcached client
>
> mongrel (1.0.1)
>     A small fast HTTP library and server that runs Rails, Camping,  
> Nitro
>     and Iowa apps.
>
> mongrel_cluster (0.2.1)
>     Mongrel plugin that provides commands and Capistrano tasks for
>     managing multiple Mongrel processes.
>
> mysql (2.7)
>     MySQL/Ruby provides the same functions for Ruby programs that the
>     MySQL C API provides for C programs.
>
> rails (1.2.2, 1.1.6, 1.0.0)
>     Web-application framework with template engine, control-flow  
> layer,
>     and ORM.
>
> rake (0.7.1, 0.7.0)
>     Ruby based make-like utility.
>
> rubyforge (0.4.0)
>     A simplistic script which automates a limited set of rubyforge
>     operations
>
> rubyzip (0.9.1)
>     rubyzip is a ruby module for reading and writing zip files
>
> sources (0.0.1)
>     This package provides download sources for remote gem installation
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From thegiive at roodo.com  Tue Mar  6 07:32:49 2007
From: thegiive at roodo.com (giive chen)
Date: Tue, 6 Mar 2007 20:32:49 +0800
Subject: [Mongrel] My Mongrel on Linux is not stable
Message-ID: <77f9ba960703060432v2b833ad6pa1c82617a901e5bb@mail.gmail.com>

Hello all
My app runs on Gentoo Linux with 2.6.18-gentoo-r6 and my CPU is
2.6.18-gentoo-r6.
The Mongrel version is 1.0.
I run mongrel cluster with 20 mongrel.

But after I lanuch my app, I found that there will be one rails application
error message in five or six request.
That means most of the request is normal but there will be 1/10 chance app
error.
But after I reload the error page, the status go to normal.
I found that some of the mongrel cluster crash but most of the cluster is
normal.
And the reverse proxy has 1/10 chance to redirect to the error mongrel.

After the mongrel cluster restart, everything goes to normal.
But one or two hours later, the status goes the same.

Could anyone give me some hint about what's going wrong?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/5348644d/attachment-0001.html 

From 2828628 at gmail.com  Tue Mar  6 07:49:48 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 20:49:48 +0800
Subject: [Mongrel] My Mongrel on Linux is not stable
In-Reply-To: <77f9ba960703060432v2b833ad6pa1c82617a901e5bb@mail.gmail.com>
References: <77f9ba960703060432v2b833ad6pa1c82617a901e5bb@mail.gmail.com>
Message-ID: <2a0834610703060449y3673aab5s15498b31fb65fff2@mail.gmail.com>

Try to run less mongrel processes. How large is your total RAM?

Ken.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/f51ffd92/attachment.html 

From 2828628 at gmail.com  Tue Mar  6 09:44:53 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 22:44:53 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
Message-ID: <2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>

'gem cleanup' i did that, but still
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/b65bcedf/attachment.html 

From jgeiger at gmail.com  Tue Mar  6 10:50:52 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 6 Mar 2007 09:50:52 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
Message-ID: <466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>

I've got issues with my rails application leaking memory as well. I
can say it's not Mongrel's fault, as I was able to duplicate the
situation in Webbrick.

My problem happens because I'm using monit to make sure my site stays
up, but in doing so, monit hits each of my mongrels every minute. I
thought the memory issues had to do with images, send_data or
something else, and what I found, is that on a site that does nothing
but respond to this monit controller, the memory grew and grew.

I'm guessing it has to do with the plugins I'm using, as when I tried
the same thing on a fresh rails application, the memory grew, but
capped off at about 35MB, where the full application loading all
plugins continued to grow until I killed it, never recovering memory.

So, for now, monit is the cause and solution to my memory problems. I
was thinking about trying to create a handler for mongrel that monit
can hit to verify that it's running, but then there's the possibility
that mongrel is up, but my application is down.

My other issue with using monit are the constant hits to the log
files, which logger.silence doesn't help (at least the methods I've
tried) If someone knows how to silence a controller completely, I'd
love to know.

Right now I'm a bit busy, but I think it would be a good test to add
my plugins one at a time to a fresh application and check the memory
usage after hitting it with a few thousand hits from apache bench.


On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> 'gem cleanup' i did that, but still
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From zedshaw at zedshaw.com  Tue Mar  6 14:08:24 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 6 Mar 2007 11:08:24 -0800
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast
Message-ID: <20070306110824.8a3e1d54.zedshaw@zedshaw.com>

Hey Everyone,

Topfunky (Geoffry) has created a great PeepCode screencast on using
httperf to performance measure your web applications:

http://nubyonrails.topfunky.com/articles/2007/03/05/peepcode-page-caching-and-httperf

http://peepcode.com/products/benchmarking-with-httperf

Topfunky put a ton of work into this and really got it right.  The
attention to detail is very good and he researched the subject
thoroughly.  I also spent time reviewing it so that he'd get the
statistics right, but he did a lot more than I expected.

The main thing that you'll get from his screencast is the actual
*process* of doing an analysis and then determining if there's
differences.  He shows graphs, takes notes, covers basic statistics,
and shows you how to figure out how fast your Mongrel setup can go.
It's much better watching someone else do it than reading a description.

Everyone who constantly asks about how to performance measure their web
apps should grab it and go through it.

Why am I pimping it so hard?  First, he's giving me a cut of the dough
and a brotha's gotta eat.  :-)  Second, it is probably the first
description of performance measurement and analysis I've seen that
actually gets it right.

Thanks for your time, and enjoy the day.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From alexey.verkhovsky at gmail.com  Tue Mar  6 12:11:40 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 6 Mar 2007 10:11:40 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
Message-ID: <3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>

So, memory leak is the problem, and monit is just highlighting it. Is that
correct?

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/446d94fe/attachment.html 

From carl.lerche at gmail.com  Tue Mar  6 12:35:01 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Tue, 6 Mar 2007 09:35:01 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
Message-ID: <ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>

Did you try adding GC.start in your application?

On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
> I've got issues with my rails application leaking memory as well. I
> can say it's not Mongrel's fault, as I was able to duplicate the
> situation in Webbrick.
>
> My problem happens because I'm using monit to make sure my site stays
> up, but in doing so, monit hits each of my mongrels every minute. I
> thought the memory issues had to do with images, send_data or
> something else, and what I found, is that on a site that does nothing
> but respond to this monit controller, the memory grew and grew.
>
> I'm guessing it has to do with the plugins I'm using, as when I tried
> the same thing on a fresh rails application, the memory grew, but
> capped off at about 35MB, where the full application loading all
> plugins continued to grow until I killed it, never recovering memory.
>
> So, for now, monit is the cause and solution to my memory problems. I
> was thinking about trying to create a handler for mongrel that monit
> can hit to verify that it's running, but then there's the possibility
> that mongrel is up, but my application is down.
>
> My other issue with using monit are the constant hits to the log
> files, which logger.silence doesn't help (at least the methods I've
> tried) If someone knows how to silence a controller completely, I'd
> love to know.
>
> Right now I'm a bit busy, but I think it would be a good test to add
> my plugins one at a time to a fresh application and check the memory
> usage after hitting it with a few thousand hits from apache bench.
>
>
> On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> > 'gem cleanup' i did that, but still
> >
> > _______________________________________________
> > 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
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From rsanheim at gmail.com  Tue Mar  6 12:36:02 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Tue, 6 Mar 2007 11:36:02 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
Message-ID: <fc113d400703060936m7383660oe07529330662919f@mail.gmail.com>

Can you do a dump of all the plugins you are using?  There are some
that are well known to be problematic with memory leaks.

- R0b

On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
> I've got issues with my rails application leaking memory as well. I
> can say it's not Mongrel's fault, as I was able to duplicate the
> situation in Webbrick.
>
> My problem happens because I'm using monit to make sure my site stays
> up, but in doing so, monit hits each of my mongrels every minute. I
> thought the memory issues had to do with images, send_data or
> something else, and what I found, is that on a site that does nothing
> but respond to this monit controller, the memory grew and grew.
>
> I'm guessing it has to do with the plugins I'm using, as when I tried
> the same thing on a fresh rails application, the memory grew, but
> capped off at about 35MB, where the full application loading all
> plugins continued to grow until I killed it, never recovering memory.
>
> So, for now, monit is the cause and solution to my memory problems. I
> was thinking about trying to create a handler for mongrel that monit
> can hit to verify that it's running, but then there's the possibility
> that mongrel is up, but my application is down.
>
> My other issue with using monit are the constant hits to the log
> files, which logger.silence doesn't help (at least the methods I've
> tried) If someone knows how to silence a controller completely, I'd
> love to know.
>
> Right now I'm a bit busy, but I think it would be a good test to add
> my plugins one at a time to a fresh application and check the memory
> usage after hitting it with a few thousand hits from apache bench.
>
>
> On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> > 'gem cleanup' i did that, but still
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From 2828628 at gmail.com  Tue Mar  6 12:54:43 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 01:54:43 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
Message-ID: <2a0834610703060954q389582ccvdcdc6eb094ef773d@mail.gmail.com>

> Did you try adding GC.start in your application?

yep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/58be976b/attachment.html 

From jgeiger at gmail.com  Tue Mar  6 13:24:06 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 6 Mar 2007 12:24:06 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
Message-ID: <466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>

Here are the plugins that were on the application when I just tried
loading a single controller, which ended up hitting an 80MB limit
after about 8 hours on all 4 mongrels running rails 1.2.2. They all
restarted within minutes of each other, which was interesting.

acts_as_ferret
arts
authorization
custom-err-msg
exception_notification
flex_image
has_many_polymorphs
http_url_validation
paginating_find
rails_rcov
resource_feeder (added after test)
restful_authentication
routing_navigator
simply_helpful
sql_session_store
timed_fragment_cache

The application I have in development that restarts every few days has
the following plugins.
acts_as_authenticated
acts_as_rateable
arts
assert_select
authorization
browser_filters
custom-err-msg
debug_view_helper
exception_notification
flex_image
paginating_find
rails_rcov
responsible_markup
simple_http_auth
timed_fragment_cache
white_list

I ran the tests with and without GC.start in the controller.
GC.start kicked off in the production application when I do a send_data call.




On 3/6/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> Did you try adding GC.start in your application?
>
> On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
> > I've got issues with my rails application leaking memory as well. I
> > can say it's not Mongrel's fault, as I was able to duplicate the
> > situation in Webbrick.
> >
> > My problem happens because I'm using monit to make sure my site stays
> > up, but in doing so, monit hits each of my mongrels every minute. I
> > thought the memory issues had to do with images, send_data or
> > something else, and what I found, is that on a site that does nothing
> > but respond to this monit controller, the memory grew and grew.
> >
> > I'm guessing it has to do with the plugins I'm using, as when I tried
> > the same thing on a fresh rails application, the memory grew, but
> > capped off at about 35MB, where the full application loading all
> > plugins continued to grow until I killed it, never recovering memory.
> >
> > So, for now, monit is the cause and solution to my memory problems. I
> > was thinking about trying to create a handler for mongrel that monit
> > can hit to verify that it's running, but then there's the possibility
> > that mongrel is up, but my application is down.
> >
> > My other issue with using monit are the constant hits to the log
> > files, which logger.silence doesn't help (at least the methods I've
> > tried) If someone knows how to silence a controller completely, I'd
> > love to know.
> >
> > Right now I'm a bit busy, but I think it would be a good test to add
> > my plugins one at a time to a fresh application and check the memory
> > usage after hitting it with a few thousand hits from apache bench.
> >
> >
> > On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> > > 'gem cleanup' i did that, but still
> > >
> > > _______________________________________________
> > > 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
> >
>
>
> --
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From mongrel at philip.pjkh.com  Tue Mar  6 14:08:32 2007
From: mongrel at philip.pjkh.com (Philip Hallstrom)
Date: Tue, 6 Mar 2007 13:08:32 -0600 (CST)
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
	<466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>
Message-ID: <20070306130753.T42542@bravo.pjkh.com>

> The application I have in development that restarts every few days has
> the following plugins.
> acts_as_authenticated
> acts_as_rateable
> arts
> assert_select
> authorization
> browser_filters
> custom-err-msg
> debug_view_helper
> exception_notification
> flex_image

flex_image uses rmagick... which folks have lots of issues with...

> paginating_find
> rails_rcov
> responsible_markup
> simple_http_auth
> timed_fragment_cache
> white_list
>
> I ran the tests with and without GC.start in the controller.
> GC.start kicked off in the production application when I do a send_data call.
>
>
>
>
> On 3/6/07, Carl Lerche <carl.lerche at gmail.com> wrote:
>> Did you try adding GC.start in your application?
>>
>> On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
>>> I've got issues with my rails application leaking memory as well. I
>>> can say it's not Mongrel's fault, as I was able to duplicate the
>>> situation in Webbrick.
>>>
>>> My problem happens because I'm using monit to make sure my site stays
>>> up, but in doing so, monit hits each of my mongrels every minute. I
>>> thought the memory issues had to do with images, send_data or
>>> something else, and what I found, is that on a site that does nothing
>>> but respond to this monit controller, the memory grew and grew.
>>>
>>> I'm guessing it has to do with the plugins I'm using, as when I tried
>>> the same thing on a fresh rails application, the memory grew, but
>>> capped off at about 35MB, where the full application loading all
>>> plugins continued to grow until I killed it, never recovering memory.
>>>
>>> So, for now, monit is the cause and solution to my memory problems. I
>>> was thinking about trying to create a handler for mongrel that monit
>>> can hit to verify that it's running, but then there's the possibility
>>> that mongrel is up, but my application is down.
>>>
>>> My other issue with using monit are the constant hits to the log
>>> files, which logger.silence doesn't help (at least the methods I've
>>> tried) If someone knows how to silence a controller completely, I'd
>>> love to know.
>>>
>>> Right now I'm a bit busy, but I think it would be a good test to add
>>> my plugins one at a time to a fresh application and check the memory
>>> usage after hitting it with a few thousand hits from apache bench.
>>>
>>>
>>> On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
>>>> 'gem cleanup' i did that, but still
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> --
>> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From public at misuse.org  Tue Mar  6 14:12:00 2007
From: public at misuse.org (Steve Midgley)
Date: Tue, 06 Mar 2007 11:12:00 -0800
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast (Zed A.
	Shaw)
In-Reply-To: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
References: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
Message-ID: <20070306192512.E547D5242072@rubyforge.org>

Hi,

Thanks Zed - this is very interesting. One item in particular caught my 
eye: Does anyone on this list have any comments or validation that 
Rails 1.2.1 is 2-4 times as slow as Rails 1.1.6? Topfunky provided a 
link that purports what looks like really horrible performance and 
memory characteristics for Rails 1.2.1, even v. 1.1.6:

http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/

Did Rails 1.2.2 fix anything in this regard? (I didn't see any mention 
of performance improvements in the dev notes).

There were some nice feature upgrades in 1.2.1 that I'm using, but it 
would be great to know that performance is now a real issue (and 
rolling back would fix it).

Any information?

Thanks,

Steve


>Message: 4
>Date: Tue, 6 Mar 2007 11:08:24 -0800
>From: "Zed A. Shaw" <zedshaw at zedshaw.com>
>Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast
>To: mongrel-users at rubyforge.org
>Message-ID: <20070306110824.8a3e1d54.zedshaw at zedshaw.com>
>Content-Type: text/plain; charset=US-ASCII
>
>Hey Everyone,
>
>Topfunky (Geoffry) has created a great PeepCode screencast on using
>httperf to performance measure your web applications:
>
>http://nubyonrails.topfunky.com/articles/2007/03/05/peepcode-page-caching-and-httperf
>
>http://peepcode.com/products/benchmarking-with-httperf
>
>Topfunky put a ton of work into this and really got it right.  The
>attention to detail is very good and he researched the subject
>thoroughly.  I also spent time reviewing it so that he'd get the
>statistics right, but he did a lot more than I expected.
>
>The main thing that you'll get from his screencast is the actual
>*process* of doing an analysis and then determining if there's
>differences.  He shows graphs, takes notes, covers basic statistics,
>and shows you how to figure out how fast your Mongrel setup can go.
>It's much better watching someone else do it than reading a 
>description.
>
>Everyone who constantly asks about how to performance measure their 
>web
>apps should grab it and go through it.
>
>Why am I pimping it so hard?  First, he's giving me a cut of the dough
>and a brotha's gotta eat.  :-)  Second, it is probably the first
>description of performance measurement and analysis I've seen that
>actually gets it right.
>
>Thanks for your time, and enjoy the day.
>
>--
>Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
>http://www.zedshaw.com/
>http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
>http://mongrel.rubyforge.org/
>


From joost at spacebabies.nl  Tue Mar  6 15:13:06 2007
From: joost at spacebabies.nl (joost baaij)
Date: Tue, 6 Mar 2007 21:13:06 +0100
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast (Zed A.
	Shaw)
In-Reply-To: <20070306192512.E547D5242072@rubyforge.org>
References: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
	<20070306192512.E547D5242072@rubyforge.org>
Message-ID: <A0C817B9-06FA-4541-A699-7E3AE46E13AA@spacebabies.nl>

Hmm, reading that I am growing more suspicious. My ram-related woes  
appeared when Rails 1.2 hit the stage. But I also saw a hefty  
increase in traffic so was quick to blame it on that.


Op 6-mrt-2007, om 20:12 heeft Steve Midgley het volgende geschreven:

> Hi,
>
> Thanks Zed - this is very interesting. One item in particular  
> caught my
> eye: Does anyone on this list have any comments or validation that
> Rails 1.2.1 is 2-4 times as slow as Rails 1.1.6? Topfunky provided a
> link that purports what looks like really horrible performance and
> memory characteristics for Rails 1.2.1, even v. 1.1.6:
>
> http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading- 
> frameworks/
>
> Did Rails 1.2.2 fix anything in this regard? (I didn't see any mention
> of performance improvements in the dev notes).
>
> There were some nice feature upgrades in 1.2.1 that I'm using, but it
> would be great to know that performance is now a real issue (and
> rolling back would fix it).
>
> Any information?
>
> Thanks,
>
> Steve
>
>
>> Message: 4
>> Date: Tue, 6 Mar 2007 11:08:24 -0800
>> From: "Zed A. Shaw" <zedshaw at zedshaw.com>
>> Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast
>> To: mongrel-users at rubyforge.org
>> Message-ID: <20070306110824.8a3e1d54.zedshaw at zedshaw.com>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> Hey Everyone,
>>
>> Topfunky (Geoffry) has created a great PeepCode screencast on using
>> httperf to performance measure your web applications:
>>
>> http://nubyonrails.topfunky.com/articles/2007/03/05/peepcode-page- 
>> caching-and-httperf
>>
>> http://peepcode.com/products/benchmarking-with-httperf
>>
>> Topfunky put a ton of work into this and really got it right.  The
>> attention to detail is very good and he researched the subject
>> thoroughly.  I also spent time reviewing it so that he'd get the
>> statistics right, but he did a lot more than I expected.
>>
>> The main thing that you'll get from his screencast is the actual
>> *process* of doing an analysis and then determining if there's
>> differences.  He shows graphs, takes notes, covers basic statistics,
>> and shows you how to figure out how fast your Mongrel setup can go.
>> It's much better watching someone else do it than reading a
>> description.
>>
>> Everyone who constantly asks about how to performance measure their
>> web
>> apps should grab it and go through it.
>>
>> Why am I pimping it so hard?  First, he's giving me a cut of the  
>> dough
>> and a brotha's gotta eat.  :-)  Second, it is probably the first
>> description of performance measurement and analysis I've seen that
>> actually gets it right.
>>
>> Thanks for your time, and enjoy the day.
>>
>> --
>> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
>> http://www.zedshaw.com/
>> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
>> http://mongrel.rubyforge.org/
>>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- 
www.gomagazine.nl +31643904460 pobox 51059 nl-1007eb amsterdam




From jgeiger at gmail.com  Tue Mar  6 15:34:34 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 6 Mar 2007 14:34:34 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
Message-ID: <466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>

> flex_image uses rmagick... which folks have lots of issues with...

I re-wrote the bits of flex_image that I use to use mini-magick and
it's working quite nicely.
I did that when the whole discussion of "RMagick bad" came up a couple
of months ago.

On 3/6/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> So, memory leak is the problem, and monit is just highlighting it. Is that
> correct?

For me, yes. I'm not exactly sure what is happening, but on my current
application, the only controller that was hit overnight was the monit
checker, which was enough to cause the leak.

Here's a copy of the controller, which I've tried to strip down as
much as possible. (On my current production app, it's doing 10k
requests per second :)

class MonitController < ActionController::Base
  session :off
##   this is used by the monitoring scripts to see if the mongrel is
up and running
  def index
  end
end

From ezmobius at gmail.com  Tue Mar  6 16:17:45 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 6 Mar 2007 13:17:45 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
Message-ID: <3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>


On Mar 6, 2007, at 12:34 PM, Joey Geiger wrote:

>> flex_image uses rmagick... which folks have lots of issues with...
>
> I re-wrote the bits of flex_image that I use to use mini-magick and
> it's working quite nicely.
> I did that when the whole discussion of "RMagick bad" came up a couple
> of months ago.
>
> On 3/6/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
>> So, memory leak is the problem, and monit is just highlighting it.  
>> Is that
>> correct?
>
> For me, yes. I'm not exactly sure what is happening, but on my current
> application, the only controller that was hit overnight was the monit
> checker, which was enough to cause the leak.
>
> Here's a copy of the controller, which I've tried to strip down as
> much as possible. (On my current production app, it's doing 10k
> requests per second :)
>
> class MonitController < ActionController::Base
>   session :off
> ##   this is used by the monitoring scripts to see if the mongrel is
> up and running
>   def index
>   end
> end


	I have seen weird behavior from having monit check with a http  
request. It woudl cause weird issues and mem leaks. I have since  
removed any http checks from all my monit recipes and used an  
external siteuptime monitoring for http status check. Monit just  
watches memory and cpu usage and restarts dead or bloated mongrels.

	It's just a fact of life with large rails applications, some of them  
just like to keep using memory as much as possible. I have found that  
restarting mongrels that go over 110Mb for a few cycles will keep  
things in check pretty well. This is for 64bit systems where memory  
usage is higher then on 32 bit systems.

	Here is a monit recipe I am using on a large number of servers that  
seems to work very well.

set httpd port 9111
     allow localhost

set daemon 60
set logfile /data/username/shared/log/monit.log
set mail-format {from:info at engineyard.com}
set mailserver smtp.engineyard.com
set alert eymonit at gmail.com

check process mongrel_username_0
   with pidfile /data/username/shared/log/mongrel.5000.pid
   start program = "/data/username/shared/bin/start_mongrel.sh 5000  
username"
   stop program = "/data/username/shared/bin/stop_mongrel.sh 5000  
username"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 10 restarts within 10 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_username_1
   with pidfile /data/username/shared/log/mongrel.5001.pid
   start program = "/data/username/shared/bin/start_mongrel.sh 5001  
username"
   stop program = "/data/username/shared/bin/stop_mongrel.sh 5001  
username"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 10 restarts within 10 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_username_2
   with pidfile /data/username/shared/log/mongrel.5002.pid
   start program = "/data/username/shared/bin/start_mongrel.sh 5002  
username"
   stop program = "/data/username/shared/bin/stop_mongrel.sh 5002  
username"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 10 restarts within 10 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel


Cheers-
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



From rsanheim at gmail.com  Tue Mar  6 16:23:20 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Tue, 6 Mar 2007 15:23:20 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
Message-ID: <fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>

On 3/6/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> On Mar 6, 2007, at 12:34 PM, Joey Geiger wrote:
>
> >> flex_image uses rmagick... which folks have lots of issues with...
> >
> > I re-wrote the bits of flex_image that I use to use mini-magick and
> > it's working quite nicely.
> > I did that when the whole discussion of "RMagick bad" came up a couple
> > of months ago.
> >
> > On 3/6/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> >> So, memory leak is the problem, and monit is just highlighting it.
> >> Is that
> >> correct?
> >
> > For me, yes. I'm not exactly sure what is happening, but on my current
> > application, the only controller that was hit overnight was the monit
> > checker, which was enough to cause the leak.
> >
> > Here's a copy of the controller, which I've tried to strip down as
> > much as possible. (On my current production app, it's doing 10k
> > requests per second :)
> >
> > class MonitController < ActionController::Base
> >   session :off
> > ##   this is used by the monitoring scripts to see if the mongrel is
> > up and running
> >   def index
> >   end
> > end
>
>
>         I have seen weird behavior from having monit check with a http
> request. It woudl cause weird issues and mem leaks. I have since
> removed any http checks from all my monit recipes and used an
> external siteuptime monitoring for http status check. Monit just
> watches memory and cpu usage and restarts dead or bloated mongrels.
>
>         It's just a fact of life with large rails applications, some of them
> just like to keep using memory as much as possible. I have found that
> restarting mongrels that go over 110Mb for a few cycles will keep
> things in check pretty well. This is for 64bit systems where memory
> usage is higher then on 32 bit systems.
>
>         Here is a monit recipe I am using on a large number of servers that
> seems to work very well.
>
> set httpd port 9111
>      allow localhost
>
> set daemon 60
> set logfile /data/username/shared/log/monit.log
> set mail-format {from:info at engineyard.com}
> set mailserver smtp.engineyard.com
> set alert eymonit at gmail.com
>
> check process mongrel_username_0
>    with pidfile /data/username/shared/log/mongrel.5000.pid
>    start program = "/data/username/shared/bin/start_mongrel.sh 5000
> username"
>    stop program = "/data/username/shared/bin/stop_mongrel.sh 5000
> username"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 10 restarts within 10 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_username_1
>    with pidfile /data/username/shared/log/mongrel.5001.pid
>    start program = "/data/username/shared/bin/start_mongrel.sh 5001
> username"
>    stop program = "/data/username/shared/bin/stop_mongrel.sh 5001
> username"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 10 restarts within 10 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_username_2
>    with pidfile /data/username/shared/log/mongrel.5002.pid
>    start program = "/data/username/shared/bin/start_mongrel.sh 5002
> username"
>    stop program = "/data/username/shared/bin/stop_mongrel.sh 5002
> username"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 10 restarts within 10 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel

Ezra,

What do you use for uptime monitoring?  I haven't found anything out
of the box that can check often enough (ie at least every minute).

- Rob

From ezmobius at gmail.com  Tue Mar  6 16:38:12 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 6 Mar 2007 13:38:12 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
Message-ID: <64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>


On Mar 6, 2007, at 1:23 PM, Rob Sanheim wrote:

> On 3/6/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>> snip
>
> Ezra,
>
> What do you use for uptime monitoring?  I haven't found anything out
> of the box that can check often enough (ie at least every minute).
>
> - Rob


Rob-

	We use http://siteuptime.com/ for an external site health check that  
checks every 2 minutes from SF, NYC, Florida and London. We also have  
health checking going on in our load balancers with alerts in closer  
to real time.


Cheers-
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



From alexey.verkhovsky at gmail.com  Tue Mar  6 17:31:13 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 6 Mar 2007 15:31:13 -0700
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
In-Reply-To: <45EBC251.2060807@gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
	<45EBC251.2060807@gmail.com>
Message-ID: <3945c4270703061431p1b77f33amcb7205d0e7619fca@mail.gmail.com>

> My personal experience points to the contrary, using FCGI listeners (if
> you have the option of dumping apache for lighttpd) works well. Just spawn
> the fcgi listeners externally from script/process/spinner


I've seen and heard many enough conversations along the lines of "FastCGI
leaves zombie Ruby processes floating around", 6 to 12 months ago.
Sure, you can harvest those things with a Cron job, but doesn't this smell
funny?

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/46680b91/attachment.html 

From 2828628 at gmail.com  Wed Mar  7 00:06:17 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 13:06:17 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
Message-ID: <2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>

I created a new rails app named 'test' which containing only a controller
and an action .
Here is the controller:

class MyTestController < ApplicationController

        def index
                render_text 'Hello!'
        end

end

I keeped the setup as the same as before. Then i ran a single mongrel server
which listening on 3000 by default, and used httperf to hit the action:

httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test --num-call
1 --num-conn 10000

The memory usage of the mongrel server grows from 20M to 144M in 20 seconds,
it's crazy!
And i tryed Lighttpd + FastCGI to test this case, it works well. Then i
think about if i need to roll back to the fastcgi way? is the mongrel the
future of the rails community?

confused! confused! confused!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/dc3bb504/attachment.html 

From 2828628 at gmail.com  Wed Mar  7 00:16:48 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 13:16:48 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
Message-ID: <2a0834610703062116u458d25aak9657fae278931262@mail.gmail.com>

is mongrel still far from production ready? or did i make something wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/aab628a2/attachment.html 

From kylekochis at gmail.com  Wed Mar  7 01:12:16 2007
From: kylekochis at gmail.com (Kyle Kochis)
Date: Tue, 6 Mar 2007 23:12:16 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703062116u458d25aak9657fae278931262@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<2a0834610703062116u458d25aak9657fae278931262@mail.gmail.com>
Message-ID: <6a7034b0703062212g5d406a81u8b3fd52c7310a271@mail.gmail.com>

There has got to be something seriously wrong with your stack/install
although I am not knowledgeable enough to tell you where to start
looking.
Kyle Kochis

On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> is mongrel still far from production ready? or did i make something wrong?
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From alexey.verkhovsky at gmail.com  Wed Mar  7 01:55:06 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 00:55:06 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
Message-ID: <3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>

On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
Hey,

Looks like we are on the same stage of the learning curve about this stuff.
So, let's share our discoveries with the rest of the world :)

httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test --num-call
> 1 --num-conn 10000
>
> The memory usage of the mongrel server grows from 20M to 144M in 20
> seconds, it's


This is exactly what Mongrel does when it cannot cope with the incoming
traffic. I've discovered the same effect today.

You are definitely overloading it with 80 requests per second. After all,
it's a single-threaded instance of a fairly CPU-heavy framework. With no
page caching it should cope with ~10 to 30 requests per second max.

The crappy part about this, after the overload condition is off, the Mongrel
process stays at 150Mb. Not a problem when you are hosting one app on the
box, but becomes a problem when it's ten.

By the way, check the errors section of httperf report, and the
production.log. See if there are "fd_unavailable" socket errors in the
former, and probably some complaints about "too many files open" in the
latter. If there are, you need to either increase the number of file
descriptors in the Linux kernel, or decrease the max number of open sockets
in the Mongrel(s), with -n option. I don't know if it solves the "RAM
footprint growing to 150 Mb" problem... I will know it first thing tomorrow
morning :)

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/ea2b19f4/attachment.html 

From jacob at jacobatzen.dk  Wed Mar  7 03:21:23 2007
From: jacob at jacobatzen.dk (Jacob Atzen)
Date: Wed, 7 Mar 2007 09:21:23 +0100
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
References: <C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
Message-ID: <20070307082123.GB74355@apoc.jacobatzen.dk>

On Wed, Mar 07, 2007 at 12:55:06AM -0600, Alexey Verkhovsky wrote:
> This is exactly what Mongrel does when it cannot cope with the incoming
> traffic. I've discovered the same effect today.
> 
> You are definitely overloading it with 80 requests per second. After all,
> it's a single-threaded instance of a fairly CPU-heavy framework. With no
> page caching it should cope with ~10 to 30 requests per second max.
> 
> The crappy part about this, after the overload condition is off, the Mongrel
> process stays at 150Mb. Not a problem when you are hosting one app on the
> box, but becomes a problem when it's ten.

I've had some success reducing the number of processors. Try reducing
this somewhat and see if it helps.

-- 
Cheers,
- Jacob Atzen

From 2828628 at gmail.com  Wed Mar  7 05:26:47 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 18:26:47 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <20070307082123.GB74355@apoc.jacobatzen.dk>
References: <C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<20070307082123.GB74355@apoc.jacobatzen.dk>
Message-ID: <2a0834610703070226y17e716c7tbf366f3d3c6d9529@mail.gmail.com>

>Looks like we are on the same stage of the learning curve about this stuff.
So, let's share our discoveries with >the rest of the world :)

httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test --num-call
> 1 --num-conn 10000
>
> The memory usage of the mongrel server grows from 20M to 144M in 20
> seconds, it's


>This is exactly what Mongrel does when it cannot cope with the incoming
traffic. I've discovered the same >effect today.

>You are definitely overloading it with 80 requests per second. After all,
it's a single-threaded instance of a fairly >CPU-heavy framework. With no
page caching it should cope with ~10 to 30 requests per second max.

Yes, it's overload with message 'Too many open files...'. Anyway this test
doesn't shoot the heart of this issue. I should make the other one later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/832cc7ca/attachment.html 

From wyhaines at gmail.com  Wed Mar  7 06:14:57 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 7 Mar 2007 04:14:57 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
Message-ID: <f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>

On 3/6/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:

> Looks like we are on the same stage of the learning curve about this stuff.
> So, let's share our discoveries with the rest of the world :)
>
> > httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test
> --num-call 1 --num-conn 10000
> >
> > The memory usage of the mongrel server grows from 20M to 144M in 20
> seconds, it's
>
> This is exactly what Mongrel does when it cannot cope with the incoming
> traffic. I've discovered the same effect today.

I think it's fair to make a distinction here.

What is probably happening is that Rails is not keeping up with that
80 reqs/second rate; it's not Mongrel.  On any remotely modern
hardware, Mongrel will easily keep that pace itself.

However, the net effect is that Mongrel creates a thread for each
accepted connection.  These threads are fairly memory intensive, since
each one carries with it a fair amount of context, yet all they are
doing is sitting there sleeping behind a mutex, waiting for their
chance to wake up and run their request through the Rails handler.

> By the way, check the errors section of httperf report, and the
> production.log. See if there are "fd_unavailable" socket errors in the
> former, and probably some complaints about "too many files open" in the
> latter. If there are, you need to either increase the number of file
> descriptors in the Linux kernel, or decrease the max number of open sockets
> in the Mongrel(s), with -n option. I don't know if it solves the "RAM
> footprint growing to 150 Mb" problem... I will know it first thing tomorrow
> morning :)

No.  That is probably happening because of the file descriptor limit
in Ruby.  Your Mongrel has accepted as many connections as Ruby can
handle; it is out of descriptors.


Kirk Haines

From rancor at mindspring.com  Wed Mar  7 08:21:33 2007
From: rancor at mindspring.com (Jim Powers)
Date: Wed, 07 Mar 2007 08:21:33 -0500
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast (Zed A.
 Shaw)
In-Reply-To: <20070306192512.E547D5242072@rubyforge.org>
References: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
	<20070306192512.E547D5242072@rubyforge.org>
Message-ID: <20070307082133.08996836@nomadII.powershouse.bogus>

On Tue, 06 Mar 2007 11:12:00 -0800
Steve Midgley <public at misuse.org> wrote:

> Thanks Zed - this is very interesting. One item in particular caught
> my eye: Does anyone on this list have any comments or validation that 
> Rails 1.2.1 is 2-4 times as slow as Rails 1.1.6? Topfunky provided a 
> link that purports what looks like really horrible performance and 
> memory characteristics for Rails 1.2.1, even v. 1.1.6:
> 
> http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/
> 
> Did Rails 1.2.2 fix anything in this regard? (I didn't see any
> mention of performance improvements in the dev notes).
> 
> There were some nice feature upgrades in 1.2.1 that I'm using, but it 
> would be great to know that performance is now a real issue (and 
> rolling back would fix it).

I have been doing my own investigations into this issue, in particular,
I'm looking for at least one cause of an unacceptable slowdown that I
have been encountering (I will now go back and redo the tests under
1.1.6 for comparison).  In particular I've been observing *really poor*
performance with ActiveRecord.  In particular, when I run with the
profiler I'm seeing a stunning number of calls to the inflector methods.

Here "my" deal:

I have a class that only inherits from ActiveRecord so I get some SQL
logging.  It actually is using the driver directly (in this case
unixODBC) because I am calling a stored procedure that returns multiple
result sets (something ActiveRecord cannot do). So I have a "find"
method that returns a simple collection of hashes, nothing more.  I
benchmarked 100 calls and found that the inflector methods were the
overall most time consuming part of the effort with over 40K calls!
Now, the stuff returned form the 'find' call are not even derived from
ActiveRecord so I would expect a total of 0 (zero) such calls.

The best I can tell is that there must be a whole lotta new after
filters in 1.2.x doing lots of Rails magic.

Still investigating.

Jim Powers

From joe_lester at sweetwater.com  Wed Mar  7 08:02:23 2007
From: joe_lester at sweetwater.com (Joe Lester)
Date: Wed, 7 Mar 2007 08:02:23 -0500
Subject: [Mongrel] Long URLs - New to Mongrel
Message-ID: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>

My rails web app (rails 1.2.1) uploads an image from a Java applet by  
encoding it into the URL. This works fine when I'm using Webrick. I'm  
trying out Mongrel today, and I'm getting an error in Safari that  
says ?lost network connection? (NSURLErrorDomain:-1005). I get  
something similar in Firefox. Is there a way to make Mongrel accept a  
really long URL like this?

Thanks. Joe.

I'm encoding the 512 x 512 jpeg image as Base64. The long URL is  
something like...

http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD% 
2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ 
EBAQEBAQEBAQEBAQEBAQH% 
2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ 
EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB% 
2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL% 
2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA 
kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd 
4eXqDhIWGh4iJipKTlJWW......... [much more]

When the URL is long, the action is not called in rails. But, if I  
remove the image from the URL, then the action is called.

From rancor at mindspring.com  Wed Mar  7 08:03:59 2007
From: rancor at mindspring.com (Jim Powers)
Date: Wed, 07 Mar 2007 08:03:59 -0500
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
Message-ID: <20070307080359.64394ef6@nomadII.powershouse.bogus>

On Wed, 7 Mar 2007 04:14:57 -0700
"Kirk Haines" <wyhaines at gmail.com> wrote:

> > By the way, check the errors section of httperf report, and the
> > production.log. See if there are "fd_unavailable" socket errors in
> > the former, and probably some complaints about "too many files
> > open" in the latter. If there are, you need to either increase the
> > number of file descriptors in the Linux kernel, or decrease the max
> > number of open sockets in the Mongrel(s), with -n option. I don't
> > know if it solves the "RAM footprint growing to 150 Mb" problem...
> > I will know it first thing tomorrow morning :)
> 
> No.  That is probably happening because of the file descriptor limit
> in Ruby.  Your Mongrel has accepted as many connections as Ruby can
> handle; it is out of descriptors.

What file descriptor limit are you referring to?  A typical Linux
<default> ulimit on file descriptors is 1024, which should be more than
enough for the test Ken is performing.

Also, I would recommend doing a test where you separate Mongrel from
Rails.  Use a simple Mongrel handler like the one found here:

http://mongrel.rubyforge.org/rdoc/index.html

require 'mongrel'

 class SimpleHandler < Mongrel::HttpHandler
    def process(request, response)
      response.start(200) do |head,out|
        head["Content-Type"] = "text/plain"
        out.write("hello!\n")
      end
    end
 end

 h = Mongrel::HttpServer.new("0.0.0.0", "3000")
 h.register("/test", SimpleHandler.new)
 h.register("/files", Mongrel::DirHandler.new("."))
 h.run.join

This will possibly narrow down the problem area.  If Mongrel itself is
to blame then you should still see lots-o-memory growth.  Or it is the
interface with Rails that is causing the problem.

Jim Powers

From eden at mojiti.com  Wed Mar  7 09:47:27 2007
From: eden at mojiti.com (Eden Li)
Date: Wed, 7 Mar 2007 22:47:27 +0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <1dd361e10703070647w69302ea7o8f0bbe69ed7c1785@mail.gmail.com>

Whoa... why don't you include the image in a POST body?

Technically there's no URL limit, but sending images using URL params sounds
like a candidate for one of the blogs that I read...

On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
>
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?
>
> Thanks. Joe.
>
> I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> something like...
>
> http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%
> 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%
> 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA
> kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd
> 4eXqDhIWGh4iJipKTlJWW......... [much more]
>
> When the URL is long, the action is not called in rails. But, if I
> remove the image from the URL, then the action is called.
> _______________________________________________
> 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/20070307/4211982e/attachment.html 

From pberry at gmail.com  Wed Mar  7 09:49:15 2007
From: pberry at gmail.com (Patrick Berry)
Date: Wed, 7 Mar 2007 06:49:15 -0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <ef13ff170703070649h5aff7917ga7bc056e1de7d448@mail.gmail.com>

Is it just me or is that an insane amount of data to send via GET?  Mongrel
is pretty strict about how clients use HTTP, so check your mongrel logs.

On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
>
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?
>
> Thanks. Joe.
>
> I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> something like...
>
> http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%
> 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%
> 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA
> kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd
> 4eXqDhIWGh4iJipKTlJWW......... [much more]
>
> When the URL is long, the action is not called in rails. But, if I
> remove the image from the URL, then the action is called.
> _______________________________________________
> 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/20070307/f5447d44/attachment.html 

From pberry at gmail.com  Wed Mar  7 10:01:22 2007
From: pberry at gmail.com (Patrick Berry)
Date: Wed, 7 Mar 2007 07:01:22 -0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <ef13ff170703070649h5aff7917ga7bc056e1de7d448@mail.gmail.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
	<ef13ff170703070649h5aff7917ga7bc056e1de7d448@mail.gmail.com>
Message-ID: <ef13ff170703070701l5e880f69j61e7abdd8ab3ee96@mail.gmail.com>

The HTTP protocol does not place any a priori limit on the length of
   a URI. Servers MUST be able to handle the URI of any resource they
   serve, and SHOULD be able to handle URIs of unbounded length if they
   provide GET-based forms that could generate such URIs. A server
   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
   than the server can handle (see section 10.4.15).

My bad...still...that's a lot of data.

On 3/7/07, Patrick Berry <pberry at gmail.com> wrote:
>
> Is it just me or is that an insane amount of data to send via GET?
> Mongrel is pretty strict about how clients use HTTP, so check your mongrel
> logs.
>
> On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
> >
> > My rails web app (rails 1.2.1) uploads an image from a Java applet by
> > encoding it into the URL. This works fine when I'm using Webrick. I'm
> > trying out Mongrel today, and I'm getting an error in Safari that
> > says "lost network connection" (NSURLErrorDomain:-1005). I get
> > something similar in Firefox. Is there a way to make Mongrel accept a
> > really long URL like this?
> >
> > Thanks. Joe.
> >
> > I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> > something like...
> >
> > http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%<http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%25>
> > 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> >
> > EBAQEBAQEBAQEBAQEBAQH%
> > 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> > EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> > 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> > 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA
> >
> > kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd
> > 4eXqDhIWGh4iJipKTlJWW......... [much more]
> >
> > When the URL is long, the action is not called in rails. But, if I
> > remove the image from the URL, then the action is called.
> > _______________________________________________
> > 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/20070307/b7cd1bed/attachment-0001.html 

From francois.beausoleil at gmail.com  Wed Mar  7 10:15:19 2007
From: francois.beausoleil at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Beausoleil?=)
Date: Wed, 7 Mar 2007 10:15:19 -0500
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <41d5fadf0703070715v20b7169bt592b4f7a511f213c@mail.gmail.com>

Hello Joe,

2007/3/7, Joe Lester <joe_lester at sweetwater.com>:
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?

Yes, Mongrel will kill the request because it thinks you're trying to
attack it.  Why can't you POST the data instead ?  This is what POST
was intended to do.

Bye !
-- 
Fran?ois Beausoleil
http://blog.teksol.info/
http://piston.rubyforge.org/

From rsanheim at gmail.com  Wed Mar  7 10:17:14 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 7 Mar 2007 09:17:14 -0600
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <fc113d400703070717n7b23c5b5k32f6dc233526f1b0@mail.gmail.com>

You realize that some browsers will complain about this, right?
Having very long URLs is generally a bad idea.

see also: http://www.boutell.com/newfaq/misc/urllength.html

- Rob

On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?
>
> Thanks. Joe.
>
> I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> something like...
>
> http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%
> 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%
> 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA
> kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd
> 4eXqDhIWGh4iJipKTlJWW......... [much more]
>
> When the URL is long, the action is not called in rails. But, if I
> remove the image from the URL, then the action is called.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From codeturkey at comcast.net  Wed Mar  7 10:15:37 2007
From: codeturkey at comcast.net (Steven Hansen)
Date: Wed, 07 Mar 2007 07:15:37 -0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <45EED719.6040301@comcast.net>

Joe Lester wrote:
> My rails web app (rails 1.2.1) uploads an image from a Java applet by  
> encoding it into the URL. 

Why not use the POST method to upload the image... it can handle a lot 
more data than GET. 

http://en.wikipedia.org/wiki/HTTP#Request_methods


-Steven

From zedshaw at zedshaw.com  Wed Mar  7 13:34:10 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 7 Mar 2007 10:34:10 -0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <20070307103410.6207043c.zedshaw@zedshaw.com>

On Wed, 7 Mar 2007 08:02:23 -0500
Joe Lester <joe_lester at sweetwater.com> wrote:

> My rails web app (rails 1.2.1) uploads an image from a Java applet by  
> encoding it into the URL. This works fine when I'm using Webrick. I'm  
> trying out Mongrel today, and I'm getting an error in Safari that  
> says ?lost network connection? (NSURLErrorDomain:-1005). I get  
> something similar in Firefox. Is there a way to make Mongrel accept a  
> really long URL like this?
> 
> Thanks. Joe.

Joe, Mongrel enforces limits on the data it accepts in order to prevent
various attacks.  As many other folks mentioned you should probably be
encoding that in a POST rather than GET request.  Just for your
reference, here's the limits that you'll hit:

FIELD_NAME = 256
FIELD_VALUE = 80 * 1024
REQUEST_URI = 1024 * 12
REQUEST_PATH = 1024
QUERY_STRING = 1024 * 10
HEADER = 1024 * (80 + 32)

FIELD_VALUE and HEADER limits are mostly to allow for the insane size
of Cookies.  You're probably hitting the QUERY_STRING limit of 10k or
the REQUEST_URI of 12k with your request.

Have a good one.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From zedshaw at zedshaw.com  Wed Mar  7 13:38:34 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 7 Mar 2007 10:38:34 -0800
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast (Zed A.
 Shaw)
In-Reply-To: <A0C817B9-06FA-4541-A699-7E3AE46E13AA@spacebabies.nl>
References: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
	<20070306192512.E547D5242072@rubyforge.org>
	<A0C817B9-06FA-4541-A699-7E3AE46E13AA@spacebabies.nl>
Message-ID: <20070307103834.29b70958.zedshaw@zedshaw.com>

On Tue, 6 Mar 2007 21:13:06 +0100
joost baaij <joost at spacebabies.nl> wrote:

> Hmm, reading that I am growing more suspicious. My ram-related woes  
> appeared when Rails 1.2 hit the stage. But I also saw a hefty  
> increase in traffic so was quick to blame it on that.

I haven't investigated it yet but you should probably test it out and
double check you've got fastthread in there.  If you run mongrel_rails
with -B you can get a log/mongrel_debug/objects.log file that will help
you track down the memory problems.

Let me know what you find.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From joe_lester at sweetwater.com  Wed Mar  7 10:40:51 2007
From: joe_lester at sweetwater.com (Joe Lester)
Date: Wed, 7 Mar 2007 10:40:51 -0500
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <ef13ff170703070701l5e880f69j61e7abdd8ab3ee96@mail.gmail.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>	<ef13ff170703070649h5aff7917ga7bc056e1de7d448@mail.gmail.com>
	<ef13ff170703070701l5e880f69j61e7abdd8ab3ee96@mail.gmail.com>
Message-ID: <66E8C0C6-DDA6-4DF6-9E34-FBFB0DBD104D@sweetwater.com>

Switching to POST. Thanks.

On Mar 7, 2007, at 10:01 AM, Patrick Berry wrote:

> The HTTP protocol does not place any a priori limit on the length of
>    a URI. Servers MUST be able to handle the URI of any resource they
>    serve, and SHOULD be able to handle URIs of unbounded length if  
> they
>
>    provide GET-based forms that could generate such URIs. A server
>    SHOULD return 414 (Request-URI Too Long) status if a URI is longer
>    than the server can handle (see section 10.4.15).
> My bad...still...that's a lot of data.
>
> On 3/7/07, Patrick Berry <pberry at gmail.com> wrote:
> Is it just me or is that an insane amount of data to send via GET?   
> Mongrel is pretty strict about how clients use HTTP, so check your  
> mongrel logs.
>
>
> On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?
>
> Thanks. Joe.
>
> I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> something like...
>
> http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%
> 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB 
> AQ
> EBAQEBAQEBAQEBAQEBAQH%
> 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB 
> AQ
> EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0 
> fA
> kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1d 
> nd
> 4eXqDhIWGh4iJipKTlJWW......... [much more]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/8e5119de/attachment.html 

From zedshaw at zedshaw.com  Wed Mar  7 13:45:01 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 7 Mar 2007 10:45:01 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
Message-ID: <20070307104501.85cee74d.zedshaw@zedshaw.com>

On Wed, 7 Mar 2007 04:14:57 -0700
"Kirk Haines" <wyhaines at gmail.com> wrote:

> On 3/6/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> > On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
>
> > This is exactly what Mongrel does when it cannot cope with the incoming
> > traffic. I've discovered the same effect today.
> 
> I think it's fair to make a distinction here.

And one more distinction:  You can use the -n parameter to set a max
allowed concurrent connections limit.  What Mongrel does is when it
hits that limit, it rejects the current connection, then goes through
the list of active threads and starts killing any that are older than
about 60 seconds.

So, if people think they're overloading Mongrel with too many threads,
they can easily test it by setting -n to say 30, thrashing it, and then
looking at either the screen output or mongrel.log (if you started as a
daemon).

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From hutch at recursive.ca  Wed Mar  7 10:48:46 2007
From: hutch at recursive.ca (Bob Hutchison)
Date: Wed, 7 Mar 2007 10:48:46 -0500
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <59AAD070-6BC1-470F-87D9-B4695650BCA7@recursive.ca>

Hi,

On 7-Mar-07, at 8:02 AM, Joe Lester wrote:

> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says ?lost network connection? (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?

Most servers will put a hard limit on the number of characters in a  
URL that they will accept. This is to avoid a kind of denial of  
service attack (imagine someone asking for a 10MB url repeatedly and  
frequently).

Something else to think about is that GET is not supposed to be  
changing the state of the resource on the server. If you are trying  
to upload a file to the server using a GET you're breaking that rule.  
If you put that URL into a webpage, some browsers will 'optimise'  
your experience by pre-fetching. Imagine a webapp that had a delete  
record action implemented as a simple href on a page and a pre-fetch  
occurred... (and of course this has happened many many times).

The solution to both problems is to use POST. BTW, Rails link_to and  
url helpers support an option (:post => true) that will make this  
quite easy to accomplish. You can also have a confirm dialog with  
a :confirm => "Are you sure?" kind of thing.

Cheers,
Bob

>
> Thanks. Joe.
>
> I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> something like...
>
> http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%
> 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB 
> AQ
> EBAQEBAQEBAQEBAQEBAQH%
> 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB 
> AQ
> EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0 
> fA
> kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1d 
> nd
> 4eXqDhIWGh4iJipKTlJWW......... [much more]
>
> When the URL is long, the action is not called in rails. But, if I
> remove the image from the URL, then the action is called.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

----
Bob Hutchison                  -- blogs at <http://www.recursive.ca/ 
hutch/>
Recursive Design Inc.          -- <http://www.recursive.ca/>
Raconteur                      -- <http://www.raconteur.info/>
xampl for Ruby                 -- <http://rubyforge.org/projects/xampl/>




From 2828628 at gmail.com  Wed Mar  7 10:55:50 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 23:55:50 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <20070307080359.64394ef6@nomadII.powershouse.bogus>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
Message-ID: <2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>

Following is the newest test case i took:

* create a fresh rails app
* then create a controller, a model and a view.
* the model is just a simple table containing id and name.
* use httperf to beat the url /book/show/1 by the following steps:
    1) httperf --server xxx --port 3000 --rate 50 --uri /book/show/1
--num-call 1 --num-conn 2000
    2) httperf --server xxx --port 3000 --rate 60 --uri /book/show/1
--num-call 1 --num-conn 2000
    3) httperf --server xxx --port 3000 --rate 70 --uri /book/show/1
--num-call 1 --num-conn 2000
    4) httperf --server xxx --port 3000 --rate 80 --uri /book/show/1
--num-call 1 --num-conn 2000

thereinto, 1), 2), 3) 4) were passed,  the memory usage of 1), 2), 3) were
normal 30~32M, however, 4) up to 60M and never recover again.
this is the report of 4):
--------------------------------------------------------
httperf --client=0/1 --server=192.168.1.131 --port=3000 --uri=/book/show/1
--rate=80 --send-buffer=4096 --recv-buffer=16384 --num-conns=2000
--num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 32.065 s

Connection rate: 62.4 conn/s (16.0 ms/conn, <=482 concurrent connections)
Connection time [ms]: min 24.0 avg 3091.5 max 12706.6 median 2240.5 stddev
2532.5
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 1.000

Request rate: 62.4 req/s (16.0 ms/req)
Request size [B]: 75.0

Reply rate [replies/s]: min 49.4 avg 61.2 max 73.6 stddev 8.9 (6 samples)
Reply time [ms]: response 3091.3 transfer 0.0
Reply size [B]: header 267.0 content 1522.0 footer 0.0 (total 1789.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 1.00 system 31.06 (user 3.1% system 96.9% total 100.0%)
Net I/O: 113.5 KB/s (0.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
------------------------------------------------------------------------------

i also repeated the 4) 2 times.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/d7977e1f/attachment-0001.html 

From 2828628 at gmail.com  Wed Mar  7 10:57:39 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 23:57:39 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
Message-ID: <2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>

used this cmd to run mongrel for the above test case:
mongrel_rails start -d -e production
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/9c5ae370/attachment.html 

From zedshaw at zedshaw.com  Wed Mar  7 14:02:07 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 7 Mar 2007 11:02:07 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
Message-ID: <20070307110207.310855f7.zedshaw@zedshaw.com>

On Wed, 7 Mar 2007 13:06:17 +0800
"Ken Wei" <2828628 at gmail.com> wrote:

> I created a new rails app named 'test' which containing only a controller
> and an action .
> Here is the controller:
> 
> class MyTestController < ApplicationController
> 
>         def index
>                 render_text 'Hello!'
>         end
> 
> end

Yes, *this* is the test case you use.
 
> I keeped the setup as the same as before. Then i ran a single mongrel server
> which listening on 3000 by default, and used httperf to hit the action:
> 
> httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test --num-call
> 1 --num-conn 10000

The --num-call parameter is useless, and a rate of 80 isn't good
either.  How did you come up with this rating?

Start with --num-conn 1000, and see what the estimated rate is, then
give it that rate.  After that, slowly move --rate up or down until you
find the point where you can't make it any faster without the speed
dropping.

And, go get http://peepcode.com/products/benchmarking-with-httperf so I
don't have to try to explain it over email.

> The memory usage of the mongrel server grows from 20M to 144M in 20 seconds,
> it's crazy!

Well, there's enough people complaining about memory leaks in *MONGREL*
when they run *RAILS* that I'll have to investigate it.

> And i tryed Lighttpd + FastCGI to test this case, it works well. Then i
> think about if i need to roll back to the fastcgi way? is the mongrel the
> future of the rails community?

FastCGI forces a garbage collection after a certain number of requests,
but if your app runs with FastCGI then you should use that.  Don't use
a solution that doesn't work.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From brad at bradediger.com  Wed Mar  7 10:20:31 2007
From: brad at bradediger.com (Brad Ediger)
Date: Wed, 7 Mar 2007 09:20:31 -0600
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <ef13ff170703070649h5aff7917ga7bc056e1de7d448@mail.gmail.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
	<ef13ff170703070649h5aff7917ga7bc056e1de7d448@mail.gmail.com>
Message-ID: <8A45E1CF-5526-453A-AF16-FA7F91001A7D@bradediger.com>

FYI, from RFC 2616 section 3.2.1: (http://www.w3.org/Protocols/ 
rfc2616/rfc2616-sec3.html)

The HTTP protocol does not place any a priori limit on the length of  
a URI. Servers MUST be able to handle the URI of any resource they  
serve, and SHOULD be able to handle URIs of unbounded length if they  
provide GET-based forms that could generate such URIs. A server  
SHOULD return 414 (Request-URI Too Long) status if a URI is longer  
than the server can handle (see section 10.4.15).

Note: Servers ought to be cautious about depending on URI lengths  
above 255 bytes, because some older client or proxy implementations  
might not properly support these lengths.


On Mar 7, 2007, at 8:49 AM, Patrick Berry wrote:

> Is it just me or is that an insane amount of data to send via GET?   
> Mongrel is pretty strict about how clients use HTTP, so check your  
> mongrel logs.
>
> On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?
>
> Thanks. Joe.
>
> I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> something like...
>
> http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%
> 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB 
> AQ
> EBAQEBAQEBAQEBAQEBAQH%
> 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB 
> AQ
> EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0 
> fA
> kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1d 
> nd
> 4eXqDhIWGh4iJipKTlJWW......... [much more]
>
> When the URL is long, the action is not called in rails. But, if I
> remove the image from the URL, then the action is called.
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/49a37c85/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/49a37c85/attachment.bin 

From wyhaines at gmail.com  Wed Mar  7 11:30:53 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 7 Mar 2007 09:30:53 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <20070307080359.64394ef6@nomadII.powershouse.bogus>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
Message-ID: <f4cd26df0703070830k333b908ckaa0908f9131df584@mail.gmail.com>

On 3/7/07, Jim Powers <rancor at mindspring.com> wrote:

> What file descriptor limit are you referring to?  A typical Linux
> <default> ulimit on file descriptors is 1024, which should be more than
> enough for the test Ken is performing.

It depends on how quickly it outruns the handler's ability to process
the requests.

Consider the last httperf command that he gave:

httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test
--num-call 1 --num-conn 10000

10000 connections is plenty enough to run out of file descriptors if
he's only managing to process, say, 70 requests per second.


Kirk Haines

From alexey.verkhovsky at gmail.com  Wed Mar  7 11:32:38 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 09:32:38 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
Message-ID: <3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>

Having RTFMed on the issue, Mongrel's max number of SOCKETS is 1024, due to
the use of select(). And in my case yesterday it was running out of file
descriptors way before it hit this limit.

As for threads and their associated context using up memory. This may well
be the case. Why does it stay at 150 Mb forever after the load is off,
however?

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/7a7411a0/attachment.html 

From alexey.verkhovsky at gmail.com  Wed Mar  7 11:35:06 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 09:35:06 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
Message-ID: <3945c4270703070835k65ff3615h40232b5918250105@mail.gmail.com>

On 3/7/07, Ken Wei <2828628 at gmail.com> wrote:
>
>     4) httperf --server xxx --port 3000 --rate 80 --uri /book/show/1
> --num-call 1 --num-conn 2000
>

2000 calls at a rate of 80/sec is not enough to it out completely and make
it run out of either file descriptors or sockets. Try 10000 calls, and
you'll reproduce the same effect as you reported yesterday.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/313b1ce9/attachment.html 

From wyhaines at gmail.com  Wed Mar  7 11:39:51 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 7 Mar 2007 09:39:51 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
Message-ID: <f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>

On 3/7/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> Having RTFMed on the issue, Mongrel's max number of SOCKETS is 1024, due to
> the use of select(). And in my case yesterday it was running out of file
> descriptors way before it hit this limit.
>
> As for threads and their associated context using up memory. This may well
> be the case. Why does it stay at 150 Mb forever after the load is off,
> however?

Analyzing details about where RAM is going is an exercise in patience.

A quick and hopefully stupid question here, though...are you using an
older version of Mongrel?  Or are you doing anything that creates an
array and then shifts values off of it?

shift() has a dumb assed (made moreso by the fact that, at least as of
1.8.5 it still exists) bug in it that will mess with your RAM usage
badly, especially if you have large things in your array.


Kirk Haines

From alexey.verkhovsky at gmail.com  Wed Mar  7 11:41:18 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 09:41:18 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <20070307104501.85cee74d.zedshaw@zedshaw.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307104501.85cee74d.zedshaw@zedshaw.com>
Message-ID: <3945c4270703070841r5ead7984s626a28b27bf2a9d3@mail.gmail.com>

Zed,

Do you know what causes overloaded Mongrel to go to 150 Mb VSS and stay
there, and why it is supposed to behave this way?
If not, would you like somebody to figure it out and/or try to fix it? I
could try to give it a shot.

Alex

On 3/7/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> And one more distinction:  You can use the -n parameter to set a max
> allowed concurrent connections limit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/ca553903/attachment.html 

From zedshaw at zedshaw.com  Wed Mar  7 14:49:11 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 7 Mar 2007 11:49:11 -0800
Subject: [Mongrel] Memory Leaks with Rails 1.2?
Message-ID: <20070307114911.558b687f.zedshaw@zedshaw.com>

I've been getting a bunch of reports about the latest Rails "leaking"
memory more than before.  Please fill out this survey:

1) Have you noticed an increase in memory usage with the latest Rails
1.2?

2) Have you changed anything else in your application?

   a) No, really, don't be a dumbass like the lusers you hate. Go look
at your svn logs and really figure out if you've changed anything else.

3) I ask again, did you change anything else since as well as Rails 1.2?

4) Does going back to a previous Rails (if you can) get rid of the
memory leak?

5) Have you tried taking a basic controller that renders :text =>
"test" only and run sequential hits against it?

   a) Does the ram increase?

   b) If not, have run this same test against a page that does?

   c) What's the difference between the leaking and non-leaking page?

6) Do you have this problem with FastCGI?

7) Do you have this problem if you add a GC.start call to the end of
your leaking requests, or as an after filter in a strategic location?

Thanks, please keep the response short so I can start looking for
patterns.

In my tests I'm not finding any leaks so I need more information.
Reproducible processes and sample code will really help a lot.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From 2828628 at gmail.com  Wed Mar  7 12:38:23 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Thu, 8 Mar 2007 01:38:23 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <f4cd26df0703070830k333b908ckaa0908f9131df584@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<f4cd26df0703070830k333b908ckaa0908f9131df584@mail.gmail.com>
Message-ID: <2a0834610703070938s62f5ea74gb876e799880e38b1@mail.gmail.com>

but, but, it did NOT run out of file descriptions, it works well except
memory leaks, up to 60M and never recover again.

the following is the all output from httperf, pls take a look seriously
first:

-----------------------------------------------------------
httperf --client=0/1 --server=192.168.1.131 --port=3000 --uri=/book/show/1
--rate=80 --send-buffer=4096 --recv-buffer=16384 --num-conns=2000
--num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 32.065 s

Connection rate: 62.4 conn/s (16.0 ms/conn, <=482 concurrent connections)
Connection time [ms]: min 24.0 avg 3091.5 max 12706.6 median 2240.5 stddev
2532.5
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 1.000

Request rate: 62.4 req/s (16.0 ms/req)
Request size [B]: 75.0

Reply rate [replies/s]: min 49.4 avg 61.2 max 73.6 stddev 8.9 (6 samples)
Reply time [ms]: response 3091.3 transfer 0.0
Reply size [B]: header 267.0 content 1522.0 footer 0.0 (total 1789.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 1.00 system 31.06 (user 3.1% system 96.9% total 100.0%)
Net I/O: 113.5 KB/s (0.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
------------------------------------------------------------------------------

The output looks good, everything passed and there is no error at all. And
there is no error/exception in production.log, e.g. 'Too many open
files...'.

So, everything works well/fast except LEAKS, again i never pointed to
mongrel at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/e0b7f8fc/attachment.html 

From kris at alternativefocusmedia.com  Wed Mar  7 12:28:31 2007
From: kris at alternativefocusmedia.com (Kris Leech)
Date: Wed, 07 Mar 2007 17:28:31 +0000
Subject: [Mongrel] Two Mongrel's Two Rails Applications
Message-ID: <45EEF63F.8050109@alternativefocusmedia.com>

Hi, I have Mongrel up and running for one application (port 3000), but 
when I start another Mongrel for a second application (port 4000) I can 
access both sites locally (using curl) but not remotly via a browser.

If I stop the first applications Mongrel and start the second the second 
one works. In other words I can only run one application at once...

I have both on different ports, it makes no difference if I run the apps 
in development or production mode or change the port numbers.

Any suggestions would be great!

Rails 1.2.1
Ruby 1.8.5
Mongrel 1.0.1

From 2828628 at gmail.com  Wed Mar  7 12:43:14 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Thu, 8 Mar 2007 01:43:14 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
Message-ID: <2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>

this is the only controller in the above test case:

class BookController < ApplicationController
  scaffold :book
  def list
    logger.debug 'List the books'
    @books=Book.find_all
  end
  def edit
    @book=Book.find(@params['id'])
    @categories=Category.find_all
  end
end

mongrel is 1.0.1, rails is 1.2.2, ruby is 1.8.5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/e9e16e51/attachment.html 

From alexey.verkhovsky at gmail.com  Wed Mar  7 13:41:56 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 11:41:56 -0700
Subject: [Mongrel] Memory Leaks with Rails 1.2?
In-Reply-To: <20070307114911.558b687f.zedshaw@zedshaw.com>
References: <20070307114911.558b687f.zedshaw@zedshaw.com>
Message-ID: <3945c4270703071041vd4ad52fjb7f2ec4317cfeb34@mail.gmail.com>

I'm researching Rails deployment, anyway, so I'll do some poking around.

Alex

On 3/7/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> I've been getting a bunch of reports about the latest Rails "leaking"
> memory more than before.  Please fill out this survey:
>
> 1) Have you noticed an increase in memory usage with the latest Rails
> 1.2?
>
> 2) Have you changed anything else in your application?
>
>    a) No, really, don't be a dumbass like the lusers you hate. Go look
> at your svn logs and really figure out if you've changed anything else.
>
> 3) I ask again, did you change anything else since as well as Rails 1.2?
>
> 4) Does going back to a previous Rails (if you can) get rid of the
> memory leak?
>
> 5) Have you tried taking a basic controller that renders :text =>
> "test" only and run sequential hits against it?
>
>    a) Does the ram increase?
>
>    b) If not, have run this same test against a page that does?
>
>    c) What's the difference between the leaking and non-leaking page?
>
> 6) Do you have this problem with FastCGI?
>
> 7) Do you have this problem if you add a GC.start call to the end of
> your leaking requests, or as an after filter in a strategic location?
>
> Thanks, please keep the response short so I can start looking for
> patterns.
>
> In my tests I'm not finding any leaks so I need more information.
> Reproducible processes and sample code will really help a lot.
>
> --
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> http://mongrel.rubyforge.org/
> _______________________________________________
> 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/20070307/dff20a3a/attachment.html 

From alexey.verkhovsky at gmail.com  Wed Mar  7 13:48:55 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 11:48:55 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703070938s62f5ea74gb876e799880e38b1@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<f4cd26df0703070830k333b908ckaa0908f9131df584@mail.gmail.com>
	<2a0834610703070938s62f5ea74gb876e799880e38b1@mail.gmail.com>
Message-ID: <3945c4270703071048m7643f81bv8d56cfd84f12282c@mail.gmail.com>

It did not run out of file descriptors because you didn't give it enough
time to run out of them. It was, however, going to run out of something in
the next minute or so.

The evidence is in the fact that reported throughput (62.4 requests/sec) was
lower than the load you gave it (80 requests/sec).

Alex

On 3/7/07, Ken Wei <2828628 at gmail.com> wrote:
>
> but, but, it did NOT run out of file descriptions, it works well except
> memory leaks, up to 60M and never recover again.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/da724d3b/attachment.html 

From 2828628 at gmail.com  Wed Mar  7 13:56:02 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Thu, 8 Mar 2007 02:56:02 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703071048m7643f81bv8d56cfd84f12282c@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<f4cd26df0703070830k333b908ckaa0908f9131df584@mail.gmail.com>
	<2a0834610703070938s62f5ea74gb876e799880e38b1@mail.gmail.com>
	<3945c4270703071048m7643f81bv8d56cfd84f12282c@mail.gmail.com>
Message-ID: <2a0834610703071056j77e1863ap56182c861c4b8fcb@mail.gmail.com>

but, how come the memory usage still stay there (60M) while everything goes
well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/fc8a2ad5/attachment-0001.html 

From carl.lerche at gmail.com  Wed Mar  7 15:09:34 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Wed, 7 Mar 2007 12:09:34 -0800
Subject: [Mongrel] Memory Leaks with Rails 1.2?
In-Reply-To: <20070307114911.558b687f.zedshaw@zedshaw.com>
References: <20070307114911.558b687f.zedshaw@zedshaw.com>
Message-ID: <ab90312e0703071209h254504b3t695940ecfd13c56@mail.gmail.com>

When I switched to rails 1.2 I noticed a large decrease in memory
usage. However, this is probably because I

1) switched from mysql to postgresql and
2) stopped using acts_as_ferret.

Currently, my 3 mongrel processes are running strong. They've
currently been up for 3 days and the memory is at 67MB, 65MB, and
59MB.

-carl

From jackc at hylesanderson.edu  Wed Mar  7 15:36:52 2007
From: jackc at hylesanderson.edu (Jack Christensen)
Date: Wed, 07 Mar 2007 14:36:52 -0600
Subject: [Mongrel] Memory Leaks with Rails 1.2?
In-Reply-To: <20070307114911.558b687f.zedshaw@zedshaw.com>
References: <20070307114911.558b687f.zedshaw@zedshaw.com>
Message-ID: <45EF2264.1050503@hylesanderson.edu>

Zed A. Shaw wrote:
> I've been getting a bunch of reports about the latest Rails "leaking"
> memory more than before.  Please fill out this survey:
>
> 1) Have you noticed an increase in memory usage with the latest Rails
> 1.2?
>
> 2) Have you changed anything else in your application?
>
>    a) No, really, don't be a dumbass like the lusers you hate. Go look
> at your svn logs and really figure out if you've changed anything else.
>
> 3) I ask again, did you change anything else since as well as Rails 1.2?
>
> 4) Does going back to a previous Rails (if you can) get rid of the
> memory leak?
>
> 5) Have you tried taking a basic controller that renders :text =>
> "test" only and run sequential hits against it?
>
>    a) Does the ram increase?
>
>    b) If not, have run this same test against a page that does?
>
>    c) What's the difference between the leaking and non-leaking page?
>
> 6) Do you have this problem with FastCGI?
>
> 7) Do you have this problem if you add a GC.start call to the end of
> your leaking requests, or as an after filter in a strategic location?
>
> Thanks, please keep the response short so I can start looking for
> patterns.
>
> In my tests I'm not finding any leaks so I need more information.
> Reproducible processes and sample code will really help a lot.
>
>   
No apparent leaks here. I even hammered it with httperf just to 
double-check. I'm running Rails 1.2.1 and Mongrel 1.0.1. My processes 
grow to about 60-70 MB then stabilize. The processes do randomly die on 
occasion, but monit to restarts them when necessary.

-- 
Jack Christensen
jackc at hylesanderson.edu


From joost at spacebabies.nl  Wed Mar  7 17:09:45 2007
From: joost at spacebabies.nl (joost baaij)
Date: Wed, 7 Mar 2007 23:09:45 +0100
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast (Zed A.
	Shaw)
In-Reply-To: <20070307103834.29b70958.zedshaw@zedshaw.com>
References: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
	<20070306192512.E547D5242072@rubyforge.org>
	<A0C817B9-06FA-4541-A699-7E3AE46E13AA@spacebabies.nl>
	<20070307103834.29b70958.zedshaw@zedshaw.com>
Message-ID: <35C78D72-D027-4DA5-AAF9-BFF10B21F6E6@spacebabies.nl>

Allrighty, mongrel -B is running and producing the log.
Do you have any pointers on how to interpret the log?

on fastthread:
joost at ded022/home/websites/gomagazine$ gem list fastthread

*** LOCAL GEMS ***

fastthread (0.6.4.1)
     Optimized replacement for thread.rb primitives




Op 7-mrt-2007, om 19:38 heeft Zed A. Shaw het volgende geschreven:

> On Tue, 6 Mar 2007 21:13:06 +0100
> joost baaij <joost at spacebabies.nl> wrote:
>
>> Hmm, reading that I am growing more suspicious. My ram-related woes
>> appeared when Rails 1.2 hit the stage. But I also saw a hefty
>> increase in traffic so was quick to blame it on that.
>
> I haven't investigated it yet but you should probably test it out and
> double check you've got fastthread in there.  If you run mongrel_rails
> with -B you can get a log/mongrel_debug/objects.log file that will  
> help
> you track down the memory problems.
>
> Let me know what you find.
>
> -- 
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> http://mongrel.rubyforge.org/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- 
www.gomagazine.nl +31643904460 pobox 51059 nl-1007eb amsterdam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/730265ec/attachment.bin 

From joost at spacebabies.nl  Wed Mar  7 18:40:26 2007
From: joost at spacebabies.nl (joost baaij)
Date: Thu, 8 Mar 2007 00:40:26 +0100
Subject: [Mongrel] Memory Leaks with Rails 1.2?
In-Reply-To: <20070307114911.558b687f.zedshaw@zedshaw.com>
References: <20070307114911.558b687f.zedshaw@zedshaw.com>
Message-ID: <6DF5210B-5A27-4FC3-9928-BD6BF7367556@spacebabies.nl>

I've got a completely reproducable case, but it has nothing to do  
with Mongrel.

When I use the file_column plugin [1] and resize images with rmagick,  
every Mongrel/fcgi process grows in size until it reaches it's limit  
(my fcgi processes are limited to 100 MB). Once there, they will  
block/sleep/whatever and get swapped out by the OS. Eventually swap  
is exhausted and carnage ensues.

Without RMagick this does not happen at all, processes are 34-40 MB  
and that's including acts_as_ferret. This behaviour has definitely  
become more apparent since 1.2 though. And to make life more  
interesting I've changed all parameters outside the application: new  
mysql, new ruby, new webserver, a bunch of plugins and moving towards  
resources-based routing. So can't help you (or myself) there.

[1] http://www.kanthak.net/opensource/file_column/
i know, it's ancient.


Op 7-mrt-2007, om 20:49 heeft Zed A. Shaw het volgende geschreven:

> I've been getting a bunch of reports about the latest Rails "leaking"
> memory more than before.  Please fill out this survey:
>
> 1) Have you noticed an increase in memory usage with the latest Rails
> 1.2?
>
> 2) Have you changed anything else in your application?
>
>    a) No, really, don't be a dumbass like the lusers you hate. Go look
> at your svn logs and really figure out if you've changed anything  
> else.
>
> 3) I ask again, did you change anything else since as well as Rails  
> 1.2?
>
> 4) Does going back to a previous Rails (if you can) get rid of the
> memory leak?
>
> 5) Have you tried taking a basic controller that renders :text =>
> "test" only and run sequential hits against it?
>
>    a) Does the ram increase?
>
>    b) If not, have run this same test against a page that does?
>
>    c) What's the difference between the leaking and non-leaking page?
>
> 6) Do you have this problem with FastCGI?
>
> 7) Do you have this problem if you add a GC.start call to the end of
> your leaking requests, or as an after filter in a strategic location?
>
> Thanks, please keep the response short so I can start looking for
> patterns.
>
> In my tests I'm not finding any leaks so I need more information.
> Reproducible processes and sample code will really help a lot.
>
> -- 
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> http://mongrel.rubyforge.org/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- 
www.gomagazine.nl +31643904460 pobox 51059 nl-1007eb amsterdam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/97b447e7/attachment.bin 

From pete at nextengine.com  Wed Mar  7 19:35:15 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 7 Mar 2007 16:35:15 -0800
Subject: [Mongrel] Lighttpd + Mongrel Upload Progress Problem
Message-ID: <16B1A38B-65D3-4033-95E3-44D904197D7F@nextengine.com>

Hi guys,

I had mongrel_upload_progress working very sweetly on my dev machine,  
where mongrel was acting directly as the webserver.  But when I went  
to production it stopped working.

The Problem: On our production server we use Lighttpd, and it looks  
like lighty is buffering the whole upload and then giving it to  
Mongrel in a big chunk.  This pretty much screws up the whole point  
of using mongrel_upload_progress.

Has anyone found a workaround for this, or a way to get Lighttpd to  
stream the file to mongrel (or let mongrel handle it entirely)?   
Showing progress is important to my application.

Any help would be much appreciated.

Thanks,
Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/9a2c8d7f/attachment.html 

From alexey.verkhovsky at gmail.com  Wed Mar  7 19:38:19 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 17:38:19 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
Message-ID: <3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>

OK, I probably know what is happening. So...

1. Mongrel with a Hello, World application has virtual segment size (VSS) of
~32 Mb. As long as it is not overloaded, it stays at that level.
2. Once you overload it, Mongrel starts spawning new threads, up to the
default limit of 1024, or {max # of file descriptors per process - 2},
whichever is smaller.
3. Creating a new thread takes quite a bit of RAM (I guess, most of it is
simply allocated to the stack). 1024 new threads take over 60 Mb.
4. Killing the thread does not cause Ruby interpreter to release the memory
back to OS.

So, in a nutshell, in overload situation you end up with all 1024 threads
parked at the Rails mutex.

Solution is to set --num-procs much lower than 1024. Say, to 64. Or even to
10.
In my tests, Hello'world application did not exceed 48 Mb even with
--num-procs=256. Due to the Rails mutex, having more threads doesn't really
help in the situation where all of your static content, uploads and
downloads are served by an upstream web server.

A more "industrial" solution would be to redesign Mongrel's internal
architecture a bit. Requests routed to Rails can be placed in a queue, and
the thread released, instead of being parked at the mutex. It would help
people hosting their apps in those 64 Mb slices to work without an upstream
web server, but it would also add complexity to the code. One of those
tradeoffs.

I also think that --num-procs=1024 is not the best possible default. For the
benefit of all the people running Rails in cheap VPSes, it should be set to
a level not exceeding the limits of a 64 Mb slice.

I have a pretty lengthy record of configuration under test and what I did to
figure all this out. If anyone is interested in reading it, let me know.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/2df78ff9/attachment-0001.html 

From wayneeseguin at gmail.com  Wed Mar  7 20:53:34 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Wed, 7 Mar 2007 20:53:34 -0500
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
Message-ID: <DE375389-7636-4DEF-83CB-35CD391BDD70@gmail.com>

Alex,

I am quite interested in reading it.

Thanks,
   ~Wayne

On Mar 07, 2007, at 19:38 , Alexey Verkhovsky wrote:
> I have a pretty lengthy record of configuration under test and what  
> I did to figure all this out. If anyone is interested in reading  
> it, let me know.
>
> Alex


From kylekochis at gmail.com  Wed Mar  7 21:17:26 2007
From: kylekochis at gmail.com (Kyle Kochis)
Date: Wed, 7 Mar 2007 19:17:26 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
Message-ID: <6a7034b0703071817qd2d90a5o32ca8c42f0b07846@mail.gmail.com>

Ah. Thank you Alex, this is very handy information for me as I am in
charge of quite a few small VPS's. I have not had mem leaking issues
yet but this could could come in really handy for a much larger scale
rails project I am working on.
Kyle Kochis

On 3/7/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> OK, I probably know what is happening. So...
>
> 1. Mongrel with a Hello, World application has virtual segment size (VSS) of
> ~32 Mb. As long as it is not overloaded, it stays at that level.
> 2. Once you overload it, Mongrel starts spawning new threads, up to the
> default limit of 1024, or {max # of file descriptors per process - 2},
> whichever is smaller.
> 3. Creating a new thread takes quite a bit of RAM (I guess, most of it is
> simply allocated to the stack). 1024 new threads take over 60 Mb.
> 4. Killing the thread does not cause Ruby interpreter to release the memory
> back to OS.
>
> So, in a nutshell, in overload situation you end up with all 1024 threads
> parked at the Rails mutex.
>
> Solution is to set --num-procs much lower than 1024. Say, to 64. Or even to
> 10.
> In my tests, Hello'world application did not exceed 48 Mb even with
> --num-procs=256. Due to the Rails mutex, having more threads doesn't really
> help in the situation where all of your static content, uploads and
> downloads are served by an upstream web server.
>
> A more "industrial" solution would be to redesign Mongrel's internal
> architecture a bit. Requests routed to Rails can be placed in a queue, and
> the thread released, instead of being parked at the mutex. It would help
> people hosting their apps in those 64 Mb slices to work without an upstream
> web server, but it would also add complexity to the code. One of those
> tradeoffs.
>
> I also think that --num-procs=1024 is not the best possible default. For the
> benefit of all the people running Rails in cheap VPSes, it should be set to
> a level not exceeding the limits of a 64 Mb slice.
>
> I have a pretty lengthy record of configuration under test and what I did to
> figure all this out. If anyone is interested in reading it, let me know.
>
> Alex
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From rsanheim at gmail.com  Wed Mar  7 21:49:59 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 7 Mar 2007 20:49:59 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
Message-ID: <fc113d400703071849v378adadei6f499f943892936a@mail.gmail.com>

On 3/7/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> OK, I probably know what is happening. So...
>
> 1. Mongrel with a Hello, World application has virtual segment size (VSS) of
> ~32 Mb. As long as it is not overloaded, it stays at that level.
> 2. Once you overload it, Mongrel starts spawning new threads, up to the
> default limit of 1024, or {max # of file descriptors per process - 2},
> whichever is smaller.
> 3. Creating a new thread takes quite a bit of RAM (I guess, most of it is
> simply allocated to the stack). 1024 new threads take over 60 Mb.
> 4. Killing the thread does not cause Ruby interpreter to release the memory
> back to OS.
>
> So, in a nutshell, in overload situation you end up with all 1024 threads
> parked at the Rails mutex.
>
> Solution is to set --num-procs much lower than 1024. Say, to 64. Or even to
> 10.
> In my tests, Hello'world application did not exceed 48 Mb even with
> --num-procs=256. Due to the Rails mutex, having more threads doesn't really
> help in the situation where all of your static content, uploads and
> downloads are served by an upstream web server.
>
> A more "industrial" solution would be to redesign Mongrel's internal
> architecture a bit. Requests routed to Rails can be placed in a queue, and
> the thread released, instead of being parked at the mutex. It would help
> people hosting their apps in those 64 Mb slices to work without an upstream
> web server, but it would also add complexity to the code. One of those
> tradeoffs.
>
> I also think that --num-procs=1024 is not the best possible default. For the
> benefit of all the people running Rails in cheap VPSes, it should be set to
> a level not exceeding the limits of a 64 Mb slice.
>
> I have a pretty lengthy record of configuration under test and what I did to
> figure all this out. If anyone is interested in reading it, let me know.
>
> Alex

All of this sounds good, but I would say that the defaults should
target something more like a 128 - 256 meg slice.  No one who is sane
is trying to really run a Rails app on a 64 meg VPS - - thats just
asking for a lot of pain.

- Rob

From zedshaw at zedshaw.com  Thu Mar  8 01:26:26 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 7 Mar 2007 22:26:26 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
Message-ID: <20070307222626.ba3f9abe.zedshaw@zedshaw.com>

On Wed, 7 Mar 2007 17:38:19 -0700
"Alexey Verkhovsky" <alexey.verkhovsky at gmail.com> wrote:

> A more "industrial" solution would be to redesign Mongrel's internal
> architecture a bit. Requests routed to Rails can be placed in a queue, and
> the thread released, instead of being parked at the mutex. It would help
> people hosting their apps in those 64 Mb slices to work without an upstream
> web server, but it would also add complexity to the code. One of those
> tradeoffs.

They are kept in a queue, a couple actually, and they are killed off
when Mongrel can, which is usually when it gets a chance.  If you're
thrashing it then it doesn't have much of a chance.

I'd say first off the solution is:  just quit doing that.  If you're
maxing out your Mongrel servers then you're seriously screwed anyway
and there's nothing but -n to help you.  No amount of additional
queuing will help.  You have to be smarter about it, especially if
you've got a setup that's only 64MB of ram and somehow you're getting
so many requests you can't keep up.  Time to stop being cheap and fork
over the extra money for a bigger slice (which is good because it means
you're popular).

I went through this many times over back in the deep dark days before
fastthread, and no matter what you do if you're piling requests behind
some kind of list--whether that's a mutex or something else--you build
up RAM.  It's as simple as you make threads, threads take ram, threads
don't go away fast enough.

Ultimately though, everyone will just keep cycling over the same old
problems looking for how they can solve it within Mongrel when really
the solution has to come from ruby-core.  Until Ruby's IO, GC, and
threads improve drastically you'll keep hitting these problems.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From carl.lerche at gmail.com  Wed Mar  7 23:49:07 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Wed, 7 Mar 2007 20:49:07 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
	<466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>
Message-ID: <ab90312e0703072049v106f7c5fnd5d577d0d1eb5ca7@mail.gmail.com>

I'm going to go ahead and blame acts_as_ferret. I had an application
that used acts_as_ferret and each mongrel process reached up to 300MB.
I removed acts_as_ferret (as well as switched from mysql to
postgresql) and now the exact same application is staying steady at 70
MB a process. I also use a lot of RMagick in that same application
(didn't have time to remove it) but the processes still stay at 70MB.

Hope this helps.

On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
> Here are the plugins that were on the application when I just tried
> loading a single controller, which ended up hitting an 80MB limit
> after about 8 hours on all 4 mongrels running rails 1.2.2. They all
> restarted within minutes of each other, which was interesting.
>
> acts_as_ferret
> arts
> authorization
> custom-err-msg
> exception_notification
> flex_image
> has_many_polymorphs
> http_url_validation
> paginating_find
> rails_rcov
> resource_feeder (added after test)
> restful_authentication
> routing_navigator
> simply_helpful
> sql_session_store
> timed_fragment_cache
>
> The application I have in development that restarts every few days has
> the following plugins.
> acts_as_authenticated
> acts_as_rateable
> arts
> assert_select
> authorization
> browser_filters
> custom-err-msg
> debug_view_helper
> exception_notification
> flex_image
> paginating_find
> rails_rcov
> responsible_markup
> simple_http_auth
> timed_fragment_cache
> white_list
>
> I ran the tests with and without GC.start in the controller.
> GC.start kicked off in the production application when I do a send_data call.
>
>
>
>
> On 3/6/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> > Did you try adding GC.start in your application?
> >
> > On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
> > > I've got issues with my rails application leaking memory as well. I
> > > can say it's not Mongrel's fault, as I was able to duplicate the
> > > situation in Webbrick.
> > >
> > > My problem happens because I'm using monit to make sure my site stays
> > > up, but in doing so, monit hits each of my mongrels every minute. I
> > > thought the memory issues had to do with images, send_data or
> > > something else, and what I found, is that on a site that does nothing
> > > but respond to this monit controller, the memory grew and grew.
> > >
> > > I'm guessing it has to do with the plugins I'm using, as when I tried
> > > the same thing on a fresh rails application, the memory grew, but
> > > capped off at about 35MB, where the full application loading all
> > > plugins continued to grow until I killed it, never recovering memory.
> > >
> > > So, for now, monit is the cause and solution to my memory problems. I
> > > was thinking about trying to create a handler for mongrel that monit
> > > can hit to verify that it's running, but then there's the possibility
> > > that mongrel is up, but my application is down.
> > >
> > > My other issue with using monit are the constant hits to the log
> > > files, which logger.silence doesn't help (at least the methods I've
> > > tried) If someone knows how to silence a controller completely, I'd
> > > love to know.
> > >
> > > Right now I'm a bit busy, but I think it would be a good test to add
> > > my plugins one at a time to a fresh application and check the memory
> > > usage after hitting it with a few thousand hits from apache bench.
> > >
> > >
> > > On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> > > > 'gem cleanup' i did that, but still
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> >
> >
> > --
> > EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> > _______________________________________________
> > 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
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From alexey.verkhovsky at gmail.com  Thu Mar  8 01:35:36 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 23:35:36 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <20070307222626.ba3f9abe.zedshaw@zedshaw.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
	<20070307222626.ba3f9abe.zedshaw@zedshaw.com>
Message-ID: <3945c4270703072235u354359c3t700d5515a09ce0d8@mail.gmail.com>

Some further findings:

"Hello World" Rails application on my rather humble rig (Dell D620 laptop
running Ubuntu 6.10, Ruby 1.8.4 and Rails 1.2.2)  can handle over 500 hits
per second on the following action:

def say_hi
  render :text => 'Hi!'
end

It also doesn't leak any memory at all *when it is not overloaded*. E.g.,
under maximum non-concurent load (single-threaded test client that fires the
next request immediately upon receiving a response to the previous one), it
stays up forever.

When Mongrel + "Hello, World" is overloaded, there is a memory leak to the
tune of 6 Mb per hour. I have yet to figure out where is it coming from.

On 3/7/07 Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> I'd say first off the solution is:  just quit doing that.

This is something I can wholeheartedly agree with :)

maxing out your Mongrel servers then you're seriously screwed anyway
> and there's nothing but -n to help you.


After a couple of hours quietly pumping iron in a gym, I came to the same
conclusion. Let me explain myself, however.

The situation that I am concerned about is 20 to 50 apps clustered on the
same set of boxes, written by one group of people and supervised by another.
Think "large corporate IT", or a shared hosting a la TextDrive.  I want to
maximize throughput under heavy load, but a more important problem is to
reduce the ability of one app screwing up other apps on the same box(es).


> It's as simple as you make threads, threads take ram, threads
> don't go away fast enough.


What I was thinking is that by uncoupling the request from its thread, you
can probably max out all capabilities (CPU, I/O, Rails) of a 4 cores
commodity box with only 15-30 threads. 10-20 request handlers (that will
either serve static stuff or carry the request to the Rails queue), one
rails handler that loops over requests queue, takes requests to Rails and
drops responses off in the response queue, 5-10 response handlers (whose job
is simply to copy Rails response from responses queue to originating
sockets).

Right now, as far as I understand the code, request is carried all the way
through by the same thread.

On second thoughts, this is asynchronous communications between threads
within the process. Far too much design and maintenance overhead for the
marginal benefits it may (or may not) bring. Basically, just me being stupid
by trying to be too smart. :)


> Until Ruby's IO, GC, and threads improve drastically you'll keep hitting
> these problems.


Yes. Meantime, the recipe apparently is "serve static stuff through an
upstream web server, and use smaller values of --num--procs". Mongrel that
only receives dynamic requests is, essentialy, a single-threaded process,
anyway. The only reason to have more than one (1) thread is so that other
requests can queue up while it's doing something that takes time. Cool.

By the way, is Ruby 1.9 solving all of these issues?

> No one who is sane is trying to really run a Rails app on a 64 meg VPS - -
thats just asking for a lot of pain.
Well, entry-level slices on most Rails VPS services are 64 Mb.
My poking around so far seems to say "it's doable, but you need to tune it".

Best regards,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/089f4f06/attachment-0001.html 

From alexey.verkhovsky at gmail.com  Thu Mar  8 01:51:55 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 23:51:55 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703072235u354359c3t700d5515a09ce0d8@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
	<20070307222626.ba3f9abe.zedshaw@zedshaw.com>
	<3945c4270703072235u354359c3t700d5515a09ce0d8@mail.gmail.com>
Message-ID: <3945c4270703072251q73985a69s99f2da7bd272f93b@mail.gmail.com>

On 3/7/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
>
> It also doesn't leak any memory at all *when it is not overloaded*. E.g.,
> under maximum non-concurent load (single-threaded test client that fires the
> next request immediately upon receiving a response to the previous one), it
> stays up forever.


Correction: it stays up forever, at the same VSS / RSS values as when it
just started.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/a5bd0c02/attachment.html 

From jarkko at jlaine.net  Thu Mar  8 02:18:13 2007
From: jarkko at jlaine.net (Jarkko Laine)
Date: Thu, 8 Mar 2007 09:18:13 +0200
Subject: [Mongrel] Memory Leaks with Rails 1.2?
In-Reply-To: <6DF5210B-5A27-4FC3-9928-BD6BF7367556@spacebabies.nl>
References: <20070307114911.558b687f.zedshaw@zedshaw.com>
	<6DF5210B-5A27-4FC3-9928-BD6BF7367556@spacebabies.nl>
Message-ID: <A3AC7908-2A77-4B39-8723-72E696C7FCE9@jlaine.net>

On 8.3.2007, at 1.40, joost baaij wrote:

> I've got a completely reproducable case, but it has nothing to do  
> with Mongrel.
>
> When I use the file_column plugin [1] and resize images with  
> rmagick, every Mongrel/fcgi process grows in size until it reaches  
> it's limit (my fcgi processes are limited to 100 MB). Once there,  
> they will block/sleep/whatever and get swapped out by the OS.  
> Eventually swap is exhausted and carnage ensues.
>
> Without RMagick this does not happen at all, processes are 34-40 MB  
> and that's including acts_as_ferret. This behaviour has definitely  
> become more apparent since 1.2 though. And to make life more  
> interesting I've changed all parameters outside the application:  
> new mysql, new ruby, new webserver, a bunch of plugins and moving  
> towards resources-based routing. So can't help you (or myself) there.
>

It's a known fact that RMagick can leak like a sieve in Rails  
(explanation here [1]). You might want to try out minimagick [2] or  
imagescience [3] instead if you can.

[1] http://codehappy.wordpress.com/2007/01/17/tracking-a-memory-leak- 
in-rails/
[2] http://rubyforge.org/projects/mini-magick/
[3] http://seattlerb.rubyforge.org/ImageScience.html

--
Jarkko Laine
http://jlaine.net
http://dotherightthing.com
http://www.railsecommerce.com
http://odesign.fi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/36f003a7/attachment.bin 

From kraemer at webit.de  Thu Mar  8 03:53:43 2007
From: kraemer at webit.de (Jens Kraemer)
Date: Thu, 8 Mar 2007 09:53:43 +0100
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <ab90312e0703072049v106f7c5fnd5d577d0d1eb5ca7@mail.gmail.com>
References: <2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
	<466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>
	<ab90312e0703072049v106f7c5fnd5d577d0d1eb5ca7@mail.gmail.com>
Message-ID: <20070308085343.GO28036@cordoba.webit.de>

Hi!

On Wed, Mar 07, 2007 at 08:49:07PM -0800, Carl Lerche wrote:
> I'm going to go ahead and blame acts_as_ferret. I had an application
> that used acts_as_ferret and each mongrel process reached up to 300MB.

Well, as long as it stays at 300 MB after that there doesn't seem to be
a leak :-)

It's right that aaf may take up some RAM, because it holds index
instances open across requests. When using these, data structures that
can be reused between searches are kept in RAM by Ferret (that process
is called 'warming up' the index) and so there really might be some
initial growth in RAM usage of your mongrel processes. How large this 
can get depends on the size of your index, of course.

Just making use of RAM to speed things up is not that bad, imho. Of
course I could open/close the index on each request, but that would be
like doing plain old CGI...

> I removed acts_as_ferret (as well as switched from mysql to
> postgresql) and now the exact same application is staying steady at 70
> MB a process. I also use a lot of RMagick in that same application
> (didn't have time to remove it) but the processes still stay at 70MB.

I have a live app here running on Rails 1.2.1/MySQL with three mongrels 
for weeks without a hickup, each taking up max. 60MB of RAM. And yes, it 
uses acts_as_ferret :-)

Jens

 

-- 
Jens Kr?mer
webit! Gesellschaft f?r neue Medien mbH
Schnorrstra?e 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
kraemer at webit.de | www.webit.de
 
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa

From piet.hadermann at seagha.com  Thu Mar  8 04:24:40 2007
From: piet.hadermann at seagha.com (Piet Hadermann)
Date: Thu, 8 Mar 2007 10:24:40 +0100
Subject: [Mongrel] Memory leaks in my site
Message-ID: <67B95D61E544254F98FE975AA08F2FB2D86600@srv-mail.win.antwerp.seagha.com>

 
Quick fix could be to use HAProxy for loadbalancing and setting the max
number of connections per mongrel to 1.
Added bonus here is that all requests get queued op at HAProxy (which is
very conservative on memory use) and routed to the first available
mongrel process instead of getting queued op at mongrel level.
 
I read nginx would in the near future (or maybe already) have the option
to limit the number of simultaneous proxied connections. But HAProxy is
the only tool that can do this that I have experience with (still
wondering why the Rails community seems to favor Pound so much).
 
Piet.



________________________________

	From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Alexey
Verkhovsky
	Sent: donderdag 8 maart 2007 7:36
	To: mongrel-users at rubyforge.org
	Subject: Re: [Mongrel] Memory leaks in my site
	 
	<snip> 
	
	
	It also doesn't leak any memory at all *when it is not
overloaded*. E.g., under maximum non-concurent load (single-threaded
test client that fires the next request immediately upon receiving a
response to the previous one), it stays up forever.
	 
	When Mongrel + "Hello, World" is overloaded, there is a memory
leak to the tune of 6 Mb per hour. I have yet to figure out where is it
coming from. 
	
	 
	<snip>
	 
	Yes. Meantime, the recipe apparently is "serve static stuff
through an upstream web server, and use smaller values of --num--procs".
Mongrel that only receives dynamic requests is, essentialy, a
single-threaded process, anyway. The only reason to have more than one
(1) thread is so that other requests can queue up while it's doing
something that takes time. Cool. 
	
	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/88ef70f1/attachment.html 

From krisleech at interkonect.com  Thu Mar  8 05:57:06 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Thu, 08 Mar 2007 10:57:06 +0000
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
Message-ID: <45EFEC02.8020908@interkonect.com>

Please note this message is not related to my previous one from 
yesterday, this is on a different server (textdrive server).
I have only one mongrel application running but 'randomly' it will go 
down, the mongrel.log file shows:

ERROR: undefined method 'request_uri' for #<URI::Generic:0x5383948 URL:*>
ERROR: bad URI(is not URI?): c:\boot.ini
[FATAL] failed to allocate memory

This is on a FreeBSD server. What does the above mean please?

Mongrel 1.0.1



From kraemer at webit.de  Thu Mar  8 07:38:59 2007
From: kraemer at webit.de (Jens Kraemer)
Date: Thu, 8 Mar 2007 13:38:59 +0100
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <67B95D61E544254F98FE975AA08F2FB2D86600@srv-mail.win.antwerp.seagha.com>
References: <67B95D61E544254F98FE975AA08F2FB2D86600@srv-mail.win.antwerp.seagha.com>
Message-ID: <20070308123859.GS28036@cordoba.webit.de>

On Thu, Mar 08, 2007 at 10:24:40AM +0100, Piet Hadermann wrote:
>  
> Quick fix could be to use HAProxy for loadbalancing and setting the max
> number of connections per mongrel to 1.
> Added bonus here is that all requests get queued op at HAProxy (which is
> very conservative on memory use) and routed to the first available
> mongrel process instead of getting queued op at mongrel level.
>  
> I read nginx would in the near future (or maybe already) have the option
> to limit the number of simultaneous proxied connections. But HAProxy is
> the only tool that can do this that I have experience with (still
> wondering why the Rails community seems to favor Pound so much).

Afair Pen can limit the number of connections per mongrel process, too.

Jens

-- 
Jens Kr?mer
webit! Gesellschaft f?r neue Medien mbH
Schnorrstra?e 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
kraemer at webit.de | www.webit.de
 
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa

From filipe at icewall.org  Thu Mar  8 07:21:04 2007
From: filipe at icewall.org (Filipe)
Date: Thu, 8 Mar 2007 09:21:04 -0300 (BRT)
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <45EFEC02.8020908@interkonect.com>
References: <45EFEC02.8020908@interkonect.com>
Message-ID: <Pine.LNX.4.64.0703080918410.20092@sophie.icewall.org>


On Thu, 8 Mar 2007, Kris Leech wrote:

> Please note this message is not related to my previous one from
> yesterday, this is on a different server (textdrive server).
> I have only one mongrel application running but 'randomly' it will go
> down, the mongrel.log file shows:
>
> ERROR: undefined method 'request_uri' for #<URI::Generic:0x5383948 URL:*>
> ERROR: bad URI(is not URI?): c:\boot.ini
> [FATAL] failed to allocate memory

someone is trying to read the partition boot of your windows. OH, it's a
freebsd machine? I thing they didn't found anything then :D

This fatal error occurs just after the request?

>
> This is on a FreeBSD server. What does the above mean please?
>
> Mongrel 1.0.1
>
>

filipe {
  @             icewall.org
  GPG        1024D/A6BA423E
  Jabber  lautert at jabber.ru
}



From eden at mojiti.com  Thu Mar  8 08:58:03 2007
From: eden at mojiti.com (Eden Li)
Date: Thu, 8 Mar 2007 21:58:03 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <20070308085343.GO28036@cordoba.webit.de>
References: <2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
	<466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>
	<ab90312e0703072049v106f7c5fnd5d577d0d1eb5ca7@mail.gmail.com>
	<20070308085343.GO28036@cordoba.webit.de>
Message-ID: <1dd361e10703080558g702d2f42rbe4f5d7926984a2f@mail.gmail.com>

Probably off topic, but which version of ferret are you running?  The
latest incarnation (0.10.14 i think?) was segfaulting about every 10th
query bringing down mongrel along with it.

On 3/8/07, Jens Kraemer <kraemer at webit.de> wrote:
> I have a live app here running on Rails 1.2.1/MySQL with three mongrels
> for weeks without a hickup, each taking up max. 60MB of RAM. And yes, it
> uses acts_as_ferret :-)

From zedshaw at zedshaw.com  Thu Mar  8 13:11:24 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 8 Mar 2007 10:11:24 -0800
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <45EFEC02.8020908@interkonect.com>
References: <45EFEC02.8020908@interkonect.com>
Message-ID: <20070308101124.64a1d379.zedshaw@zedshaw.com>

On Thu, 08 Mar 2007 10:57:06 +0000
Kris Leech <krisleech at interkonect.com> wrote:

> Please note this message is not related to my previous one from 
> yesterday, this is on a different server (textdrive server).
> I have only one mongrel application running but 'randomly' it will go 
> down, the mongrel.log file shows:
> 
> ERROR: undefined method 'request_uri' for #<URI::Generic:0x5383948 URL:*>
> ERROR: bad URI(is not URI?): c:\boot.ini
> [FATAL] failed to allocate memory

Dammit, THIS is why I refused to add support for those idiots who
insist on making GET requests with a full URL.  It's just one more
attack vector and I can't validate the code in Ruby's URI parsing.

I'll probably make this optional then for those people who don't care
about IE on a localhost setup.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From zedshaw at zedshaw.com  Thu Mar  8 13:27:58 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 8 Mar 2007 10:27:58 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703072235u354359c3t700d5515a09ce0d8@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
	<20070307080359.64394ef6@nomadII.powershouse.bogus>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
	<20070307222626.ba3f9abe.zedshaw@zedshaw.com>
	<3945c4270703072235u354359c3t700d5515a09ce0d8@mail.gmail.com>
Message-ID: <20070308102758.9476853d.zedshaw@zedshaw.com>

On Wed, 7 Mar 2007 23:35:36 -0700
"Alexey Verkhovsky" <alexey.verkhovsky at gmail.com> wrote:

> Some further findings:
> 
> "Hello World" Rails application on my rather humble rig (Dell D620 laptop
> running Ubuntu 6.10, Ruby 1.8.4 and Rails 1.2.2)  can handle over 500 hits
> per second on the following action:
> 
> def say_hi
>   render :text => 'Hi!'
> end
> 
> It also doesn't leak any memory at all *when it is not overloaded*. E.g.,
> under maximum non-concurent load (single-threaded test client that fires the
> next request immediately upon receiving a response to the previous one), it
> stays up forever.

Sigh, I'll test this too, but the solution is to set -n to something
reasonable for your setup.

> What I was thinking is that by uncoupling the request from its thread, you
> can probably max out all capabilities (CPU, I/O, Rails) of a 4 cores
> commodity box with only 15-30 threads. 10-20 request handlers (that will
> either serve static stuff or carry the request to the Rails queue), one
> rails handler that loops over requests queue, takes requests to Rails and
> drops responses off in the response queue, 5-10 response handlers (whose job
> is simply to copy Rails response from responses queue to originating
> sockets).
> 
> Right now, as far as I understand the code, request is carried all the way
> through by the same thread.
> 
> On second thoughts, this is asynchronous communications between threads
> within the process. Far too much design and maintenance overhead for the
> marginal benefits it may (or may not) bring. Basically, just me being stupid
> by trying to be too smart. :)

Exactly, I went through this design too using various queueing
mechanisms and Ruby's Thread primitives were just too damn slow.  The
best way to get max performance was to start a thread which handled the
request and response.  The fastest (by a small margin) was not using
threads at all but instead using a select loop.  Problem with that is
then if your Rails code starts a Thread and doesn't do it right then
Ruby's idiotic deadlock detection kicks in because it considers the
select calls part of the deadlock detection.

Now that fastthread is out though, it might be worth checking out the
queueing model to see if it's still slow as hell or not.  Ultimately I
wanted a single thread that listened for connections and built the
HttpRequest/Response objects using select, then fire off these to a
queue of N numbers of processor threads.  Queue was just too damn slow
to pull it off so it didn't work out.

> > Until Ruby's IO, GC, and threads improve drastically you'll keep hitting
> > these problems.
> 
> 
> Yes. Meantime, the recipe apparently is "serve static stuff through an
> upstream web server, and use smaller values of --num--procs". Mongrel that
> only receives dynamic requests is, essentialy, a single-threaded process,
> anyway. The only reason to have more than one (1) thread is so that other
> requests can queue up while it's doing something that takes time. Cool.

Not really, if you set Mongrel to handle only -n 1 then your web server
will randomly kill off mongrels and connections from clients whenever
you run out of backends to service requests.  The nginx author is
currently working on a mechanism to allow you to queue the requests at
the proxy server before sending them back.

Also, -n 1 will not work for all the other Ruby web frameworks that
don't have this locking problem.  All of the other frameworks are
thread safe (even ones that use AR) and can run multiple requests
concurrently.

> By the way, is Ruby 1.9 solving all of these issues?

No idea, considering 1.9 is decades out at it's current pace.  You
should go look at JRuby if you want something modern that's able to run
Rails right now (and Mongrel).

> > No one who is sane is trying to really run a Rails app on a 64 meg VPS - -
> thats just asking for a lot of pain.
> Well, entry-level slices on most Rails VPS services are 64 Mb.
> My poking around so far seems to say "it's doable, but you need to tune it".

No, people need to quit thinking that this will work the way it did
when they dumped their crappy PHP code into a directory and prayed
Apache would run it.  Even in those situations that ease of deployment
and ability to run on small installations was an illusion.  Talk to
anyone who does serious PHP hosting and they'll tell you it gets much
more complicated.

Sorry to be so harsh, but as the saying goes, you can have it cheap,
fast, or reliable pick one. (Yes, one, I'm changing it. :-)

However, why are people are complaining about 64M of ram for a Mongrel
process?  C'mon, Java processes typically hit the 600M or even
2G ranges and that's just common place.  If you want small scale
hosting, you'll have to try a different solution entirely.

Even better, why are people complaining about the memory footprint of
RAILS on the MONGREL mailing list?  These same problems existed before
Mongrel, and when you complain here there's nothing I can really do.
You want the RAM to go down in Rails, then start writing the patches to
get it to go down.  I'm sure there's just oodles of savings to be made
inside Rails.


-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From alexey.verkhovsky at gmail.com  Thu Mar  8 11:52:09 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Thu, 8 Mar 2007 09:52:09 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <20070308102758.9476853d.zedshaw@zedshaw.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
	<20070307222626.ba3f9abe.zedshaw@zedshaw.com>
	<3945c4270703072235u354359c3t700d5515a09ce0d8@mail.gmail.com>
	<20070308102758.9476853d.zedshaw@zedshaw.com>
Message-ID: <3945c4270703080852v6730866ds415b48465b076a92@mail.gmail.com>

On 3/8/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
>  C'mon, Java processes typically hit the 600M or even
> 2G ranges and that's just common place.


Java runtime is a bloat. But its processes are natively multi-threaded and
can serve multiple apps from the same server. So, one Java process should
probably be compared with about 5-10 Rails processes in terms of RAM
footprint. It's still a bloat.

Even better, why are people complaining about the memory footprint of
> RAILS on the MONGREL mailing list?

Not guilty. In this thread, I am complaining about Mongrel's memory
footprint, not "Hello, World"'s. :)
Besides, I'm not even complaining, just trying to understand the ins and
outs of this stack, and what can or cannot be squeezed out of it.

By the way, I hope load balancing solutions are not off-topic? :)

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/958afb2c/attachment.html 

From kraemer at webit.de  Thu Mar  8 12:18:58 2007
From: kraemer at webit.de (Jens Kraemer)
Date: Thu, 8 Mar 2007 18:18:58 +0100
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <1dd361e10703080558g702d2f42rbe4f5d7926984a2f@mail.gmail.com>
References: <ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
	<466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>
	<ab90312e0703072049v106f7c5fnd5d577d0d1eb5ca7@mail.gmail.com>
	<20070308085343.GO28036@cordoba.webit.de>
	<1dd361e10703080558g702d2f42rbe4f5d7926984a2f@mail.gmail.com>
Message-ID: <20070308171858.GT28036@cordoba.webit.de>

On Thu, Mar 08, 2007 at 09:58:03PM +0800, Eden Li wrote:
> Probably off topic, but which version of ferret are you running?  The
> latest incarnation (0.10.14 i think?) was segfaulting about every 10th
> query bringing down mongrel along with it.

that's a common problem with 0.10.x, however I haven't experienced it
myself in this app (which uses 0.10.14), I guess because the index is 
mostly read-only.

Recent 0.11.x versions of Ferret seem to fix large parts of these
issues.

Jens


-- 
Jens Kr?mer
webit! Gesellschaft f?r neue Medien mbH
Schnorrstra?e 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
kraemer at webit.de | www.webit.de
 
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa

From abstractryan at gmail.com  Thu Mar  8 12:19:55 2007
From: abstractryan at gmail.com (Ryan Richards)
Date: Thu, 8 Mar 2007 11:19:55 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703080852v6730866ds415b48465b076a92@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>	<20070307222626.ba3f9abe.zedshaw@zedshaw.com>	<3945c4270703072235u354359c3t700d5515a09ce0d8@mail.gmail.com>	<20070308102758.9476853d.zedshaw@zedshaw.com>
	<3945c4270703080852v6730866ds415b48465b076a92@mail.gmail.com>
Message-ID: <000c01c761a5$fe320ea0$fa962be0$@com>

I agree - java server processes can get HUGE. I work with weblogic clusters
and we constantly have to change the thread pools and stack size on the
threads because they can get wayyy out of hand. 

 

Has anyone successfully created mongrel clusters spanning two or more
physical servers? Just curious.

 

Ryan

 

From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Alexey Verkhovsky
Sent: Thursday, March 08, 2007 10:52 AM
To: mongrel-users at rubyforge.org
Subject: Re: [Mongrel] Memory leaks in my site

 

On 3/8/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:

 C'mon, Java processes typically hit the 600M or even
2G ranges and that's just common place.


Java runtime is a bloat. But its processes are natively multi-threaded and
can serve multiple apps from the same server. So, one Java process should
probably be compared with about 5-10 Rails processes in terms of RAM
footprint. It's still a bloat. 

 

Even better, why are people complaining about the memory footprint of
RAILS on the MONGREL mailing list? 

Not guilty. In this thread, I am complaining about Mongrel's memory
footprint, not "Hello, World"'s. :)
Besides, I'm not even complaining, just trying to understand the ins and
outs of this stack, and what can or cannot be squeezed out of it. 

By the way, I hope load balancing solutions are not off-topic? :)

Alex

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/1d50ec07/attachment.html 

From zedshaw at zedshaw.com  Thu Mar  8 16:38:27 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 8 Mar 2007 13:38:27 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703080852v6730866ds415b48465b076a92@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
	<20070307222626.ba3f9abe.zedshaw@zedshaw.com>
	<3945c4270703072235u354359c3t700d5515a09ce0d8@mail.gmail.com>
	<20070308102758.9476853d.zedshaw@zedshaw.com>
	<3945c4270703080852v6730866ds415b48465b076a92@mail.gmail.com>
Message-ID: <20070308133827.f51d9e80.zedshaw@zedshaw.com>

On Thu, 8 Mar 2007 09:52:09 -0700
"Alexey Verkhovsky" <alexey.verkhovsky at gmail.com> wrote:

> On 3/8/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> >
> >  C'mon, Java processes typically hit the 600M or even
> > 2G ranges and that's just common place.
> 
> 
> Java runtime is a bloat. But its processes are natively multi-threaded and
> can serve multiple apps from the same server. So, one Java process should
> probably be compared with about 5-10 Rails processes in terms of RAM
> footprint. It's still a bloat.
> 
> Even better, why are people complaining about the memory footprint of
> > RAILS on the MONGREL mailing list?
> 
> Not guilty. In this thread, I am complaining about Mongrel's memory
> footprint, not "Hello, World"'s. :)
> Besides, I'm not even complaining, just trying to understand the ins and
> outs of this stack, and what can or cannot be squeezed out of it.

No, you're still testing Rails' memory usage.  If you want to test
Mongrel's you need to write a non-rails Mongrel handler that does
hello world.  For example, here's the tests I run to make sure that I
haven't destroyed Mongrel's memory usage:

SERVER	TEST	VSZ	RSS
Mongrel	Hello	20844	10564
Mongrel	Rails	56092	39512
Webrick	Hello	15180	4916
Webrick	Rails	56548	39924
ruby	IRB	4756	3252
ruby	IRB_Thr	12952	3376

IRB_Thr is just irb run with a single thread in sleep.  The two Hello
apps are pretty close to the same, and the Rails apps are the exact
same and show usage after the handling the same number of requests.

What you can see is even though Webrick is smaller than
Mongrel, it still ends up being the same size when it runs under
Rails.  That's why I say look at Rails if you want to save memory.
Even if you stripped Mongrel down to the absolute essentials, the
absolute impossible best is IRB_Thr.  If you could get Mongrel down to
Webrick's size, the test also shows it doesn't matter since the memory
goes up to the same as when running mongrel anyway.

No matter what, if you want to save memory you've gotta look at Rails
and not Mongrel.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From zedshaw at zedshaw.com  Thu Mar  8 16:39:25 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 8 Mar 2007 13:39:25 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <000c01c761a5$fe320ea0$fa962be0$@com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703070755u264cf158rc014f7ffa1d6cf56@mail.gmail.com>
	<2a0834610703070757v201f4fe7jb4c3ebe3208c475d@mail.gmail.com>
	<3945c4270703070832m1b948d8au3c4d21eb871bb98f@mail.gmail.com>
	<f4cd26df0703070839u7b6b424aqf5f6cc605a7183ad@mail.gmail.com>
	<2a0834610703070943x2b25ea36ge2d88f55f98ddbde@mail.gmail.com>
	<3945c4270703071638v144b0aabj1d5abb415c39625e@mail.gmail.com>
	<20070307222626.ba3f9abe.zedshaw@zedshaw.com>
	<3945c4270703072235u354359c3t700d5515a09ce0d8@mail.gmail.com>
	<20070308102758.9476853d.zedshaw@zedshaw.com>
	<3945c4270703080852v6730866ds415b48465b076a92@mail.gmail.com>
	<000c01c761a5$fe320ea0$fa962be0$@com>
Message-ID: <20070308133925.436bb959.zedshaw@zedshaw.com>

On Thu, 8 Mar 2007 11:19:55 -0600
"Ryan Richards" <abstractryan at gmail.com> wrote:

> I agree - java server processes can get HUGE. I work with weblogic clusters
> and we constantly have to change the thread pools and stack size on the
> threads because they can get wayyy out of hand. 
> 
>  
> 
> Has anyone successfully created mongrel clusters spanning two or more
> physical servers? Just curious.

Yep, many folks do this.  Just run the mongrels across the servers and
point your webserver or load balancer at them.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From Daniel.Berger at Qwest.com  Thu Mar  8 14:33:11 2007
From: Daniel.Berger at Qwest.com (Berger, Daniel)
Date: Thu, 8 Mar 2007 13:33:11 -0600
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <20070308101124.64a1d379.zedshaw@zedshaw.com>
Message-ID: <7524A45A1A5B264FA4809E2156496CFB0D0EF4@ITOMAE2KM01.AD.QINTRA.COM>

> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org 
> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed A. Shaw
> Sent: Thursday, March 08, 2007 11:11 AM
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] bad URI(is not URI?): c:\boot.ini
> 
> 
> On Thu, 08 Mar 2007 10:57:06 +0000
> Kris Leech <krisleech at interkonect.com> wrote:
> 
> > Please note this message is not related to my previous one from
> > yesterday, this is on a different server (textdrive server).
> > I have only one mongrel application running but 'randomly' 
> it will go 
> > down, the mongrel.log file shows:
> > 
> > ERROR: undefined method 'request_uri' for #<URI::Generic:0x5383948 
> > URL:*>
> > ERROR: bad URI(is not URI?): c:\boot.ini
> > [FATAL] failed to allocate memory
> 
> Dammit, THIS is why I refused to add support for those idiots 
> who insist on making GET requests with a full URL.  It's just 
> one more attack vector and I can't validate the code in 
> Ruby's URI parsing.
> 
> I'll probably make this optional then for those people who 
> don't care about IE on a localhost setup.

Is this something that needs to be fixed in the URI module, i.e.
handling Windows-style file URL's? Or should I just nevermind?

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

From zedshaw at zedshaw.com  Thu Mar  8 20:27:41 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 8 Mar 2007 17:27:41 -0800
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0EF4@ITOMAE2KM01.AD.QINTRA.COM>
References: <20070308101124.64a1d379.zedshaw@zedshaw.com>
	<7524A45A1A5B264FA4809E2156496CFB0D0EF4@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <20070308172741.43405e4c.zedshaw@zedshaw.com>

On Thu, 8 Mar 2007 13:33:11 -0600
"Berger, Daniel" <Daniel.Berger at Qwest.com> wrote:

> > I'll probably make this optional then for those people who 
> > don't care about IE on a localhost setup.
> 
> Is this something that needs to be fixed in the URI module, i.e.
> handling Windows-style file URL's? Or should I just nevermind?

No, it's more of an opening for an attack based on malformed URLs than
anything.

Normally, let's say you do a request for:

GET /<something horrible>/../c:\system.ini HTTP/1.1

Then Mongrel will take the <something horrible> and reject it since it
most likely is a parsing error.  This is why mongrel so easily defends
against a lot of attacks.  Not because it's actively trying, but just
by being strict.

The problem comes from an ambiguity in the RFC that says requests with:

GET http://localhost:3000/<something horrible>/../c:\system.ini HTTP/1.1

Are not valid, but still need to be processed by servers since clients
still try to use it.  The above line is intended for proxy servers
only, not end point web servers.  Mongrel isn't a proxy server, so all
this host information is useless.  The RFC is also ambiguous on which
host specification should win when this and a Host: header is given.

What happens is IE for various weird reasons insists on sending this as
its GET request.  Since people running rails on IE typically don't put
it behind a proxying server these requests aren't scrubbed so they blow
up.  Nothing they can do, and the only fix is to either reject these
outright or try parsing the requested URI to pull off the path and
request portions dropping the host and protocol junk.

Well, that's where the trouble lurks.  If the quality of cgi.rb is any
indicator, Ruby's URI parsing could have all sorts of
vulnerabilities.  It's not written using a parser so it's not easy to
validate correctness (you can look at mongrel's parser and check it
right away against the RFC).  Now that there's some attack available
for these kinds of URLs that only IE and Windows servers process
validly I begin to worry how long it'll be before there's an attack.

Then again I'm paranoid, but my paranoia has paid off for many people
and been right many times before.

So, long story short, there's nothing you can do unless you can fix
IE.  Only thing I'm going to do is add an option to reject these kinds
of URLs with the full host as attacks, and then see what happens. 

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From erik at runeland.se  Fri Mar  9 06:42:52 2007
From: erik at runeland.se (Erik Runeland)
Date: Fri, 9 Mar 2007 12:42:52 +0100
Subject: [Mongrel] https load balancer for windows?
Message-ID: <001e01c76240$12328c00$7800a8c0@intranet.syntune.com>

Hello,

 

I noticed that mongrel would work very nicely with something called Pound to
get https access to a rails app. However, I think Pound isn't available for
the windows platform? Is there any other nice lightweight load balancer like
Pound that I could take a look at to get https with mongrel and rails?

 

Cheers,

/Erik

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070309/6b12294c/attachment.html 

From jeroen at supercool.nl  Fri Mar  9 07:52:04 2007
From: jeroen at supercool.nl (Jeroen Houben)
Date: Fri, 09 Mar 2007 13:52:04 +0100
Subject: [Mongrel] how to translate request.params['PATH_INFO'] into
	physical file
Message-ID: <45F15874.3040903@supercool.nl>

Hi,

What's the most reliable way to find out the physical file location when 
given a request.params['PATH_INFO'] ?
I guess I need to know mongrel's document_root or something similar.

tia,

Jeroen


From eden at mojiti.com  Fri Mar  9 10:11:09 2007
From: eden at mojiti.com (Eden Li)
Date: Fri, 9 Mar 2007 23:11:09 +0800
Subject: [Mongrel] https load balancer for windows?
In-Reply-To: <001e01c76240$12328c00$7800a8c0@intranet.syntune.com>
References: <001e01c76240$12328c00$7800a8c0@intranet.syntune.com>
Message-ID: <1dd361e10703090711o5975aa7an8efff99ecdf3ec3e@mail.gmail.com>

pen will probably work -- although I can't seem to find any binaries
on their site: http://siag.nu/pen/.  Although, there does appear to be
one hidden on the ftp download site:
ftp://siag.nu/pub/pen/pen-0.17.1.exe...

On 3/9/07, Erik Runeland <erik at runeland.se> wrote:
>
>
>
>
> Hello,
>
>
>
> I noticed that mongrel would work very nicely with something called Pound to
> get https access to a rails app. However, I think Pound isn't available for
> the windows platform? Is there any other nice lightweight load balancer like
> Pound that I could take a look at to get https with mongrel and rails?
>
>
>
> Cheers,
>
> /Erik
>
>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From erik at runeland.se  Fri Mar  9 10:37:54 2007
From: erik at runeland.se (Erik Runeland)
Date: Fri, 9 Mar 2007 16:37:54 +0100
Subject: [Mongrel] https load balancer for windows?
In-Reply-To: <1dd361e10703090711o5975aa7an8efff99ecdf3ec3e@mail.gmail.com>
References: <001e01c76240$12328c00$7800a8c0@intranet.syntune.com>
	<1dd361e10703090711o5975aa7an8efff99ecdf3ec3e@mail.gmail.com>
Message-ID: <004501c76260$e98294a0$7800a8c0@intranet.syntune.com>

Okay thanks, I didn't notice anything about support for https at the Pen
site. Did I miss it somehow? It sort of claims to do "simple" TCP protocols,
and I'm not sure https/SSL counts as one of those. 

/Erik

> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users-
> bounces at rubyforge.org] On Behalf Of Eden Li
> Sent: den 9 mars 2007 16:11
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] https load balancer for windows?
> 
> pen will probably work -- although I can't seem to find any binaries
> on their site: http://siag.nu/pen/.  Although, there does appear to be
> one hidden on the ftp download site:
> ftp://siag.nu/pub/pen/pen-0.17.1.exe...
> 
> On 3/9/07, Erik Runeland <erik at runeland.se> wrote:
> >
> >
> >
> >
> > Hello,
> >
> >
> >
> > I noticed that mongrel would work very nicely with something called
> Pound to
> > get https access to a rails app. However, I think Pound isn't available
> for
> > the windows platform? Is there any other nice lightweight load balancer
> like
> > Pound that I could take a look at to get https with mongrel and rails?
> >
> >
> >
> > Cheers,
> >
> > /Erik
> >
> >
> >
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From eden at mojiti.com  Fri Mar  9 13:12:01 2007
From: eden at mojiti.com (Eden Li)
Date: Sat, 10 Mar 2007 02:12:01 +0800
Subject: [Mongrel] https load balancer for windows?
In-Reply-To: <004501c76260$e98294a0$7800a8c0@intranet.syntune.com>
References: <001e01c76240$12328c00$7800a8c0@intranet.syntune.com>
	<1dd361e10703090711o5975aa7an8efff99ecdf3ec3e@mail.gmail.com>
	<004501c76260$e98294a0$7800a8c0@intranet.syntune.com>
Message-ID: <1dd361e10703091012k1057d8d0v19e593993f1cf42@mail.gmail.com>

http://siag.nu/pen/howto.shtml#https

On 3/9/07, Erik Runeland <erik at runeland.se> wrote:
> Okay thanks, I didn't notice anything about support for https at the Pen
> site. Did I miss it somehow? It sort of claims to do "simple" TCP protocols,
> and I'm not sure https/SSL counts as one of those.
>
> /Erik
>
> > -----Original Message-----
> > From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users-
> > bounces at rubyforge.org] On Behalf Of Eden Li
> > Sent: den 9 mars 2007 16:11
> > To: mongrel-users at rubyforge.org
> > Subject: Re: [Mongrel] https load balancer for windows?
> >
> > pen will probably work -- although I can't seem to find any binaries
> > on their site: http://siag.nu/pen/.  Although, there does appear to be
> > one hidden on the ftp download site:
> > ftp://siag.nu/pub/pen/pen-0.17.1.exe...
> >
> > On 3/9/07, Erik Runeland <erik at runeland.se> wrote:
> > >
> > >
> > >
> > >
> > > Hello,
> > >
> > >
> > >
> > > I noticed that mongrel would work very nicely with something called
> > Pound to
> > > get https access to a rails app. However, I think Pound isn't available
> > for
> > > the windows platform? Is there any other nice lightweight load balancer
> > like
> > > Pound that I could take a look at to get https with mongrel and rails?
> > >
> > >
> > >
> > > Cheers,
> > >
> > > /Erik
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From km at acrasis.net  Fri Mar  9 13:48:31 2007
From: km at acrasis.net (km at acrasis.net)
Date: Fri, 9 Mar 2007 10:48:31 -0800
Subject: [Mongrel] Rails log file permissions
Message-ID: <20070309184831.GK4506@acrasis.net>

When I start a Rails server with

  $ mongrel_rails start --chdir ~/railsapp --port 3003 --pid \
      /home/me/railsapp/tmp/pids/mongrel.pid --daemonize

the server starts and opens two log files, development.log and
mongrel.log.  Both have permissions -rw-rw-rw-.

If I omit --deamonize, it opens one log file, development.log, with
permissions -rw-r--r--.

I would like to make the server use permissions of my choice in
either case.  How to do that?

Thanks
-- 
KM


From alexey.verkhovsky at gmail.com  Fri Mar  9 14:07:38 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Fri, 9 Mar 2007 12:07:38 -0700
Subject: [Mongrel] Rails log file permissions
In-Reply-To: <20070309184831.GK4506@acrasis.net>
References: <20070309184831.GK4506@acrasis.net>
Message-ID: <3945c4270703091107x68c3dd62lec39dfb4e932e24f@mail.gmail.com>

Don't know the answer yet (did you try setting umask on the logs directory?)

But do you know that by the time you go to production (and file permissions
on logs become important), the log file name MUST be production.log, not
development.log?

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070309/add1bee8/attachment-0001.html 

From zedshaw at zedshaw.com  Fri Mar  9 17:48:16 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 9 Mar 2007 14:48:16 -0800
Subject: [Mongrel] Rails log file permissions
In-Reply-To: <20070309184831.GK4506@acrasis.net>
References: <20070309184831.GK4506@acrasis.net>
Message-ID: <20070309144816.4d431a38.zedshaw@zedshaw.com>

On Fri, 9 Mar 2007 10:48:31 -0800
km at acrasis.net wrote:

> When I start a Rails server with
> 
>   $ mongrel_rails start --chdir ~/railsapp --port 3003 --pid \
>       /home/me/railsapp/tmp/pids/mongrel.pid --daemonize
> 
> the server starts and opens two log files, development.log and
> mongrel.log.  Both have permissions -rw-rw-rw-.
> 
> If I omit --deamonize, it opens one log file, development.log, with
> permissions -rw-r--r--.
> 
> I would like to make the server use permissions of my choice in
> either case.  How to do that?

If it's configurable you'd configure it in Rails not Mongrel (since
that log is created by Rails, not Mongrel).  Look at the documentation
for the Logger class in Ruby, but DO NOT use Logger's rotation
feature.  It will crash your system hard.

You should also check your umask for the user that you're running as a
daemon.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From alexey.verkhovsky at gmail.com  Fri Mar  9 20:49:30 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Fri, 9 Mar 2007 18:49:30 -0700
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
In-Reply-To: <3945c4270703061431p1b77f33amcb7205d0e7619fca@mail.gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
	<45EBC251.2060807@gmail.com>
	<3945c4270703061431p1b77f33amcb7205d0e7619fca@mail.gmail.com>
Message-ID: <3945c4270703091749n614137c2v811cafb2a819088c@mail.gmail.com>

OK, having done some research on the subject, I came to a conclusion that
the main problem with my scenario is that Ruby concurrency sucks, and should
be avoided. Other problems are the total RAM footprint and

Therefore, I'm currently leaning towards the following setup for, say, 20
apps running on the same box:

1. Apache (or possibly nginx) with 20 Virtual Hosts (vhost per app) serving
static content from ./public and redirecting dynamic requests to...

2. HAProxy on the same box, listening on 20 ports (port per app) and
configured to forward requests to 3-5 downstream ports per app, with
maxconns = 1 (which means that the proxy will send only one request at a
time to a downstream port). If all downstream proxies are busy or down,
HAProxy queues the requests internally. It is also smart about not sending
any requests to servers that are down. Below HAProxy, possibly on another
physical box(-es), there are...

3. 3-5 Mongrels per app, with --num-conns=2 (since we are not really sending
them more than one request at a time). This prevents a Mongrel process from
allocating an extra 60 to 100 Mb RAM to itself when it comes under overload.
Not all of these Mongrels need to be running. One or two per app may well be
enough. Two is better, as it prevents a long-running action from holding up
other requests.

When a "slashdotting" occurs, some sort of smart agent (even a human
operator) can start additional Mongrels as needed.

I've created a setup like this on my laptop yesterday, and stress-tested it
in some creative ways for half a day, running Mephisto with page caching
turned off.

Mongrels stayed up through the entire ordeal, at about 48 Mb VSS apiece,
because they were basically never overloaded. The system behaved gracefully
under overload (responding to as many requests as it could, and returning
HTTP 503 to the rest), and did the right things when I killed and restarted
individual Mongrels (seamlessly redirecting traffic to other nodes).

No memory leaks, zombie processes or any other abnormalities observed.

Another thing I discovered is that Ruby (since 1.8.5) can be told to commit
suicide if it needs to allocate more than a certain amount of RAM.
Process.setrlimit(Process::RLIMIT_AS) is the magical word. This is better
than harvests oversized processes with a cron job, because a greedy process
dies before the memory is actually allocated, so other processes on the same
OS remain unaffected.

Am I on the right track? What other issues should I be testing for /
thinking about?

Best regards,
Alex Verkhovsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070309/6d73226a/attachment.html 

From alexey.verkhovsky at gmail.com  Fri Mar  9 20:53:05 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Fri, 9 Mar 2007 18:53:05 -0700
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
In-Reply-To: <3945c4270703091749n614137c2v811cafb2a819088c@mail.gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
	<45EBC251.2060807@gmail.com>
	<3945c4270703061431p1b77f33amcb7205d0e7619fca@mail.gmail.com>
	<3945c4270703091749n614137c2v811cafb2a819088c@mail.gmail.com>
Message-ID: <3945c4270703091753t72051c9ay4e18348715b5f24c@mail.gmail.com>

On 3/9/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
>
> OK, having done some research on the subject, I came to a conclusion that
> the main problem with my scenario is that Ruby concurrency sucks, and should
> be avoided. Other problems are the total RAM footprint and


"gracefully surviving overloads" is the missing part.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070309/f41fef80/attachment.html 

From eric at maverixsystems.com  Sat Mar 10 12:37:28 2007
From: eric at maverixsystems.com (Eric Dean)
Date: Sat, 10 Mar 2007 12:37:28 -0500
Subject: [Mongrel] Mongrel Hangs After Idle Period
Message-ID: <003401c7633a$c6331d00$6501a8c0@SOHODEMO>

 
I had posted a thread couple of weeks ago whereby mongrel just mysteriously
stops interacting with my application after an idle period...usually less
than 8 hours.  
http://rubyforge.org/pipermail/mongrel-users/2007-February/002908.html
 
I had hoped this would go away after a few upgrades but to know avail.
Interestingly, the process does not die...it still accepts HTTP requests but
does not respond...just sits there deaf.  I do a cluster::stop and start and
we're back in action.
 
There is nothing at the tail of mongrel_log..and when I make new
connections..nothing gets appended
 
The answers to the previously asked questions are as follows:
1) We do not rotate logs (yet) so we don't use ruby to rotate
 
2) ruby script/about
About your application's environment
Ruby version                 1.8.5 (i686-linux)
RubyGems version             0.9.1
Rails version                1.2.0
Active Record version        1.14.4
Action Pack version          1.12.5
Action Web Service version   1.1.6
Action Mailer version        1.2.5
Active Support version       1.3.1
Edge Rails revision          175
Application root             /home/webapp/visualcareers_3_7
Environment                  development
Database adapter             mysql
Database schema version      44
 
3) cat config/database.yml
 
development:
  adapter: mysql
  database: server_development
  username: ******
  password: ******
  host: my.server.com
 
test:
  adapter: mysql
  database: server_test
  username: ******
  password: ******
  host: localhost
 
production:
  adapter: mysql
  database: server_production
  username: ******
  password: ******
  host: localhost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070310/cf5da20e/attachment.html 

From jbaty at fusionary.com  Sat Mar 10 13:06:52 2007
From: jbaty at fusionary.com (Jack Baty)
Date: Sat, 10 Mar 2007 13:06:52 -0500
Subject: [Mongrel] Mongrel Hangs After Idle Period
In-Reply-To: <003401c7633a$c6331d00$6501a8c0@SOHODEMO>
References: <003401c7633a$c6331d00$6501a8c0@SOHODEMO>
Message-ID: <81350a250703101006q23fd088cj37a3cecd14bf176a@mail.gmail.com>

On 3/10/07, Eric Dean <eric at maverixsystems.com> wrote:
>
> I had posted a thread couple of weeks ago whereby mongrel just mysteriously
> stops interacting with my application after an idle period...usually less
> than 8 hours.
>

For the record, I'm seeing the same thing. Any site not being hit for
a period of time (exact period unknown) will just go deaf and require
a cluster::restart

Rails 1.2.2
Mongrel 1.0.1
Apache 2.2.3 w/proxy_balancer

-- 
--------------------------------------------------------------------------------
Jack Baty                  http://jackbaty.com/    (616) 822-5800
Fusionary                  http://fusionary.com/   (616) 454-2357
820 Monroe N.W. Suite 212
Grand Rapids, MI 49503

From codeturkey at comcast.net  Sat Mar 10 13:40:46 2007
From: codeturkey at comcast.net (Steven Hansen)
Date: Sat, 10 Mar 2007 10:40:46 -0800
Subject: [Mongrel] Mongrel Hangs After Idle Period
In-Reply-To: <003401c7633a$c6331d00$6501a8c0@SOHODEMO>
References: <003401c7633a$c6331d00$6501a8c0@SOHODEMO>
Message-ID: <45F2FBAE.80102@comcast.net>



This sounds like the mysql timeout bug.

Have you seen this thread?  
http://rubyforge.org/pipermail/mongrel-users/2006-November/002178.html

Regards,
Steven


Eric Dean wrote:
>  
> I had posted a thread couple of weeks ago whereby mongrel just 
> mysteriously stops interacting with my application after an idle 
> period...usually less than 8 hours. 
> http://rubyforge.org/pipermail/mongrel-users/2007-February/002908.html
>  
> I had hoped this would go away after a few upgrades but to know 
> avail.  Interestingly, the process does not die...it still accepts 
> HTTP requests but does not respond...just sits there deaf.  I do a 
> cluster::stop and start and we're back in action.
>  
> There is nothing at the tail of mongrel_log..and when I make new 
> connections..nothing gets appended
>  
> The answers to the previously asked questions are as follows:
> 1) We do not rotate logs (yet) so we don't use ruby to rotate
>  
> 2) ruby script/about
> About your application's environment
> Ruby version                 1.8.5 (i686-linux)
> RubyGems version             0.9.1
> Rails version                1.2.0
> Active Record version        1.14.4
> Action Pack version          1.12.5
> Action Web Service version   1.1.6
> Action Mailer version        1.2.5
> Active Support version       1.3.1
> Edge Rails revision          175
> Application root             /home/webapp/visualcareers_3_7
> Environment                  development
> Database adapter             mysql
> Database schema version      44
>  
> 3) cat config/database.yml
>  
> development:
>   adapter: mysql
>   database: server_development
>   username: ******
>   password: ******
>   host: my.server.com
>  
> test:
>   adapter: mysql
>   database: server_test
>   username: ******
>   password: ******
>   host: localhost
>  
> production:
>   adapter: mysql
>   database: server_production
>   username: ******
>   password: ******
>   host: localhost
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From joost at spacebabies.nl  Sat Mar 10 13:53:00 2007
From: joost at spacebabies.nl (joost baaij)
Date: Sat, 10 Mar 2007 19:53:00 +0100
Subject: [Mongrel] Mongrel Hangs After Idle Period
In-Reply-To: <003401c7633a$c6331d00$6501a8c0@SOHODEMO>
References: <003401c7633a$c6331d00$6501a8c0@SOHODEMO>
Message-ID: <6B19658A-FAA6-4636-8253-8E93B2F4B30E@spacebabies.nl>

I had this exact same problem. I *think* I've tracked down the  
source: a memory-leaking plugin. In any case Mongrel had nothing to  
do with it, it was my Rails app.

Op 10-mrt-2007, om 18:37 heeft Eric Dean het volgende geschreven:

>
> I had posted a thread couple of weeks ago whereby mongrel just  
> mysteriously stops interacting with my application after an idle  
> period...usually less than 8 hours.
> http://rubyforge.org/pipermail/mongrel-users/2007-February/002908.html
>
> I had hoped this would go away after a few upgrades but to know  
> avail.  Interestingly, the process does not die...it still accepts  
> HTTP requests but does not respond...just sits there deaf.  I do a  
> cluster::stop and start and we're back in action.
>
> There is nothing at the tail of mongrel_log..and when I make new  
> connections..nothing gets appended
>
> The answers to the previously asked questions are as follows:
> 1) We do not rotate logs (yet) so we don't use ruby to rotate
>
> 2) ruby script/about
> About your application's environment
> Ruby version                 1.8.5 (i686-linux)
> RubyGems version             0.9.1
> Rails version                1.2.0
> Active Record version        1.14.4
> Action Pack version          1.12.5
> Action Web Service version   1.1.6
> Action Mailer version        1.2.5
> Active Support version       1.3.1
> Edge Rails revision          175
> Application root             /home/webapp/visualcareers_3_7
> Environment                  development
> Database adapter             mysql
> Database schema version      44
>
> 3) cat config/database.yml
>
> development:
>   adapter: mysql
>   database: server_development
>   username: ******
>   password: ******
>   host: my.server.com
>
> test:
>   adapter: mysql
>   database: server_test
>   username: ******
>   password: ******
>   host: localhost
>
> production:
>   adapter: mysql
>   database: server_production
>   username: ******
>   password: ******
>   host: localhost
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- 
www.gomagazine.nl +31643904460 pobox 51059 nl-1007eb amsterdam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070310/ec3b479f/attachment-0001.bin 

From jgeiger at gmail.com  Sat Mar 10 14:36:12 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Sat, 10 Mar 2007 13:36:12 -0600
Subject: [Mongrel] Mongrel Hangs After Idle Period
In-Reply-To: <6B19658A-FAA6-4636-8253-8E93B2F4B30E@spacebabies.nl>
References: <003401c7633a$c6331d00$6501a8c0@SOHODEMO>
	<6B19658A-FAA6-4636-8253-8E93B2F4B30E@spacebabies.nl>
Message-ID: <466af3440703101136v41cdd51ej6624120581bf293d@mail.gmail.com>

What is the plugin you believe to be leaking memory?

On 3/10/07, joost baaij <joost at spacebabies.nl> wrote:
> I had this exact same problem. I *think* I've tracked down the
> source: a memory-leaking plugin. In any case Mongrel had nothing to
> do with it, it was my Rails app.
>
> Op 10-mrt-2007, om 18:37 heeft Eric Dean het volgende geschreven:
>
> >
> > I had posted a thread couple of weeks ago whereby mongrel just
> > mysteriously stops interacting with my application after an idle
> > period...usually less than 8 hours.
> > http://rubyforge.org/pipermail/mongrel-users/2007-February/002908.html
> >
> > I had hoped this would go away after a few upgrades but to know
> > avail.  Interestingly, the process does not die...it still accepts
> > HTTP requests but does not respond...just sits there deaf.  I do a
> > cluster::stop and start and we're back in action.
> >
> > There is nothing at the tail of mongrel_log..and when I make new
> > connections..nothing gets appended
> >
> > The answers to the previously asked questions are as follows:
> > 1) We do not rotate logs (yet) so we don't use ruby to rotate
> >
> > 2) ruby script/about
> > About your application's environment
> > Ruby version                 1.8.5 (i686-linux)
> > RubyGems version             0.9.1
> > Rails version                1.2.0
> > Active Record version        1.14.4
> > Action Pack version          1.12.5
> > Action Web Service version   1.1.6
> > Action Mailer version        1.2.5
> > Active Support version       1.3.1
> > Edge Rails revision          175
> > Application root             /home/webapp/visualcareers_3_7
> > Environment                  development
> > Database adapter             mysql
> > Database schema version      44
> >
> > 3) cat config/database.yml
> >
> > development:
> >   adapter: mysql
> >   database: server_development
> >   username: ******
> >   password: ******
> >   host: my.server.com
> >
> > test:
> >   adapter: mysql
> >   database: server_test
> >   username: ******
> >   password: ******
> >   host: localhost
> >
> > production:
> >   adapter: mysql
> >   database: server_production
> >   username: ******
> >   password: ******
> >   host: localhost
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
>
> --
> www.gomagazine.nl +31643904460 pobox 51059 nl-1007eb amsterdam
>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>

From krisleech at interkonect.com  Sat Mar 10 14:57:17 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Sat, 10 Mar 2007 19:57:17 +0000
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <Pine.LNX.4.64.0703080918410.20092@sophie.icewall.org>
References: <45EFEC02.8020908@interkonect.com>
	<Pine.LNX.4.64.0703080918410.20092@sophie.icewall.org>
Message-ID: <45F30D9D.7090605@interkonect.com>

Filipe wrote:
> On Thu, 8 Mar 2007, Kris Leech wrote:
>
>   
>> Please note this message is not related to my previous one from
>> yesterday, this is on a different server (textdrive server).
>> I have only one mongrel application running but 'randomly' it will go
>> down, the mongrel.log file shows:
>>
>> ERROR: undefined method 'request_uri' for #<URI::Generic:0x5383948 URL:*>
>> ERROR: bad URI(is not URI?): c:\boot.ini
>> [FATAL] failed to allocate memory
>>     
>
> someone is trying to read the partition boot of your windows. OH, it's a
> freebsd machine? I thing they didn't found anything then :D
>
> This fatal error occurs just after the request?
>   
I'm not  really sure when its happening its kinda random in that the 
site is up and working and then I'll get an email saying its down again.
There is no clear pattern to it going down. Not that I can currently see 
anyway. And yes its FreeBSD.
So you are saying this is a hack attack of sorts? It is a very new site, 
not even in google etc. yet, but maybe because it is on textdrive it is 
being targeted. Having said that they would know Textdrive is on FreeBSD 
and not Windows, so my guess is some kind of automated attack?
Is there anything I can do to stop it actually bringing the server down?
>   
>> This is on a FreeBSD server. What does the above mean please?
>>
>> Mongrel 1.0.1
>>
>>
>>     
>
> filipe {
>   @             icewall.org
>   GPG        1024D/A6BA423E
>   Jabber  lautert at jabber.ru
> }
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>
>   



From krisleech at interkonect.com  Sat Mar 10 15:00:57 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Sat, 10 Mar 2007 20:00:57 +0000
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <20070308101124.64a1d379.zedshaw@zedshaw.com>
References: <45EFEC02.8020908@interkonect.com>
	<20070308101124.64a1d379.zedshaw@zedshaw.com>
Message-ID: <45F30E79.8080506@interkonect.com>

Zed A. Shaw wrote:
> On Thu, 08 Mar 2007 10:57:06 +0000
> Kris Leech <krisleech at interkonect.com> wrote:
>
>   
>> Please note this message is not related to my previous one from 
>> yesterday, this is on a different server (textdrive server).
>> I have only one mongrel application running but 'randomly' it will go 
>> down, the mongrel.log file shows:
>>
>> ERROR: undefined method 'request_uri' for #<URI::Generic:0x5383948 URL:*>
>> ERROR: bad URI(is not URI?): c:\boot.ini
>> [FATAL] failed to allocate memory
>>     
>
> Dammit, THIS is why I refused to add support for those idiots who
> insist on making GET requests with a full URL.  It's just one more
> attack vector and I can't validate the code in Ruby's URI parsing.
>
> I'll probably make this optional then for those people who don't care
> about IE on a localhost setup.
>   
Hi Zed, I'm not sure what your getting at...
Is this a common or unique problem?

Thanks for your time.



From krisleech at interkonect.com  Sat Mar 10 15:05:03 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Sat, 10 Mar 2007 20:05:03 +0000
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <20070308172741.43405e4c.zedshaw@zedshaw.com>
References: <20070308101124.64a1d379.zedshaw@zedshaw.com>	<7524A45A1A5B264FA4809E2156496CFB0D0EF4@ITOMAE2KM01.AD.QINTRA.COM>
	<20070308172741.43405e4c.zedshaw@zedshaw.com>
Message-ID: <45F30F6F.4030600@interkonect.com>

Zed A. Shaw wrote:
> On Thu, 8 Mar 2007 13:33:11 -0600
> "Berger, Daniel" <Daniel.Berger at Qwest.com> wrote:
>
>   
>>> I'll probably make this optional then for those people who 
>>> don't care about IE on a localhost setup.
>>>       
>> Is this something that needs to be fixed in the URI module, i.e.
>> handling Windows-style file URL's? Or should I just nevermind?
>>     
>
> No, it's more of an opening for an attack based on malformed URLs than
> anything.
>
> Normally, let's say you do a request for:
>
> GET /<something horrible>/../c:\system.ini HTTP/1.1
>
> Then Mongrel will take the <something horrible> and reject it since it
> most likely is a parsing error.  This is why mongrel so easily defends
> against a lot of attacks.  Not because it's actively trying, but just
> by being strict.
>
> The problem comes from an ambiguity in the RFC that says requests with:
>
> GET http://localhost:3000/<something horrible>/../c:\system.ini HTTP/1.1
>
> Are not valid, but still need to be processed by servers since clients
> still try to use it.  The above line is intended for proxy servers
> only, not end point web servers.  Mongrel isn't a proxy server, so all
> this host information is useless.  The RFC is also ambiguous on which
> host specification should win when this and a Host: header is given.
>
> What happens is IE for various weird reasons insists on sending this as
> its GET request.  Since people running rails on IE typically don't put
> it behind a proxying server these requests aren't scrubbed so they blow
> up.  Nothing they can do, and the only fix is to either reject these
> outright or try parsing the requested URI to pull off the path and
> request portions dropping the host and protocol junk.
>
> Well, that's where the trouble lurks.  If the quality of cgi.rb is any
> indicator, Ruby's URI parsing could have all sorts of
> vulnerabilities.  It's not written using a parser so it's not easy to
> validate correctness (you can look at mongrel's parser and check it
> right away against the RFC).  Now that there's some attack available
> for these kinds of URLs that only IE and Windows servers process
> validly I begin to worry how long it'll be before there's an attack.
>
> Then again I'm paranoid, but my paranoia has paid off for many people
> and been right many times before.
>
> So, long story short, there's nothing you can do unless you can fix
> IE.  Only thing I'm going to do is add an option to reject these kinds
> of URLs with the full host as attacks, and then see what happens. 
>   
Now I see. At current this can be used as a DOS attack since it actually 
brings Mongrel down.




From krisleech at interkonect.com  Sat Mar 10 15:06:55 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Sat, 10 Mar 2007 20:06:55 +0000
Subject: [Mongrel] Two Mongrel's Two Rails Applications
In-Reply-To: <45EEF63F.8050109@alternativefocusmedia.com>
References: <45EEF63F.8050109@alternativefocusmedia.com>
Message-ID: <45F30FDF.9080405@interkonect.com>

Kris Leech wrote:
> Hi, I have Mongrel up and running for one application (port 3000), but 
> when I start another Mongrel for a second application (port 4000) I can 
> access both sites locally (using curl) but not remotly via a browser.
>
> If I stop the first applications Mongrel and start the second the second 
> one works. In other words I can only run one application at once...
>
> I have both on different ports, it makes no difference if I run the apps 
> in development or production mode or change the port numbers.
>
> Any suggestions would be great!
>
> Rails 1.2.1
> Ruby 1.8.5
> Mongrel 1.0.1
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>
>   
Fixed. It was something so silly, I did not setup proxypass for the 
other port!!



From dallas.devries at gmail.com  Sat Mar 10 17:09:00 2007
From: dallas.devries at gmail.com (Dallas DeVries)
Date: Sat, 10 Mar 2007 17:09:00 -0500
Subject: [Mongrel] upgrading rails to 1.2.2 giving me mongrel errors
Message-ID: <1200dbac0703101409r729cbc97nb4e5f31b916431e4@mail.gmail.com>

I'm working on upgrading to rails 1.2.2 from 1.1.6 and getting the mongrel
error below in development mode.  Now things seem to work fine with 1.1.6and
1.2.2 (in prod mode).
Any ideas what might cause this?  Googling gave me very little to work
with.  This was the closest thing i found
http://dev.rubyonrails.org/ticket/6716

I'm running Ubuntu with mongrel 1.0.1 and fastthread 0.6.4.1.  I also get
this on macosx

Thanks!
Dallas


Error calling Dispatcher.dispatch #<NameError: cannot remove
Object::USER_AGENT>
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:422:in
`remove_const'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:422:in
`remove_constant'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:273:in
`remove_unloadable_constants!'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:273:in
`remove_unloadable_constants!'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:72:in
`clear'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:60:in
`reset_application!'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:116:in
`reset_after_dispatch'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:51:in `dispatch'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:78:in
`process'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76:in
`process'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:618:in
`process_client'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in
`process_client'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in
`run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in
`run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in
`run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
/usr/bin/mongrel_rails:18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070310/d65e87dd/attachment.html 

From eimorton at gmail.com  Sat Mar 10 18:22:29 2007
From: eimorton at gmail.com (Erik Morton)
Date: Sat, 10 Mar 2007 18:22:29 -0500
Subject: [Mongrel] upgrading rails to 1.2.2 giving me mongrel errors
In-Reply-To: <1200dbac0703101409r729cbc97nb4e5f31b916431e4@mail.gmail.com>
References: <1200dbac0703101409r729cbc97nb4e5f31b916431e4@mail.gmail.com>
Message-ID: <8598A8DE-1466-4882-BED7-B900D0BACD1D@gmail.com>

For what it's worth I was getting the same error, except the object  
was from RMagick. I moved all the 'include Magick' statements to  
below the class definitions and the errors have, so far, gone away. I  
never dug deep enough into the differences between 1.2.2 and 1.1.6 to  
figure out what was causing the error.
On Mar 10, 2007, at 5:09 PM, Dallas DeVries wrote:

> I'm working on upgrading to rails 1.2.2 from 1.1.6 and getting the  
> mongrel error below in development mode.  Now things seem to work  
> fine with 1.1.6 and 1.2.2 (in prod mode).
> Any ideas what might cause this?  Googling gave me very little to  
> work with.  This was the closest thing i found  http:// 
> dev.rubyonrails.org/ticket/6716
>
> I'm running Ubuntu with mongrel 1.0.1 and fastthread 0.6.4.1.  I  
> also get this on macosx
>
> Thanks!
> Dallas
>
>
> Error calling Dispatcher.dispatch #<NameError: cannot remove  
> Object::USER_AGENT>
> /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/ 
> dependencies.rb:422:in `remove_const'
> /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/ 
> dependencies.rb:422:in `remove_constant'
> /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/ 
> dependencies.rb:273:in `remove_unloadable_constants!'
> /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/ 
> dependencies.rb:273:in `remove_unloadable_constants!'
> /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/ 
> dependencies.rb:72:in `clear'
> /usr/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:60:in  
> `reset_application!'
> /usr/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:116:in  
> `reset_after_dispatch'
> /usr/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/dispatcher.rb:51:in  
> `dispatch'
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb: 
> 78:in `process'
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb: 
> 76:in `process'
> /usr/lib/ruby/gems/1.8/gems/mongrel- 1.0.1/lib/mongrel.rb:618:in  
> `process_client'
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in  
> `process_client'
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'
> /usr/lib/ruby/gems/1.8/gems/mongrel- 1.0.1/lib/mongrel.rb:736:in `run'
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `run'
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ 
> configurator.rb:271:in `run'
> /usr/lib/ruby/gems/1.8/gems/mongrel- 1.0.1/lib/mongrel/ 
> configurator.rb:270:in `run'
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in  
> `run'
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb: 
> 211:in `run'
> /usr/lib/ruby/gems/1.8/gems/mongrel- 1.0.1/bin/mongrel_rails:243
> /usr/bin/mongrel_rails:18
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From devrieda at gmail.com  Sat Mar 10 19:06:14 2007
From: devrieda at gmail.com (Derek DeVries)
Date: Sat, 10 Mar 2007 17:06:14 -0700
Subject: [Mongrel] upgrading rails to 1.2.2 giving me mongrel errors
In-Reply-To: <8598A8DE-1466-4882-BED7-B900D0BACD1D@gmail.com>
References: <1200dbac0703101409r729cbc97nb4e5f31b916431e4@mail.gmail.com>
	<8598A8DE-1466-4882-BED7-B900D0BACD1D@gmail.com>
Message-ID: <7bdec5870703101606v16b5bfc0x52e1c866ca78aa03@mail.gmail.com>

Thanks Erik, looks like this error had to do with the new way Rails
1.2loads packages. Taking out the include fixed it for us as well.

Derek

On 3/10/07, Erik Morton <eimorton at gmail.com> wrote:
>
> For what it's worth I was getting the same error, except the object
> was from RMagick. I moved all the 'include Magick' statements to
> below the class definitions and the errors have, so far, gone away. I
> never dug deep enough into the differences between 1.2.2 and 1.1.6 to
> figure out what was causing the error.
> On Mar 10, 2007, at 5:09 PM, Dallas DeVries wrote:
>
> > I'm working on upgrading to rails 1.2.2 from 1.1.6 and getting the
> > mongrel error below in development mode.  Now things seem to work
> > fine with 1.1.6 and 1.2.2 (in prod mode).
> > Any ideas what might cause this?  Googling gave me very little to
> > work with.  This was the closest thing i found  http://
> > dev.rubyonrails.org/ticket/6716
> >
> > I'm running Ubuntu with mongrel 1.0.1 and fastthread 0.6.4.1.  I
> > also get this on macosx
> >
> > Thanks!
> > Dallas
> >
> >
> > Error calling Dispatcher.dispatch #<NameError: cannot remove
> > Object::USER_AGENT>
> > /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/
> > dependencies.rb:422:in `remove_const'
> > /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/
> > dependencies.rb:422:in `remove_constant'
> > /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/
> > dependencies.rb:273:in `remove_unloadable_constants!'
> > /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/
> > dependencies.rb:273:in `remove_unloadable_constants!'
> > /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/
> > dependencies.rb:72:in `clear'
> > /usr/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:60:in
> > `reset_application!'
> > /usr/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:116:in
> > `reset_after_dispatch'
> > /usr/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/dispatcher.rb:51:in
> > `dispatch'
> > /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:
> > 78:in `process'
> > /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:
> > 76:in `process'
> > /usr/lib/ruby/gems/1.8/gems/mongrel- 1.0.1/lib/mongrel.rb:618:in
> > `process_client'
> > /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in
> > `process_client'
> > /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'
> > /usr/lib/ruby/gems/1.8/gems/mongrel- 1.0.1/lib/mongrel.rb:736:in `run'
> > /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `run'
> > /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/
> > configurator.rb:271:in `run'
> > /usr/lib/ruby/gems/1.8/gems/mongrel- 1.0.1/lib/mongrel/
> > configurator.rb:270:in `run'
> > /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in
> > `run'
> > /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:
> > 211:in `run'
> > /usr/lib/ruby/gems/1.8/gems/mongrel- 1.0.1/bin/mongrel_rails:243
> > /usr/bin/mongrel_rails:18
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070310/976939e3/attachment-0001.html 

From joost at spacebabies.nl  Sat Mar 10 23:02:41 2007
From: joost at spacebabies.nl (joost baaij)
Date: Sun, 11 Mar 2007 05:02:41 +0100
Subject: [Mongrel] Mongrel Hangs After Idle Period
In-Reply-To: <466af3440703101136v41cdd51ej6624120581bf293d@mail.gmail.com>
References: <003401c7633a$c6331d00$6501a8c0@SOHODEMO>
	<6B19658A-FAA6-4636-8253-8E93B2F4B30E@spacebabies.nl>
	<466af3440703101136v41cdd51ej6624120581bf293d@mail.gmail.com>
Message-ID: <E3DC51FC-DDF5-45C2-BB82-22968D8CBFEF@spacebabies.nl>

RMagick.

Op 10-mrt-2007, om 20:36 heeft Joey Geiger het volgende geschreven:

> What is the plugin you believe to be leaking memory?
>
> On 3/10/07, joost baaij <joost at spacebabies.nl> wrote:
>> I had this exact same problem. I *think* I've tracked down the
>> source: a memory-leaking plugin. In any case Mongrel had nothing to
>> do with it, it was my Rails app.
>>
>> Op 10-mrt-2007, om 18:37 heeft Eric Dean het volgende geschreven:
>>
>>>
>>> I had posted a thread couple of weeks ago whereby mongrel just
>>> mysteriously stops interacting with my application after an idle
>>> period...usually less than 8 hours.
>>> http://rubyforge.org/pipermail/mongrel-users/2007-February/ 
>>> 002908.html
>>>
>>> I had hoped this would go away after a few upgrades but to know
>>> avail.  Interestingly, the process does not die...it still accepts
>>> HTTP requests but does not respond...just sits there deaf.  I do a
>>> cluster::stop and start and we're back in action.
>>>
>>> There is nothing at the tail of mongrel_log..and when I make new
>>> connections..nothing gets appended
>>>
>>> The answers to the previously asked questions are as follows:
>>> 1) We do not rotate logs (yet) so we don't use ruby to rotate
>>>
>>> 2) ruby script/about
>>> About your application's environment
>>> Ruby version                 1.8.5 (i686-linux)
>>> RubyGems version             0.9.1
>>> Rails version                1.2.0
>>> Active Record version        1.14.4
>>> Action Pack version          1.12.5
>>> Action Web Service version   1.1.6
>>> Action Mailer version        1.2.5
>>> Active Support version       1.3.1
>>> Edge Rails revision          175
>>> Application root             /home/webapp/visualcareers_3_7
>>> Environment                  development
>>> Database adapter             mysql
>>> Database schema version      44
>>>
>>> 3) cat config/database.yml
>>>
>>> development:
>>>   adapter: mysql
>>>   database: server_development
>>>   username: ******
>>>   password: ******
>>>   host: my.server.com
>>>
>>> test:
>>>   adapter: mysql
>>>   database: server_test
>>>   username: ******
>>>   password: ******
>>>   host: localhost
>>>
>>> production:
>>>   adapter: mysql
>>>   database: server_production
>>>   username: ******
>>>   password: ******
>>>   host: localhost
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>> --
>> www.gomagazine.nl +31643904460 pobox 51059 nl-1007eb amsterdam
>>
>>
>>
>> _______________________________________________
>> 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

-- 
www.gomagazine.nl +31643904460 pobox 51059 nl-1007eb amsterdam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070311/efc280e8/attachment.bin 

From jeroen at supercool.nl  Sun Mar 11 18:38:21 2007
From: jeroen at supercool.nl (Jeroen Houben)
Date: Sun, 11 Mar 2007 23:38:21 +0100
Subject: [Mongrel] how to translate request.params['PATH_INFO']
 into	physical file
In-Reply-To: <45F15874.3040903@supercool.nl>
References: <45F15874.3040903@supercool.nl>
Message-ID: <45F484DD.1000008@supercool.nl>

Jeroen Houben wrote:
> Hi,
> 
> What's the most reliable way to find out the physical file location when 
> given a request.params['PATH_INFO'] ?
> I guess I need to know mongrel's document_root or something similar.

Ah found something myself. This seems to work for me:

   def initialize(options = {})
     @observe_path = '/flvstream'
     @docroot      = options[:cwd] + "/" + options[:docroot]
   end

Jeroen

From christopher at mintdigital.com  Sun Mar 11 22:33:50 2007
From: christopher at mintdigital.com (Christopher Wilson)
Date: Sun, 11 Mar 2007 22:33:50 -0400
Subject: [Mongrel] Mongrel - HUP Signal
Message-ID: <45F4BC0E.20302@mintdigital.com>

With the latest version of Mongrel, will Mongrel reopen log files when 
sent a HUP signal?  I would like to do a log rotate, but would prefer 
not to restart the mongrel instances as monit is watching after them 
all.  monit is great for restarting the individual instances, but I 
would prefer not to do a restart all through monit.

I would be curious if this is advisable.


-- 
-----
Christopher Wilson

Mint Digital
www.mintdigital.com

-----
www.islandoo.com

From jgeiger at gmail.com  Mon Mar 12 06:50:08 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Mon, 12 Mar 2007 05:50:08 -0500
Subject: [Mongrel] Mongrel - HUP Signal
In-Reply-To: <45F4BC0E.20302@mintdigital.com>
References: <45F4BC0E.20302@mintdigital.com>
Message-ID: <466af3440703120350x5da9d9f1ua95bfba92b8e0cf0@mail.gmail.com>

I actually wrote a script to kill my mongrels one at a time (every 30
seconds) after a log rotate and I just let monit start them back up.

I may lose some rails logging, but I don't mind.

On 3/11/07, Christopher Wilson <christopher at mintdigital.com> wrote:
> With the latest version of Mongrel, will Mongrel reopen log files when
> sent a HUP signal?  I would like to do a log rotate, but would prefer
> not to restart the mongrel instances as monit is watching after them
> all.  monit is great for restarting the individual instances, but I
> would prefer not to do a restart all through monit.
>
> I would be curious if this is advisable.
>
>
> --
> -----
> Christopher Wilson
>
> Mint Digital
> www.mintdigital.com
>
> -----
> www.islandoo.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From jeroen at supercool.nl  Mon Mar 12 08:47:27 2007
From: jeroen at supercool.nl (Jeroen Houben)
Date: Mon, 12 Mar 2007 13:47:27 +0100
Subject: [Mongrel] need help writing a plugin
Message-ID: <45F54BDF.7030208@supercool.nl>

Hi,

I'm halfway developing a tiny plugin that allows people to scrub flash 
video files. I've got my plugin setup to monitor a directory /movies.
Whenever a .flv file is requested within that directory, some stuff 
should happen, if not, the request should be processed as usual. I don't 
know how to do the latter..

require 'mongrel'
require 'gem_plugin'

class Streamert < GemPlugin::Plugin "/handlers"
  include Mongrel::HttpHandlerPlugin

  def initialize(options = {})
    @docroot = options[:cwd] + "/" + options[:docroot]
  end

  def process(request, response)
   
    # only stream flv files
    unless File.extname(request.params['REQUEST_PATH']).downcase == '.flv'
        # somehow call the original process method?    
    end
...
end

How would I accomplish this?

Jeroen


From technoweenie at gmail.com  Mon Mar 12 09:24:24 2007
From: technoweenie at gmail.com (Rick Olson)
Date: Mon, 12 Mar 2007 08:24:24 -0500
Subject: [Mongrel] need help writing a plugin
In-Reply-To: <45F54BDF.7030208@supercool.nl>
References: <45F54BDF.7030208@supercool.nl>
Message-ID: <48fe25b0703120624i39bb1ca0u5567b4b8fba94955@mail.gmail.com>

On 3/12/07, Jeroen Houben <jeroen at supercool.nl> wrote:
> Hi,
>
> I'm halfway developing a tiny plugin that allows people to scrub flash
> video files. I've got my plugin setup to monitor a directory /movies.
> Whenever a .flv file is requested within that directory, some stuff
> should happen, if not, the request should be processed as usual. I don't
> know how to do the latter..

I'm pretty sure you can stack handlers.  If your handler doesn't send
a response it just goes to the next one in line.

-- 
Rick Olson
http://lighthouseapp.com
http://weblog.techno-weenie.net
http://mephistoblog.com

From zedshaw at zedshaw.com  Mon Mar 12 10:34:24 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 12 Mar 2007 10:34:24 -0400
Subject: [Mongrel] need help writing a plugin
In-Reply-To: <45F54BDF.7030208@supercool.nl>
References: <45F54BDF.7030208@supercool.nl>
Message-ID: <20070312103424.33499f2b.zedshaw@zedshaw.com>

On Mon, 12 Mar 2007 13:47:27 +0100
Jeroen Houben <jeroen at supercool.nl> wrote:

> Hi,
> 
> I'm halfway developing a tiny plugin that allows people to scrub flash 
> video files. I've got my plugin setup to monitor a directory /movies.
> Whenever a .flv file is requested within that directory, some stuff 
> should happen, if not, the request should be processed as usual. I don't 
> know how to do the latter..

Handlers are put in a chain and you can load them in front or back
(default is in back).  In your case, you want your handler to either do
the processing and then set the response to finished (see HttpResponse
docs), or simply ignore the request and let it continue.  Then, you'll
just register the handler on "/" but give the :in_front => true option.

Let me know if you need more than that.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From krisleech at interkonect.com  Mon Mar 12 13:13:20 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Mon, 12 Mar 2007 17:13:20 +0000
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <45EFEC02.8020908@interkonect.com>
References: <45EFEC02.8020908@interkonect.com>
Message-ID: <45F58A30.60506@interkonect.com>

Kris Leech wrote:
> Please note this message is not related to my previous one from 
> yesterday, this is on a different server (textdrive server).
> I have only one mongrel application running but 'randomly' it will go 
> down, the mongrel.log file shows:
>
> ERROR: undefined method 'request_uri' for #<URI::Generic:0x5383948 URL:*>
> ERROR: bad URI(is not URI?): c:\boot.ini
> [FATAL] failed to allocate memory
>
> This is on a FreeBSD server. What does the above mean please?
>   
Its bringing my server down everyday. Is there anything I can do to 
protect myself until Mongrel has the patch added?
> Mongrel 1.0.1
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>
>   



From km at acrasis.net  Mon Mar 12 13:25:00 2007
From: km at acrasis.net (km at acrasis.net)
Date: Mon, 12 Mar 2007 10:25:00 -0700
Subject: [Mongrel] Rails log file permissions
In-Reply-To: <20070309144816.4d431a38.zedshaw@zedshaw.com>
References: <20070309184831.GK4506@acrasis.net>
	<20070309144816.4d431a38.zedshaw@zedshaw.com>
Message-ID: <20070312172500.GB8001@acrasis.net>

On 2007-03-09 14:48, Zed A. Shaw wrote:
> 
> If it's configurable you'd configure it in Rails not Mongrel (since
> that log is created by Rails, not Mongrel).  Look at the documentation
> for the Logger class in Ruby, but DO NOT use Logger's rotation
> feature.  It will crash your system hard.

Thank you.  I found that adding this

   Rails::Initializer.run do |config|
      ...
      File.umask(026) if 0 == File.umask
   end

into my Rails environment.rb has the desired effect on development.log.
It has no effect on mongrel.log.  Is that log file created by Rails?

> You should also check your umask for the user that you're running as a
> daemon.

The user's umask seems not to matter because Daemonize unconditionally
clears the umask.  By editing the source (daemonize.rb line 219), it is
possible to determine what mongrel.log's permissions will be.  Hopefully
a better solution is possible?

-- 
KM

From magic_hat60622 at yahoo.com  Mon Mar 12 15:50:27 2007
From: magic_hat60622 at yahoo.com (magic hat)
Date: Mon, 12 Mar 2007 12:50:27 -0700 (PDT)
Subject: [Mongrel] setup/config issue
Message-ID: <24016.69968.qm@web60917.mail.yahoo.com>

Hey everyone. I've got my linux apache 2.0 server set up with vhost.conf to forward traffic to mongrel on port 8000. 

It's working fine in some situations, but I recently installed a rails app that is giving me all sorts of missing model and controller errors. The app works on other servers, so I'm guessing there's some sort of mongrel/rails interaction issue going on here. 

Wondering if anyone has suggestions/fixes. Here's some sample errors: 

>>      @departments = Department.find(:all)
LoadError: Expected script/../config/../config/../app/models/department.rb to define Department
        from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:249:in `load_missing_constant'
        from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:452:in `const_missing'
        from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:464:in `const_missing'
        from (irb):1

and.... 


/usr/bin/mongrel_rails:16
Expected app/controllers/store_controller.rb to define StoreController
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:249:in `load_missing_constant'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:452:in `const_missing'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:464:in `const_missing'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/inflector.rb:250:in `constantize'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/core_ext/string/inflections.rb:148:in `constantize'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/routing.rb:1284:in `recognize'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:40:in `dispatch'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:78:in `process'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76:in `process'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:618:in `process_client'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in `each'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in `process_client'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `initialize'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `new'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `initialize'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `new'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `each'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in `run'
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
/usr/bin/mongrel_rails:16:in `load'
/usr/bin/mongrel_rails:16


 
---------------------------------
 Get your own web address.
 Have a HUGE year through Yahoo! Small Business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070312/8a58b82b/attachment-0001.html 

From jeroen at supercool.nl  Mon Mar 12 17:29:04 2007
From: jeroen at supercool.nl (Jeroen Houben)
Date: Mon, 12 Mar 2007 22:29:04 +0100
Subject: [Mongrel] need help writing a plugin
In-Reply-To: <20070312103424.33499f2b.zedshaw@zedshaw.com>
References: <45F54BDF.7030208@supercool.nl>
	<20070312103424.33499f2b.zedshaw@zedshaw.com>
Message-ID: <45F5C620.8010507@supercool.nl>

Zed A. Shaw wrote:
> On Mon, 12 Mar 2007 13:47:27 +0100
> Jeroen Houben <jeroen at supercool.nl> wrote:
> 
>> Hi,
>>
>> I'm halfway developing a tiny plugin that allows people to scrub flash 
>> video files. I've got my plugin setup to monitor a directory /movies.
>> Whenever a .flv file is requested within that directory, some stuff 
>> should happen, if not, the request should be processed as usual. I don't 
>> know how to do the latter..
> 
> Handlers are put in a chain and you can load them in front or back
> (default is in back).  In your case, you want your handler to either do
> the processing and then set the response to finished (see HttpResponse
> docs), or simply ignore the request and let it continue.  Then, you'll
> just register the handler on "/" but give the :in_front => true option.
> 
> Let me know if you need more than that.
> 

Hi Zed, thanks for your reply.

Okay I understand the theory, but how do I continue? I thought simply 
returning from my process() method would do the trick, but the code 
below doesn't work, it gives a 404 for files that do exists, but are not 
flv. I just want any file that is not .flv to be served normally.

   def process(request, response)

     # only stream flv files
     if File.extname(request.params['REQUEST_PATH']).downcase == '.flv'
       puts "not a flv, so returning to the next handler on the stack"
       return
     end


Here's my config:

uri "/movies",
   :handler => plugin("/handlers/streamert"),
   :in_front => true


I'll post the whole init.rb below, just in case.

require 'mongrel'
require 'gem_plugin'

class Streamert < GemPlugin::Plugin "/handlers"
   include Mongrel::HttpHandlerPlugin

   def initialize(options = {})
     @docroot = options[:cwd] + "/" + options[:docroot]
   end

   def process(request, response)

     # only stream flv files
     if File.extname(request.params['REQUEST_PATH']).downcase == '.flv'
       puts "not a flv, so returning to the next handler on the stack"
       return
     end

     filename = @docroot + request.params['REQUEST_PATH']

     # check if file exists
     unless File.exists?(filename) && File.readable?(filename)
       response.start(404, true) do |head,out|
         out.write "Could not open file #{request.params['REQUEST_PATH']}\n"
       end
     end

     # see if an offset was given
     offset = 
Mongrel::HttpRequest.query_parse(request.params['QUERY_STRING'])['offset'].to_i
     # check for sane offset
     offset = 0 unless (0...File.size(filename)).include? offset

     begin
       response.start(200, true) do |head,out|

         head['Content-Type'] = 'video/x-flv'

         # write flv marker bytes to response stream
         if pos != 0
           out.write "FLV"
           out.write [1].pack("C")
           out.write [1].pack("C")
           out.write [9].pack("N")
           out.write [9].pack("N")
         end

         # read and output flv file optionally starting at a given offset
         File.open(filename, "rb") do |f|
           f.seek(offset)
           while (!f.eof) do
             out.write f.read(8092)
           end
         end
       end
     rescue Exception => e
       response.start(500, true) do |head,out|
         out.write "error proceessing #{request.params['REQUEST_PATH']}\n"
       end
     end

   end

end

From niall at makalumedia.com  Mon Mar 12 19:14:59 2007
From: niall at makalumedia.com (Niall O Broin)
Date: Mon, 12 Mar 2007 23:14:59 +0000
Subject: [Mongrel] Basic authentication with Apache and Mongrel
Message-ID: <8994A030-1953-41D1-8096-10CA2273FED6@makalumedia.com>

I recently moved an app. from lighttpd + fastcgi to apache 2.2 +  
mod_proxy_balancer + Mongrel. On lighttpd, I was using basic  
authentication with a configuration like this:

auth.backend = "htpasswd"
auth.backend.htpasswd.userfile = "/path/to/htpasswd"
auth.require = ("/" => ("method" => "basic", "realm" => "My Realm",  
"require" => "valid-user"))

which was nice and simple - just as simple as using basic auth. with  
a static Apache site.

Is there any way of doing such authentication with apache 2.2 +  
mod_proxy_balancer + Mongrel ? All I've been able to find with google  
suggests that I can't do this and I will require some app. level  
authentication, and I really don't want to have to do that.





Kindest regards,



Niall  O Broin



From matte at ruckuswireless.com  Mon Mar 12 20:54:07 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Mon, 12 Mar 2007 17:54:07 -0700
Subject: [Mongrel] Basic authentication with Apache and Mongrel
In-Reply-To: <8994A030-1953-41D1-8096-10CA2273FED6@makalumedia.com>
References: <8994A030-1953-41D1-8096-10CA2273FED6@makalumedia.com>
Message-ID: <45F5F62F.2090100@ruckuswireless.com>

I don't see the difference with this and a simple static apache site.  
It's still Apache in front of the proxy (as the proxy) doing the auth.  
I'm doing it.  That is if you're not involved with a complicated 
multi-server setup.

Also, if you're using Rails, you can do basic auth with the 
"simple_http_auth" plugin.  FYI.  I've used it.  It's cool.  And easier, 
IMHO, than setting up users on the server side with htpasswd, etc.  but 
be careful if you've got an open SVN repository.

matte

Niall O Broin wrote:
> I recently moved an app. from lighttpd + fastcgi to apache 2.2 +  
> mod_proxy_balancer + Mongrel. On lighttpd, I was using basic  
> authentication with a configuration like this:
>
> auth.backend = "htpasswd"
> auth.backend.htpasswd.userfile = "/path/to/htpasswd"
> auth.require = ("/" => ("method" => "basic", "realm" => "My Realm",  
> "require" => "valid-user"))
>
> which was nice and simple - just as simple as using basic auth. with  
> a static Apache site.
>
> Is there any way of doing such authentication with apache 2.2 +  
> mod_proxy_balancer + Mongrel ? All I've been able to find with google  
> suggests that I can't do this and I will require some app. level  
> authentication, and I really don't want to have to do that.
>
>   


From bill at tribley.org  Mon Mar 12 21:25:54 2007
From: bill at tribley.org (Bill Tribley)
Date: Mon, 12 Mar 2007 20:25:54 -0500
Subject: [Mongrel] Fwd: Re:  Basic authentication with Apache and Mongrel
In-Reply-To: <2007312201325.280926@billp4>
Message-ID: <2007312202554.473178@billp4>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070312/a953ffc2/attachment.html 

From jens.carroll at carroll.de  Tue Mar 13 07:18:43 2007
From: jens.carroll at carroll.de (Jens Carroll)
Date: Tue, 13 Mar 2007 12:18:43 +0100
Subject: [Mongrel] Mongrel cluster with one app and many mysql databases
Message-ID: <45F68893.4030805@carroll.de>

Hi All,

I am new to the mongrel mailing list and I have a question (and I didn't
find any answer in the archives).

I have successfully installed the apache2.2 proxy balancer with mongrel
cluster and that works just fine.

For a single rails app I have started 2 mongrels which consume about
100M (ps says 5.0% for each and I have 1G RAM). It seems a bit much but OK.
However that would imply that I can have only another 6-8 apps before I
need to upgrade RAM on my server.

In fact I only have one appl (e.g. radiant) but I want to serve many of
them with different mysql databases. So I am asking why not fire-up 10
mongrels and convince mongrel (or the app) to switch databases on
request (maybe with the rails routing facilities)

Any ideas or pointers?

The mongrel cluster thingy is really great! I love it! Good job boyz.

TIA
Jens


From alexey.verkhovsky at gmail.com  Tue Mar 13 08:02:49 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 13 Mar 2007 06:02:49 -0600
Subject: [Mongrel] Mongrel cluster with one app and many mysql databases
In-Reply-To: <45F68893.4030805@carroll.de>
References: <45F68893.4030805@carroll.de>
Message-ID: <3945c4270703130502n71155b17v6415d77bda10d417@mail.gmail.com>

> convince mongrel (or the app) to switch databases on request (maybe with
the rails routing facilities)

10 databases with the same structure but different data? This is doable.
You'd have to hack it yourself, probably by replacing ActiveRecord::
Base.connection with something that will internally hold 10 connections and
switch dynamically.

None of will have anything to do with Mongrel though. Mongrel is not a J2EE
container, it has no notion of database connections.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070313/34d56452/attachment.html 

From jens.carroll at carroll.de  Tue Mar 13 09:15:40 2007
From: jens.carroll at carroll.de (Jens Carroll)
Date: Tue, 13 Mar 2007 14:15:40 +0100
Subject: [Mongrel] Mongrel cluster with one app and many mysql databases
In-Reply-To: <3945c4270703130502n71155b17v6415d77bda10d417@mail.gmail.com>
References: <45F68893.4030805@carroll.de>
	<3945c4270703130502n71155b17v6415d77bda10d417@mail.gmail.com>
Message-ID: <45F6A3FC.4050605@carroll.de>

Thanks Alexey,

I got also more and more to the point where it is clearly not a mongrel
problem.

Thanks for the answer, but if someone has done that before I would
really appreciate any pointer.

Jens

Alexey Verkhovsky schrieb:
>> convince mongrel (or the app) to switch databases on request (maybe
> with the rails routing facilities)
> 
> 10 databases with the same structure but different data? This is doable.
> You'd have to hack it yourself, probably by replacing ActiveRecord::
> Base.connection with something that will internally hold 10 connections
> and switch dynamically.
> 
> None of will have anything to do with Mongrel though. Mongrel is not a
> J2EE container, it has no notion of database connections.
> 
> Alex
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

From mzukowski at urbacon.net  Tue Mar 13 12:32:18 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Tue, 13 Mar 2007 12:32:18 -0400
Subject: [Mongrel] Daemonizing a camping server
Message-ID: <45F6D212.3040002@urbacon.net>

I'm having no luck trying to daemonize mongrel running a camping server.

When mongrel daemonizes, I get:

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:723:in
`accept': closed stream (IOError)
        from
/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:293:in
`join'
...

(This was after I disabled the unhandled exception catchall in the
mongrel code -- otherwise it would just spew "!!!UNHANDLED EXCEPTION --
TELL ZED HE'S A MORON" ... or something to that effect).

Here's how I'm daemonizing the server. I scraped this together from the
code in mongrel_rails as well as rv:

settings = {:host => "0.0.0.0", :log_file => 'foo.log', :cwd =>
$MYSERVER_HOME}

config = Mongrel::Configurator.new settings  do
  listener :port => 12345 do
    uri '/foo', :handler => Mongrel::Camping::CampingHandler.new(CASServer)
    setup_signals
  end
  daemonize :log_file => 'foo.log', :cwd => $MYSERVER_HOME
end

config.run
config.join


The server works just fine if I comment out the "daemonize" call, but
doesn't work at all when daemonized.

Any ideas?


This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.



From public at misuse.org  Tue Mar 13 13:00:13 2007
From: public at misuse.org (Steve Midgley)
Date: Tue, 13 Mar 2007 10:00:13 -0700
Subject: [Mongrel] Mongrel cluster with one app and many mysql databases
In-Reply-To: <mailman.110.1173804418.6568.mongrel-users@rubyforge.org>
References: <mailman.110.1173804418.6568.mongrel-users@rubyforge.org>
Message-ID: <20070313170032.B95B25240BAD@rubyforge.org>

Hi,

This is getting a little OT but I think you can easily switch your 
database connections by playing with which environment you're running 
in when the rails system starts up. This doesn't get you all the way to 
your solution but should point out the line of code you'll want to 
investigate.

For example, if you were to start up 10 scratch Rails instances and had 
10 entries in your database.yml file, one for each configuration, you 
could load 10 different db instances: for each one you would provide a 
different "RAILS_ENV" environment variable (corresponding to the 
appropriate entry in database.yml). Then you'd be running 10 different 
production instances with 10 dif. connections.

What you want is a little trickier b/c you want to switch db instances 
on the fly with a single instance of Rails. But I still don't think 
this is going to be too difficult. For example, it's possible access an 
alternate database configuration entry with this line of code in the 
environment.rb file:

config.database_configuration["development"]["database"]

How and where to make the switch in an active running Rails server, I 
don't know, but it looks very plausible.

I hope this helps get you started,

Steve


At 09:46 AM 3/13/2007, mongrel-users-request at rubyforge.org wrote:
>Message: 7
>Date: Tue, 13 Mar 2007 14:15:40 +0100
>From: Jens Carroll <jens.carroll at carroll.de>
>Subject: Re: [Mongrel] Mongrel cluster with one app and many mysql
>         databases
>To: mongrel-users at rubyforge.org
>Message-ID: <45F6A3FC.4050605 at carroll.de>
>Content-Type: text/plain; charset=ISO-8859-1
>
>Thanks Alexey,
>
>I got also more and more to the point where it is clearly not a 
>mongrel
>problem.
>
>Thanks for the answer, but if someone has done that before I would
>really appreciate any pointer.
>
>Jens
>
>Alexey Verkhovsky schrieb:
> >> convince mongrel (or the app) to switch databases on request 
> (maybe
> > with the rails routing facilities)
> >
> > 10 databases with the same structure but different data? This is 
> doable.
> > You'd have to hack it yourself, probably by replacing 
> ActiveRecord::
> > Base.connection with something that will internally hold 10 
> connections
> > and switch dynamically.
> >
> > None of will have anything to do with Mongrel though. Mongrel is 
> not a
> > J2EE container, it has no notion of database connections.
> >
> > Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070313/a4aebad3/attachment.html 

From matte at ruckuswireless.com  Tue Mar 13 14:23:36 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Tue, 13 Mar 2007 11:23:36 -0700
Subject: [Mongrel] Fwd: Re: Basic authentication with Apache and Mongrel
In-Reply-To: <2007312202554.473178@billp4>
References: <2007312202554.473178@billp4>
Message-ID: <45F6EC28.1080904@ruckuswireless.com>

Well, yeah.  What I meant was that the Apache-side auth process isn't 
any different between a dynamic site and a static site.  The difference 
enters in when you need to process past apache.

Sorry for the confusion.

matte

Bill Tribley wrote:
> There is a big difference if you are not running a pure rails site. I 
> am doing auth apache-side because I serve static content, perl scripts 
> via cgi and feed the mongrel pack from Apache.
>
> The REMOTE_USER variable value can be passed to rails using a 
> technique described deep down in one of the informative pieces on the 
> Mongrel website.
>
> Bill
>
>
> On Mon, 12 Mar 2007 17:54:07 -0700, Matte Edens wrote:
> > I don't see the difference with this and a simple static apache site. 
> It's
> > still Apache in front of the proxy (as the proxy) doing the auth. I'm 
> doing
> > it.  That is if you're not involved with a complicated multi-server 
> setup.
> >
> > Also, if you're using Rails, you can do basic auth with the
> > "simple_http_auth" plugin.  FYI.  I've used it.  It's cool.  And easier,
> > IMHO, than setting up users on the server side with htpasswd, etc. 
>  but be
> > careful if you've got an open SVN repository.
> >
> > matte
> >
> > Niall O Broin wrote:
> >> I recently moved an app. from lighttpd + fastcgi to apache 2.2 +
> >> mod_proxy_balancer + Mongrel. On lighttpd, I was using basic 
> authentication
> >> with a configuration like this:
> >>
> >> auth.backend = "htpasswd"
> >> auth.backend.htpasswd.userfile = "/path/to/htpasswd"
> >> auth.require = ("/" => ("method" => "basic", "realm" => "My Realm",
> >> "require" => "valid-user"))
> >>
> >> which was nice and simple - just as simple as using basic auth. with a
> >> static Apache site.
> >>
> >> Is there any way of doing such authentication with apache 2.2 +
> >> mod_proxy_balancer + Mongrel ? All I've been able to find with google
> >> suggests that I can't do this and I will require some app. level
> >> authentication, and I really don't want to have to do that.
> >>
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users 
> <http://rubyforge.org/mailman/listinfo/mongrel-users>
> >
> > ** Classified by CRM114 SS as good **
> > CLASSIFY fails; success probability: 0.1452  pR: -0.7699
> > Best match to file #1 (nonspam.css) prob: 0.8548  pR: 0.7699 Total 
> features
> > in input file: 3653
> > #0 (spam.css): features: 1609955, hits: 159866, prob: 1.45e-01, pR: 
>  -0.77 #1
> > (nonspam.css): features: 1618666, hits: 136684, prob: 8.55e-01, pR:   
> 0.77
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20070313/d43545d9/attachment.html 

From mikeisgreat at gmail.com  Tue Mar 13 14:59:47 2007
From: mikeisgreat at gmail.com (Michael Steinfeld)
Date: Tue, 13 Mar 2007 14:59:47 -0400
Subject: [Mongrel] dropping lighty+fastcgi and moving to apache+mongrel in
	production
Message-ID: <3d5db09e0703131159o256736a4nc6342d8200d0cbb8@mail.gmail.com>

Most of my machines have apache+mongrel running but the mongrels are using
the localhost.
In my production environment, I have 4 boxes. I have setup 2 http servers (
apache 2.2.4 ) and 2 app servers. They are currently using lighttpd+fastcgi.
Which I am changing this week.
I want to get advice from you guys before I actually do this since this is
my production env.

I have installed apache on the the 2 https servers and will serve local
content in app/public on them both, but in my cluster.conf file on my
staging server I use:

BalancerMember http://localhost:port(s)

Since I have 2 app servers (separate boxes), I plan on running 10 mongrels
on each.. I am assuming I just simply use:

BalancerMember http://10.0.1.1:800*
...
BalancerMember http://10.0.1.2:800*
...

Should this be identical on both http servers?

So I would have a total of 20 entries per conf on each http server ( 10x2
mongrels for 2 app servers ).

Otherwise I am assuming the setup is the same as if they were local
mongrels. If you guys can let me know if I am on the right track here I
would appreciate it.

Regards,
-- 
-mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070313/53f83ece/attachment.html 

From rails at philip.pjkh.com  Tue Mar 13 15:31:05 2007
From: rails at philip.pjkh.com (Philip Hallstrom)
Date: Tue, 13 Mar 2007 12:31:05 -0700 (PDT)
Subject: [Mongrel] dropping lighty+fastcgi and moving to apache+mongrel
 in production
In-Reply-To: <3d5db09e0703131159o256736a4nc6342d8200d0cbb8@mail.gmail.com>
References: <3d5db09e0703131159o256736a4nc6342d8200d0cbb8@mail.gmail.com>
Message-ID: <20070313122831.Y28309@bravo.pjkh.com>

> Most of my machines have apache+mongrel running but the mongrels are using
> the localhost.
> In my production environment, I have 4 boxes. I have setup 2 http servers (
> apache 2.2.4 ) and 2 app servers. They are currently using lighttpd+fastcgi.
> Which I am changing this week.
> I want to get advice from you guys before I actually do this since this is
> my production env.
>
> I have installed apache on the the 2 https servers and will serve local
> content in app/public on them both, but in my cluster.conf file on my
> staging server I use:
>
> BalancerMember http://localhost:port(s)
>
> Since I have 2 app servers (separate boxes), I plan on running 10 mongrels
> on each.. I am assuming I just simply use:

Why 10?  Have you tested that assumption?  We found 4 mongrels to be our 
sweet spot... http://mongrel.rubyforge.org/docs/how_many_mongrels.html

Also, you might consider merging the web/app servers... we found that 
apache didn't use up that many resources serving static files so each of 
our servers runs both apache and mongrel.  So you might consider running 
apache + 4 mongrels on each of the 4 servers...

Guess I'm assuming your HTTP is behind some other load balancer...

>
> BalancerMember http://10.0.1.1:800*
> ...
> BalancerMember http://10.0.1.2:800*
> ...
>
> Should this be identical on both http servers?
>
> So I would have a total of 20 entries per conf on each http server ( 10x2
> mongrels for 2 app servers ).
>
> Otherwise I am assuming the setup is the same as if they were local
> mongrels. If you guys can let me know if I am on the right track here I
> would appreciate it.
>
> Regards,
> -- 
> -mike
>

From jjhogue at sbcglobal.net  Tue Mar 13 15:27:20 2007
From: jjhogue at sbcglobal.net (Jim Hogue)
Date: Tue, 13 Mar 2007 15:27:20 -0400
Subject: [Mongrel] Mongrel cluster with one app and many mysql databases
References: <mailman.110.1173804418.6568.mongrel-users@rubyforge.org>
	<20070313170032.B95B25240BAD@rubyforge.org>
Message-ID: <00f201c765a5$9f355430$0400a8c0@DEN2>

I just got a copy of "Rails Recipes" and I see in the index

    15. Connecting to Multiple Databases

I literally just got the book, so I can't give you any details, but 
this might help get you to a solution.

Note that the OT comment is probably correct as it is Rails, not 
Mongrel that deals with the database.  You may want to try the Rails 
mailing list archives.

    - Jim

----- Original Message ----- 
From: "Steve Midgley" <public at misuse.org>
To: <mongrel-users at rubyforge.org>
Sent: Tuesday, March 13, 2007 1:00 PM
Subject: Re: [Mongrel] Mongrel cluster with one app and many mysql 
databases


> Hi,
>
> This is getting a little OT but I think you can easily switch your
> database connections by playing with which environment you're 
> running
> in when the rails system starts up. This doesn't get you all the way 
> to
> your solution but should point out the line of code you'll want to
> investigate.
>
> For example, if you were to start up 10 scratch Rails instances and 
> had
> 10 entries in your database.yml file, one for each configuration, 
> you
> could load 10 different db instances: for each one you would provide 
> a
> different "RAILS_ENV" environment variable (corresponding to the
> appropriate entry in database.yml). Then you'd be running 10 
> different
> production instances with 10 dif. connections.
>
> What you want is a little trickier b/c you want to switch db 
> instances
> on the fly with a single instance of Rails. But I still don't think
> this is going to be too difficult. For example, it's possible access 
> an
> alternate database configuration entry with this line of code in the
> environment.rb file:
>
> config.database_configuration["development"]["database"]
>
> How and where to make the switch in an active running Rails server, 
> I
> don't know, but it looks very plausible.
>
> I hope this helps get you started,
>
> Steve
>
>
> At 09:46 AM 3/13/2007, mongrel-users-request at rubyforge.org wrote:
>>Message: 7
>>Date: Tue, 13 Mar 2007 14:15:40 +0100
>>From: Jens Carroll <jens.carroll at carroll.de>
>>Subject: Re: [Mongrel] Mongrel cluster with one app and many mysql
>>         databases
>>To: mongrel-users at rubyforge.org
>>Message-ID: <45F6A3FC.4050605 at carroll.de>
>>Content-Type: text/plain; charset=ISO-8859-1
>>
>>Thanks Alexey,
>>
>>I got also more and more to the point where it is clearly not a
>>mongrel
>>problem.
>>
>>Thanks for the answer, but if someone has done that before I would
>>really appreciate any pointer.
>>
>>Jens
>>
>>Alexey Verkhovsky schrieb:
>> >> convince mongrel (or the app) to switch databases on request
>> (maybe
>> > with the rails routing facilities)
>> >
>> > 10 databases with the same structure but different data? This is
>> doable.
>> > You'd have to hack it yourself, probably by replacing
>> ActiveRecord::
>> > Base.connection with something that will internally hold 10
>> connections
>> > and switch dynamically.
>> >
>> > None of will have anything to do with Mongrel though. Mongrel is
>> not a
>> > J2EE container, it has no notion of database connections.
>> >
>> > Alex
>


--------------------------------------------------------------------------------


> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users 



From mikeisgreat at gmail.com  Tue Mar 13 15:40:45 2007
From: mikeisgreat at gmail.com (Michael Steinfeld)
Date: Tue, 13 Mar 2007 15:40:45 -0400
Subject: [Mongrel] dropping lighty+fastcgi and moving to apache+mongrel
	in production
In-Reply-To: <20070313122831.Y28309@bravo.pjkh.com>
References: <3d5db09e0703131159o256736a4nc6342d8200d0cbb8@mail.gmail.com>
	<20070313122831.Y28309@bravo.pjkh.com>
Message-ID: <3d5db09e0703131240s7c07bd89o9e2065e0cb41bfb3@mail.gmail.com>

Hi --

On 3/13/07, Philip Hallstrom <rails at philip.pjkh.com> wrote:
>
> > Most of my machines have apache+mongrel running but the mongrels are
> using
> > the localhost.
> > In my production environment, I have 4 boxes. I have setup 2 http
> servers (
> > apache 2.2.4 ) and 2 app servers. They are currently using
> lighttpd+fastcgi.
> > Which I am changing this week.
> > I want to get advice from you guys before I actually do this since this
> is
> > my production env.
> >
> > I have installed apache on the the 2 https servers and will serve local
> > content in app/public on them both, but in my cluster.conf file on my
> > staging server I use:
> >
> > BalancerMember http://localhost:port(s)
> >
> > Since I have 2 app servers (separate boxes), I plan on running 10
> mongrels
> > on each.. I am assuming I just simply use:
>
> Why 10?  Have you tested that assumption?  We found 4 mongrels to be our
> sweet spot... http://mongrel.rubyforge.org/docs/how_many_mongrels.html


Well, Someone else on the team had previously set up 10 so that is what I
was assuming to go with here. I will read the link you just gave me. Thanks
you!



Also, you might consider merging the web/app servers... we found that
> apache didn't use up that many resources serving static files so each of
> our servers runs both apache and mongrel.  So you might consider running
> apache + 4 mongrels on each of the 4 servers...


I did think of that and suggested it to the CIO. I was wondering why we
would go 2 and 2 when 4 and 4 gives us the performance and redundancy, I am
pondering your suggestions whole heartedly. Just a note I have been a *nix
admin for roughly 8 years but this is my first Rails production environment.
So I don't have much experience. Your feedback is more than helpful.



Guess I'm assuming your HTTP is behind some other load balancer...


Interestingly enough we don't. In many of the other networks we did have HW
for load balancing. This environment is using round robin dns, though this
is my first encounter with using round robin to handle the load balancing
needs as well. I am open to any suggestions you may have in regards to the
direction we should investigate. Right now there are 4 machines but soon
that may double. So I am thinking of both short-term and long-term needs
right now. Anything else you have to offer would be appreciated.

Thanks

>
> > BalancerMember http://10.0.1.1:800*
> > ...
> > BalancerMember http://10.0.1.2:800*
> > ...
> >
> > Should this be identical on both http servers?
> >
> > So I would have a total of 20 entries per conf on each http server (
> 10x2
> > mongrels for 2 app servers ).
> >
> > Otherwise I am assuming the setup is the same as if they were local
> > mongrels. If you guys can let me know if I am on the right track here I
> > would appreciate it.
> >
> > Regards,
> > --
> > -mike
> >
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
-mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070313/2a53f32a/attachment.html 

From rails at philip.pjkh.com  Tue Mar 13 16:18:05 2007
From: rails at philip.pjkh.com (Philip Hallstrom)
Date: Tue, 13 Mar 2007 13:18:05 -0700 (PDT)
Subject: [Mongrel] dropping lighty+fastcgi and moving to apache+mongrel
 in production
In-Reply-To: <3d5db09e0703131240s7c07bd89o9e2065e0cb41bfb3@mail.gmail.com>
References: <3d5db09e0703131159o256736a4nc6342d8200d0cbb8@mail.gmail.com>
	<20070313122831.Y28309@bravo.pjkh.com>
	<3d5db09e0703131240s7c07bd89o9e2065e0cb41bfb3@mail.gmail.com>
Message-ID: <20070313131418.T28309@bravo.pjkh.com>

>> > Since I have 2 app servers (separate boxes), I plan on running 10
>> mongrels
>> > on each.. I am assuming I just simply use:
>> 
>> Why 10?  Have you tested that assumption?  We found 4 mongrels to be our
>> sweet spot... http://mongrel.rubyforge.org/docs/how_many_mongrels.html
>
> Well, Someone else on the team had previously set up 10 so that is what I
> was assuming to go with here. I will read the link you just gave me. Thanks
> you!

Yeah, definitely go through the steps in that URL.  We had been running 20 
FCGI's then went to 8 mongrels I believe then Zed posted those docs and 
when we tested we found 4 to be ideal.  Seems counter intuitive, but there 
ya go :)

> Also, you might consider merging the web/app servers... we found that
>> apache didn't use up that many resources serving static files so each of
>> our servers runs both apache and mongrel.  So you might consider running
>> apache + 4 mongrels on each of the 4 servers...
>
> I did think of that and suggested it to the CIO. I was wondering why we
> would go 2 and 2 when 4 and 4 gives us the performance and redundancy, I am
> pondering your suggestions whole heartedly. Just a note I have been a *nix
> admin for roughly 8 years but this is my first Rails production environment.
> So I don't have much experience. Your feedback is more than helpful.

I suppose it depends on how hard your apache servers are working.  Ours 
don't work that hard at all so we'd rather rails had access to more 
ram/cpu...

> Guess I'm assuming your HTTP is behind some other load balancer...
>
> Interestingly enough we don't. In many of the other networks we did have HW
> for load balancing. This environment is using round robin dns, though this
> is my first encounter with using round robin to handle the load balancing
> needs as well. I am open to any suggestions you may have in regards to the
> direction we should investigate. Right now there are 4 machines but soon
> that may double. So I am thinking of both short-term and long-term needs
> right now. Anything else you have to offer would be appreciated.

Hrm.  I think I would.  The problem with round robin is how long the cycle 
is... if it's too long and you get slashdotted (for example) won't all 
those new users end up on a single web server?

I didn't set it up, but I like the load balancer we've got since it lets 
us disable a backend and we can take it offline and do whatever we want 
with it and bring it back up, etc...

I haven't used it, but a lot of people really seem to like HAproxy as a 
software solution.  Might be worth investigating as well.

-p

From rsanheim at gmail.com  Tue Mar 13 20:11:33 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Tue, 13 Mar 2007 19:11:33 -0500
Subject: [Mongrel] ruby 1.8.6 includes fastthread?
Message-ID: <fc113d400703131711m2bea203ejfc4ce0fd8e21f4ae@mail.gmail.com>

It looks like fastthread was rolled into 1.8.6:

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/tags/v1_8_6/NEWS?revision=12055&view=markup

Does that mean once we upgrade to 186 we can forget about rubygem version?

- Rob

From luislavena at gmail.com  Tue Mar 13 20:28:32 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 13 Mar 2007 21:28:32 -0300
Subject: [Mongrel] ruby 1.8.6 includes fastthread?
In-Reply-To: <fc113d400703131711m2bea203ejfc4ce0fd8e21f4ae@mail.gmail.com>
References: <fc113d400703131711m2bea203ejfc4ce0fd8e21f4ae@mail.gmail.com>
Message-ID: <71166b3b0703131728u418377eck59ee77d69afe2ae8@mail.gmail.com>

On 3/13/07, Rob Sanheim <rsanheim at gmail.com> wrote:
> It looks like fastthread was rolled into 1.8.6:
>
> http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/tags/v1_8_6/NEWS?revision=12055&view=markup
>
> Does that mean once we upgrade to 186 we can forget about rubygem version?
>

Yep, guess next mongrel release will force 1.8.6, dropping
cgi_multipart_eof_fix and fastthread. (or at least, hope so, provide
support for every weird setup of gems, ruby installations and gems is
a hell, worse than dll hell on windows).

Also some good news in the win32 front, but will investigate this
weekend about VC8 performance against stock 1.8.6 (which guess will be
VC6).

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From michel at wolfstar.ca  Tue Mar 13 19:36:21 2007
From: michel at wolfstar.ca (Michel Vaillancourt)
Date: Tue, 13 Mar 2007 18:36:21 -0500
Subject: [Mongrel] Getting Started without Rails
Message-ID: <45F73575.10005@wolfstar.ca>

	
	Hi, everyone.  I am in the process of learning Ruby.  I've concluded that there are couple of quirks with mod_ruby that are limiting me a fair bit, so I'm looking for an alternative.  From what I've read, Mongrel is The Answer.  However, this has left me with a few questions.

	I'm looking for some help getting a non-rails Mongrel started...  I can't seem to find the docs I need in my web searching...  specifically need something that explains what files Mongrel expects to see where for a non-rails app to work.  Everything I have found is written on the premise of Mongrel with Rails (eg, http://mongrel.rubyforge.org/rdoc/index.html).
	
ext2:/home/www/ruby/cosmogenesis# mongrel_rails start
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- /home/www/ruby/cosmogenesis/config/environment (LoadError)
        from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:155:in `rails'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:112:in `cloaker_'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:138:in `call'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:138:in `listener'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:98:in `cloaker_'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:51:in `call'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:51:in `initialize'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:83:in `new'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:83:in `run'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in `run'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
        from /usr/bin/mongrel_rails:16:in `load'
        from /usr/bin/mongrel_rails:16

	... its pretty obvious that Mongrel is expecting to find some key files with Important Stuff in them, but I can't seem to find info on where/what.  Can someone point me at a how-to or docs that explain what files are needed with what contents?

	Thanks in advance for any and all help.

	--Michel

From chris at oxdi.eu  Wed Mar 14 07:44:14 2007
From: chris at oxdi.eu (Chris Farmiloe)
Date: Wed, 14 Mar 2007 11:44:14 +0000
Subject: [Mongrel] Getting Started without Rails
In-Reply-To: <45F73575.10005@wolfstar.ca>
References: <45F73575.10005@wolfstar.ca>
Message-ID: <07DF45FF-4EDE-4E38-A31C-0A8CE7329378@oxdi.eu>

Hey Michel:

$ mongrel_rails start

is a command specifically for launching rails apps.

if you want to use mongrel as the server for your own framework/ 
application, then take a quick look at the example (examples/ 
simpletest.rb).

http://mongrel.rubyforge.org/rdoc/

using mongrel for your ruby apps is a slightly different approch if  
your used to cgi-gateways ... but it is infinitely more flexible,  
since you have Ruby-based control over the whole request/response  
process....

write yourself a little Handler class to take the request -> call  
your methods -> modify the response.

I think there is a short mongrel book on O'Reily safari online if you  
have an account.

Otherwise, the examples in the source are very helpful .... checkout  
how the Camping framework uses mongrel (as this is quite simple).


I am assuming here that by non-rails...you still meen a Ruby app ...  
I've yet to see anyone launching a PHP app via mongrel :)






Regards.

Chris Farmiloe
Design & Development


Oxygen
Brighton, BN2 1ED


+44 1273 608708
http://www.oxdi.eu



On 13 Mar 2007, at 23:36, Michel Vaillancourt wrote:

> 	
> 	Hi, everyone.  I am in the process of learning Ruby.  I've  
> concluded that there are couple of quirks with mod_ruby that are  
> limiting me a fair bit, so I'm looking for an alternative.  From  
> what I've read, Mongrel is The Answer.  However, this has left me  
> with a few questions.
>
> 	I'm looking for some help getting a non-rails Mongrel started...   
> I can't seem to find the docs I need in my web searching...   
> specifically need something that explains what files Mongrel  
> expects to see where for a non-rails app to work.  Everything I  
> have found is written on the premise of Mongrel with Rails (eg,  
> http://mongrel.rubyforge.org/rdoc/index.html).
> 	
> ext2:/home/www/ruby/cosmogenesis# mongrel_rails start
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Starting Rails with development environment...
> /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in  
> `gem_original_require': no such file to load -- /home/www/ruby/ 
> cosmogenesis/config/environment (LoadError)
>         from /usr/local/lib/site_ruby/1.8/rubygems/ 
> custom_require.rb:27:in `require'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ 
> rails.rb:155:in `rails'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:112:in `cloaker_'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ 
> configurator.rb:138:in `call'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ 
> configurator.rb:138:in `listener'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:98:in `cloaker_'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ 
> configurator.rb:51:in `call'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ 
> configurator.rb:51:in `initialize'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:83:in `new'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:83:in `run'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ 
> command.rb:211:in `run'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:243
>         from /usr/bin/mongrel_rails:16:in `load'
>         from /usr/bin/mongrel_rails:16
>
> 	... its pretty obvious that Mongrel is expecting to find some key  
> files with Important Stuff in them, but I can't seem to find info  
> on where/what.  Can someone point me at a how-to or docs that  
> explain what files are needed with what contents?
>
> 	Thanks in advance for any and all help.
>
> 	--Michel
> _______________________________________________
> 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/20070314/b951bfe4/attachment-0001.html 

From eden at mojiti.com  Wed Mar 14 08:08:18 2007
From: eden at mojiti.com (Eden Li)
Date: Wed, 14 Mar 2007 20:08:18 +0800
Subject: [Mongrel] Getting Started without Rails
In-Reply-To: <45F73575.10005@wolfstar.ca>
References: <45F73575.10005@wolfstar.ca>
Message-ID: <1dd361e10703140508q167059c8qc905fea5b7e9c46f@mail.gmail.com>

You probably don't want to use 'mongrel_rails' if you don't want to use rails.

Instead, you should probably write some handlers and write a
configurator script that brings them all together.  The docs on both
are located at http://mongrel.rubyforge.org/rdoc/index.html.

An example is included with mongrel:

  /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/examples/simpletest.rb

On 3/14/07, Michel Vaillancourt <michel at wolfstar.ca> wrote:
>
>         Hi, everyone.  I am in the process of learning Ruby.  I've concluded that there are couple of quirks with mod_ruby that are limiting me a fair bit, so I'm looking for an alternative.  From what I've read, Mongrel is The Answer.  However, this has left me with a few questions.
>
>         I'm looking for some help getting a non-rails Mongrel started...  I can't seem to find the docs I need in my web searching...  specifically need something that explains what files Mongrel expects to see where for a non-rails app to work.  Everything I have found is written on the premise of Mongrel with Rails (eg, http://mongrel.rubyforge.org/rdoc/index.html).
>
> ext2:/home/www/ruby/cosmogenesis# mongrel_rails start
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Starting Rails with development environment...
> /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- /home/www/ruby/cosmogenesis/config/environment (LoadError)
>         from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:155:in `rails'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:112:in `cloaker_'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:138:in `call'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:138:in `listener'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:98:in `cloaker_'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:51:in `call'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:51:in `initialize'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:83:in `new'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:83:in `run'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in `run'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
>         from /usr/bin/mongrel_rails:16:in `load'
>         from /usr/bin/mongrel_rails:16
>
>         ... its pretty obvious that Mongrel is expecting to find some key files with Important Stuff in them, but I can't seem to find info on where/what.  Can someone point me at a how-to or docs that explain what files are needed with what contents?
>
>         Thanks in advance for any and all help.
>
>         --Michel
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From johan at johansorensen.com  Wed Mar 14 07:45:16 2007
From: johan at johansorensen.com (=?ISO-8859-1?Q?Johan_S=F8rensen?=)
Date: Wed, 14 Mar 2007 12:45:16 +0100
Subject: [Mongrel] Getting Started without Rails
In-Reply-To: <45F73575.10005@wolfstar.ca>
References: <45F73575.10005@wolfstar.ca>
Message-ID: <547176FA-4C46-4C1E-8318-C49A9F97010A@johansorensen.com>

Hi,

On Mar 14, 2007, at 12:36 AM, Michel Vaillancourt wrote:

> 	I'm looking for some help getting a non-rails Mongrel started...   
> I can't seem to find the docs I need in my web searching...   
> specifically need something that explains what files Mongrel  
> expects to see where for a non-rails app to work.  Everything I  
> have found is written on the premise of Mongrel with Rails (eg,  
> http://mongrel.rubyforge.org/rdoc/index.html).
> 	
> ext2:/home/www/ruby/cosmogenesis# mongrel_rails start
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Starting Rails with development environment...
> /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in  
> `gem_original_require': no such file to load -- /home/www/ruby/ 
> cosmogenesis/config/environment (LoadError)

Looks like you _are_ trying to use the rails handler for your non- 
rails app. Your first step is to make your own mongrel handler for  
your app. Looking at the handlers in the mongrel source (and mongrel  
in general; reading the source is the easiest way to understand how  
it works), and other frameworks like rails, merb, camping & nitro is  
a good start.

I'd also suggest looking into rack (http://rack.rubyforge.org/) for  
handling all those boring details.

JS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070314/76769e89/attachment.html 

From michel at wolfstar.ca  Wed Mar 14 09:39:46 2007
From: michel at wolfstar.ca (Michel R Vaillancourt)
Date: Wed, 14 Mar 2007 09:39:46 -0400
Subject: [Mongrel] Getting Started without Rails
In-Reply-To: <1dd361e10703140508q167059c8qc905fea5b7e9c46f@mail.gmail.com>
References: <45F73575.10005@wolfstar.ca>
	<1dd361e10703140508q167059c8qc905fea5b7e9c46f@mail.gmail.com>
Message-ID: <45F7FB22.1070601@wolfstar.ca>


	Thanks to everyone for your suggestions.  I'll go do some more reading.  :)

	--Michel

From wyhaines at gmail.com  Wed Mar 14 10:42:25 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 14 Mar 2007 07:42:25 -0700
Subject: [Mongrel] Getting Started without Rails
In-Reply-To: <45F7FB22.1070601@wolfstar.ca>
References: <45F73575.10005@wolfstar.ca>
	<1dd361e10703140508q167059c8qc905fea5b7e9c46f@mail.gmail.com>
	<45F7FB22.1070601@wolfstar.ca>
Message-ID: <f4cd26df0703140742m51639980p7ae11c399dbace02@mail.gmail.com>

On 3/14/07, Michel R Vaillancourt <michel at wolfstar.ca> wrote:
>
>        Thanks to everyone for your suggestions.  I'll go do some more reading.  :)

If you want a thin, easy layer on Mongrel for writing an app, take a
look at Rack.

rack.rubyforge.org


Kirk Haines

From jens.carroll at carroll.de  Wed Mar 14 10:51:36 2007
From: jens.carroll at carroll.de (Jens Carroll)
Date: Wed, 14 Mar 2007 15:51:36 +0100
Subject: [Mongrel] Mongrel cluster with one app and many mysql databases
In-Reply-To: <00f201c765a5$9f355430$0400a8c0@DEN2>
References: <mailman.110.1173804418.6568.mongrel-users@rubyforge.org>	<20070313170032.B95B25240BAD@rubyforge.org>
	<00f201c765a5$9f355430$0400a8c0@DEN2>
Message-ID: <45F80BF8.9090702@carroll.de>

Thanks guys! That should keep me busy.

Have fun
Jens

Jim Hogue schrieb:
> I just got a copy of "Rails Recipes" and I see in the index
> 
>     15. Connecting to Multiple Databases
> 
> I literally just got the book, so I can't give you any details, but 
> this might help get you to a solution.
> 
> Note that the OT comment is probably correct as it is Rails, not 
> Mongrel that deals with the database.  You may want to try the Rails 
> mailing list archives.
> 
>     - Jim
> 
> ----- Original Message ----- 
> From: "Steve Midgley" <public at misuse.org>
> To: <mongrel-users at rubyforge.org>
> Sent: Tuesday, March 13, 2007 1:00 PM
> Subject: Re: [Mongrel] Mongrel cluster with one app and many mysql 
> databases
> 
> 
>> Hi,
>>
>> This is getting a little OT but I think you can easily switch your
>> database connections by playing with which environment you're 
>> running
>> in when the rails system starts up. This doesn't get you all the way 
>> to
>> your solution but should point out the line of code you'll want to
>> investigate.
>>
>> For example, if you were to start up 10 scratch Rails instances and 
>> had
>> 10 entries in your database.yml file, one for each configuration, 
>> you
>> could load 10 different db instances: for each one you would provide 
>> a
>> different "RAILS_ENV" environment variable (corresponding to the
>> appropriate entry in database.yml). Then you'd be running 10 
>> different
>> production instances with 10 dif. connections.
>>
>> What you want is a little trickier b/c you want to switch db 
>> instances
>> on the fly with a single instance of Rails. But I still don't think
>> this is going to be too difficult. For example, it's possible access 
>> an
>> alternate database configuration entry with this line of code in the
>> environment.rb file:
>>
>> config.database_configuration["development"]["database"]
>>
>> How and where to make the switch in an active running Rails server, 
>> I
>> don't know, but it looks very plausible.
>>
>> I hope this helps get you started,
>>
>> Steve
>>
>>
>> At 09:46 AM 3/13/2007, mongrel-users-request at rubyforge.org wrote:
>>> Message: 7
>>> Date: Tue, 13 Mar 2007 14:15:40 +0100
>>> From: Jens Carroll <jens.carroll at carroll.de>
>>> Subject: Re: [Mongrel] Mongrel cluster with one app and many mysql
>>>         databases
>>> To: mongrel-users at rubyforge.org
>>> Message-ID: <45F6A3FC.4050605 at carroll.de>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> Thanks Alexey,
>>>
>>> I got also more and more to the point where it is clearly not a
>>> mongrel
>>> problem.
>>>
>>> Thanks for the answer, but if someone has done that before I would
>>> really appreciate any pointer.
>>>
>>> Jens
>>>
>>> Alexey Verkhovsky schrieb:
>>>>> convince mongrel (or the app) to switch databases on request
>>> (maybe
>>>> with the rails routing facilities)
>>>>
>>>> 10 databases with the same structure but different data? This is
>>> doable.
>>>> You'd have to hack it yourself, probably by replacing
>>> ActiveRecord::
>>>> Base.connection with something that will internally hold 10
>>> connections
>>>> and switch dynamically.
>>>>
>>>> None of will have anything to do with Mongrel though. Mongrel is
>>> not a
>>>> J2EE container, it has no notion of database connections.
>>>>
>>>> Alex
> 
> 
> --------------------------------------------------------------------------------
> 
> 
>> _______________________________________________
>> 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
> 


-- 
Carroll Engineering
Dipl.-Ing. Jens Carroll
Neuk?llnerstr. 2
D-71229 Leonberg, Germany

Phone: +49 (0)7152 929053
FAX:   +49 (0)7152 929054


From mzukowski at urbacon.net  Wed Mar 14 11:23:41 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Wed, 14 Mar 2007 11:23:41 -0400
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <45F6D212.3040002@urbacon.net>
References: <45F6D212.3040002@urbacon.net>
Message-ID: <45F8137D.2090707@urbacon.net>

I didn't get any responses to my previous post about this, so I figure
maybe I'm not explaining myself clearly enough. My problem is fairly
simple. I'm trying to run a Camping server as a background (daemon)
process. I'm using Mongrel configurator's "daemonize()" method to do
this. However, when I daemonize the server, I got a huge spew of:

!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.

See below for details on what I'm doing, how I'm doing it, and what I
think is the culprit (hint: IOError in mongrel.rb line 723).

Thanks,
Matt.

Matt Zukowski wrote:
> I'm having no luck trying to daemonize mongrel running a camping server.
> 
> When mongrel daemonizes, I get:
> 
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:723:in
> `accept': closed stream (IOError)
>         from
> /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:293:in
> `join'
> ...
> 
> (This was after I disabled the unhandled exception catchall in the
> mongrel code -- otherwise it would just spew "!!!UNHANDLED EXCEPTION --
> TELL ZED HE'S A MORON" ... or something to that effect).
> 
> Here's how I'm daemonizing the server. I scraped this together from the
> code in mongrel_rails as well as rv:
> 
> settings = {:host => "0.0.0.0", :log_file => 'foo.log', :cwd =>
> $MYSERVER_HOME}
> 
> config = Mongrel::Configurator.new settings  do
>   listener :port => 12345 do
>     uri '/foo', :handler => Mongrel::Camping::CampingHandler.new(CASServer)
>     setup_signals
>   end
>   daemonize :log_file => 'foo.log', :cwd => $MYSERVER_HOME
> end
> 
> config.run
> config.join
> 
> 
> The server works just fine if I comment out the "daemonize" call, but
> doesn't work at all when daemonized.
> 
> Any ideas?
> 
> 
> This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.
> 
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From rubyforge at aanet.com.au  Wed Mar 14 18:13:39 2007
From: rubyforge at aanet.com.au (rubyforge at aanet.com.au)
Date: Thu, 15 Mar 2007 08:13:39 +1000 (EST)
Subject: [Mongrel] Fastthread memory leak?
Message-ID: <43100.57.70.22.34.1173910419.squirrel@mail.aanet.com.au>

Hi All,

I have an app making extensive use of Mutex and was concerned about the
memory leak I have read about.  I saw some sample code to reproduce the
problem here: http://pastie.caboo.se/10194

So I thought I would run it myself to see the problem.

I do not see a memory leak when using the sample code, but if I require
"fastthread" before "thread" using fastthread (0.6.4.1) then I see the app
bleeding memory.

Here is the output from that program linked above (with time added in):

Using require "thread"
Max memory: 76.1 mb - climbed then stabilised after first "waiting" message
Output:
Starting threads
waiting for 1000 threads
waiting for 713 threads
waiting for 407 threads
waiting for 34 threads
Threads gone.
67 seconds

Using require "fastthread"; require "thread"
Max memory: 163 mb - continued to climb, never stopped
Output:
Starting threads
waiting for 1000 threads
waiting for 750 threads
waiting for 476 threads
waiting for 226 threads
Threads gone.
65 seconds

Using require "thread"; require "sync"
Max memory: 28 mb - climbed then stabilised after first "waiting" message
Output:
Starting threads
waiting for 1000 threads
waiting for 791 threads
waiting for 511 threads
waiting for 204 threads
Threads gone.
70 seconds

Interestingly I cannot reproduce this in Windows.

I have Linux (FC5), Ruby 1.8.5, fastthread (0.6.4.1).

Anyone have any suggestions?

Also, should I be posting this elsewhere?

Thanks,
Jason



From mental at rydia.net  Wed Mar 14 21:01:38 2007
From: mental at rydia.net (MenTaLguY)
Date: Wed, 14 Mar 2007 18:01:38 -0700
Subject: [Mongrel] Fastthread memory leak?
In-Reply-To: <43100.57.70.22.34.1173910419.squirrel@mail.aanet.com.au>
References: <43100.57.70.22.34.1173910419.squirrel@mail.aanet.com.au>
Message-ID: <f59015b9cfd2db5676e0070ed5083a7a@localhost>

Try setting $fastthread_avoid_mem_pools = true at the top of your program before you require either thread or fastthread, and see if it makes a difference for you.

-mental


From abstractryan at gmail.com  Wed Mar 14 21:42:17 2007
From: abstractryan at gmail.com (Ryan)
Date: Wed, 14 Mar 2007 20:42:17 -0500
Subject: [Mongrel] Issues with mongrel PID files when restarting clusters
	with Capistrano
Message-ID: <45F8A479.6000401@gmail.com>

Hey all:

When using capistrano and/or manually restarting mongrel clusters we 
encounter errors when restarting that states:

** !!! PID file log/mongrel.8010.pid already exists.  Mongrel could be 
running already.  Check your log/mongrel.log for errors.
** !!! Exiting with error.  You must stop mongrel and clear the .pid 
before I'll attempt a start.
** !!! PID file log/mongrel.8011.pid already exists.  Mongrel could be 
running already.  Check your log/mongrel.log for errors.
** !!! Exiting with error.  You must stop mongrel and clear the .pid 
before I'll attempt a start.
** !!! PID file log/mongrel.8012.pid already exists.  Mongrel could be 
running already.  Check your log/mongrel.log for errors.
** !!! Exiting with error.  You must stop mongrel and clear the .pid 
before I'll attempt a start.

I then manually have to kill the processes, and if the pids are there, I 
clean them out and restart without issue. However this only happens 
intermittently. Both the server processes and the pid files are owned by 
the mongrel user.

thanks for any insight.
Ryan


From rsanheim at gmail.com  Wed Mar 14 22:07:17 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 14 Mar 2007 21:07:17 -0500
Subject: [Mongrel] Issues with mongrel PID files when restarting
	clusters with Capistrano
In-Reply-To: <45F8A479.6000401@gmail.com>
References: <45F8A479.6000401@gmail.com>
Message-ID: <fc113d400703141907oa07dd0bo1e9d3009854997b4@mail.gmail.com>

You need the latest prerelease of mongrel, which has an option to blow
away dead PIDs.  Search the archives of this group, it was recently
announced.

On 3/14/07, Ryan <abstractryan at gmail.com> wrote:
> Hey all:
>
> When using capistrano and/or manually restarting mongrel clusters we
> encounter errors when restarting that states:
>
> ** !!! PID file log/mongrel.8010.pid already exists.  Mongrel could be
> running already.  Check your log/mongrel.log for errors.
> ** !!! Exiting with error.  You must stop mongrel and clear the .pid
> before I'll attempt a start.
> ** !!! PID file log/mongrel.8011.pid already exists.  Mongrel could be
> running already.  Check your log/mongrel.log for errors.
> ** !!! Exiting with error.  You must stop mongrel and clear the .pid
> before I'll attempt a start.
> ** !!! PID file log/mongrel.8012.pid already exists.  Mongrel could be
> running already.  Check your log/mongrel.log for errors.
> ** !!! Exiting with error.  You must stop mongrel and clear the .pid
> before I'll attempt a start.
>
> I then manually have to kill the processes, and if the pids are there, I
> clean them out and restart without issue. However this only happens
> intermittently. Both the server processes and the pid files are owned by
> the mongrel user.
>
> thanks for any insight.
> Ryan
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From rubyforge at aanet.com.au  Wed Mar 14 23:14:57 2007
From: rubyforge at aanet.com.au (rubyforge at aanet.com.au)
Date: Thu, 15 Mar 2007 13:14:57 +1000 (EST)
Subject: [Mongrel] Fastthread memory leak?
In-Reply-To: <f59015b9cfd2db5676e0070ed5083a7a@localhost>
References: <43100.57.70.22.34.1173910419.squirrel@mail.aanet.com.au>
	<f59015b9cfd2db5676e0070ed5083a7a@localhost>
Message-ID: <6780.57.70.22.34.1173928497.squirrel@mail.aanet.com.au>

Thanks.  Tried that but no luck.

It took 89 seconds this time and consumed 189 mb.  The memory continued to
climb.

Any ideas?

> Try setting $fastthread_avoid_mem_pools = true at the top of your program
> before you require either thread or fastthread, and see if it makes a
> difference for you.
>
> -mental
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



From zedshaw at zedshaw.com  Thu Mar 15 05:59:12 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 15 Mar 2007 05:59:12 -0400
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <45F8137D.2090707@urbacon.net>
References: <45F6D212.3040002@urbacon.net>
	<45F8137D.2090707@urbacon.net>
Message-ID: <20070315055912.36c9d1b9.zedshaw@zedshaw.com>

On Wed, 14 Mar 2007 11:23:41 -0400
Matt Zukowski <mzukowski at urbacon.net> wrote:

> I didn't get any responses to my previous post about this, so I figure
> maybe I'm not explaining myself clearly enough. My problem is fairly
> simple. I'm trying to run a Camping server as a background (daemon)
> process. I'm using Mongrel configurator's "daemonize()" method to do
> this. However, when I daemonize the server, I got a huge spew of:

Sorry Matt, I've been travelling a lot lately and missed this.
 
> !!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.

It says tell ZED not the mongrel-users mailing list. :-)

Anyway, the exception is a weird one since it's saying that you've
opened this port and then it's closed right away.  You'll have to give
me sample code and the platform information so I can replicate it
better.  I'm thinking it might be something strange about this platform
when a client closes right at the accept point.


-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From jeroen at supercool.nl  Thu Mar 15 08:49:21 2007
From: jeroen at supercool.nl (Jeroen Houben)
Date: Thu, 15 Mar 2007 13:49:21 +0100
Subject: [Mongrel] need help writing a plugin - Still hoping for an answer
 :-)
In-Reply-To: <45F5C620.8010507@supercool.nl>
References: <45F54BDF.7030208@supercool.nl>	<20070312103424.33499f2b.zedshaw@zedshaw.com>
	<45F5C620.8010507@supercool.nl>
Message-ID: <45F940D1.4060002@supercool.nl>

Jeroen Houben wrote:
> Zed A. Shaw wrote:
>   
>> On Mon, 12 Mar 2007 13:47:27 +0100
>> Jeroen Houben <jeroen at supercool.nl> wrote:
>>
>>     
>>> Hi,
>>>
>>> I'm halfway developing a tiny plugin that allows people to scrub flash 
>>> video files. I've got my plugin setup to monitor a directory /movies.
>>> Whenever a .flv file is requested within that directory, some stuff 
>>> should happen, if not, the request should be processed as usual. I don't 
>>> know how to do the latter..
>>>       
>> Handlers are put in a chain and you can load them in front or back
>> (default is in back).  In your case, you want your handler to either do
>> the processing and then set the response to finished (see HttpResponse
>> docs), or simply ignore the request and let it continue.  Then, you'll
>> just register the handler on "/" but give the :in_front => true option.
>>
>> Let me know if you need more than that.
>>
>>     
>
> Hi Zed, thanks for your reply.
>
> Okay I understand the theory, but how do I continue? I thought simply 
> returning from my process() method would do the trick, but the code 
> below doesn't work, it gives a 404 for files that do exists, but are not 
> flv. I just want any file that is not .flv to be served normally.
>
>    def process(request, response)
>
>      # only stream flv files
>      if File.extname(request.params['REQUEST_PATH']).downcase == '.flv'
>        puts "not a flv, so returning to the next handler on the stack"
>        return
>      end
>
>
> Here's my config:
>
> uri "/movies",
>    :handler => plugin("/handlers/streamert"),
>    :in_front => true
>
>
> I'll post the whole init.rb below, just in case.
>
> require 'mongrel'
> require 'gem_plugin'
>
> class Streamert < GemPlugin::Plugin "/handlers"
>    include Mongrel::HttpHandlerPlugin
>
>    def initialize(options = {})
>      @docroot = options[:cwd] + "/" + options[:docroot]
>    end
>
>    def process(request, response)
>
>      # only stream flv files
>      if File.extname(request.params['REQUEST_PATH']).downcase == '.flv'
>        puts "not a flv, so returning to the next handler on the stack"
>        return
>      end
>
>      filename = @docroot + request.params['REQUEST_PATH']
>
>      # check if file exists
>      unless File.exists?(filename) && File.readable?(filename)
>        response.start(404, true) do |head,out|
>          out.write "Could not open file #{request.params['REQUEST_PATH']}\n"
>        end
>      end
>
>      # see if an offset was given
>      offset = 
> Mongrel::HttpRequest.query_parse(request.params['QUERY_STRING'])['offset'].to_i
>      # check for sane offset
>      offset = 0 unless (0...File.size(filename)).include? offset
>
>      begin
>        response.start(200, true) do |head,out|
>
>          head['Content-Type'] = 'video/x-flv'
>
>          # write flv marker bytes to response stream
>          if pos != 0
>            out.write "FLV"
>            out.write [1].pack("C")
>            out.write [1].pack("C")
>            out.write [9].pack("N")
>            out.write [9].pack("N")
>          end
>
>          # read and output flv file optionally starting at a given offset
>          File.open(filename, "rb") do |f|
>            f.seek(offset)
>            while (!f.eof) do
>              out.write f.read(8092)
>            end
>          end
>        end
>      rescue Exception => e
>        response.start(500, true) do |head,out|
>          out.write "error proceessing #{request.params['REQUEST_PATH']}\n"
>        end
>      end
>
>    end
>
> end
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   



From jan.svitok at gmail.com  Fri Mar 16 06:37:20 2007
From: jan.svitok at gmail.com (Jan Svitok)
Date: Fri, 16 Mar 2007 11:37:20 +0100
Subject: [Mongrel] need help writing a plugin - Still hoping for an
	answer :-)
In-Reply-To: <45F940D1.4060002@supercool.nl>
References: <45F54BDF.7030208@supercool.nl>
	<20070312103424.33499f2b.zedshaw@zedshaw.com>
	<45F5C620.8010507@supercool.nl> <45F940D1.4060002@supercool.nl>
Message-ID: <8d9b3d920703160337s5587617dg28e0bb3210434ca1@mail.gmail.com>

On 3/15/07, Jeroen Houben <jeroen at supercool.nl> wrote:
> Jeroen Houben wrote:
> > Hi Zed, thanks for your reply.
> >
> > Okay I understand the theory, but how do I continue? I thought simply
> > returning from my process() method would do the trick, but the code
> > below doesn't work, it gives a 404 for files that do exists, but are not
> > flv. I just want any file that is not .flv to be served normally.

Hi,

if nobody answers, maybe you can resort to reading the mongrel sources ;-)

look in lib/mongrel.rb for

              # Process each handler in registered order until we run
out or one finalizes the response.
              handlers.each do |handler|
                handler.process(request, response)
                break if response.done or client.closed?
              end

              # And finally, if nobody closed the response off, we finalize it.
              unless response.done or client.closed?
                response.finished
              end

The sources are pretty readable, so you should find your way pretty
fast. I suspect that the problem is that the "normal processing"
plugin is not there. See the lines just after those I posted. Or add
some traces there to see what's going on(like what handlers are tried
etc.)

From jeroen at supercool.nl  Fri Mar 16 08:40:29 2007
From: jeroen at supercool.nl (Jeroen Houben)
Date: Fri, 16 Mar 2007 13:40:29 +0100
Subject: [Mongrel] need help writing a plugin - Still hoping for
 an	answer :-)
In-Reply-To: <8d9b3d920703160337s5587617dg28e0bb3210434ca1@mail.gmail.com>
References: <45F54BDF.7030208@supercool.nl>	<20070312103424.33499f2b.zedshaw@zedshaw.com>	<45F5C620.8010507@supercool.nl>
	<45F940D1.4060002@supercool.nl>
	<8d9b3d920703160337s5587617dg28e0bb3210434ca1@mail.gmail.com>
Message-ID: <45FA903D.6060102@supercool.nl>

Jan Svitok wrote:
> On 3/15/07, Jeroen Houben <jeroen at supercool.nl> wrote:
>   
>> Jeroen Houben wrote:
>>     
>>> Hi Zed, thanks for your reply.
>>>
>>> Okay I understand the theory, but how do I continue? I thought simply
>>> returning from my process() method would do the trick, but the code
>>> below doesn't work, it gives a 404 for files that do exists, but are not
>>> flv. I just want any file that is not .flv to be served normally.
>>>       
>
> Hi,
>
> if nobody answers, maybe you can resort to reading the mongrel sources ;-)
>
> I suspect that the problem is that the "normal processing"
> plugin is not there. See the lines just after those I posted. Or add
> some traces there to see what's going on(like what handlers are tried
> etc.)
>   

I think you're right, adding some traces gives me this:

outputtings handlers for /10/metadata.yml
Streamert

outputtings handlers for /favicon.ico
Mongrel::Rails::RailsHandler

outputtings handlers for /favicon.ico
Mongrel::Rails::RailsHandler

I wonder why it hasn't registered the Streamert handler in front of the 
rails handler. Here's my config

uri "/movies",
  :handler => plugin("/handlers/streamert"),
  :in_front => true


if I change the first line to  uri "/",

things will work, but I then my plugin gets called for every request. 
Not very efficient, I mean, it's fine for what I'm going to do, but 
having it "listen" only to URLs under /movies seems more elegant.

Anyways, thanks for your help!

Jeroen


From magic_hat60622 at yahoo.com  Fri Mar 16 09:16:20 2007
From: magic_hat60622 at yahoo.com (magic hat)
Date: Fri, 16 Mar 2007 06:16:20 -0700 (PDT)
Subject: [Mongrel] mongrel, apache 2.0 & ssl
In-Reply-To: <45FA903D.6060102@supercool.nl>
Message-ID: <64660.66411.qm@web60913.mail.yahoo.com>

I need to deploy an app that requires SSL on a linux/apache 2.0 server that cannot be upgraded to apache 2.2. 

I'm a bit concerned that using pound and avoiding apache entirely will mess up my Plesk setup, but I'm willing to take a gamble on that, or any other approach that someone's found effective. Suggestions? 

 
---------------------------------
 Get your own web address.
 Have a HUGE year through Yahoo! Small Business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070316/0d1d6a94/attachment.html 

From pberry at gmail.com  Fri Mar 16 09:45:06 2007
From: pberry at gmail.com (Patrick Berry)
Date: Fri, 16 Mar 2007 06:45:06 -0700
Subject: [Mongrel] mongrel, apache 2.0 & ss
In-Reply-To: <64660.66411.qm@web60913.mail.yahoo.com>
References: <45FA903D.6060102@supercool.nl>
	<64660.66411.qm@web60913.mail.yahoo.com>
Message-ID: <ef13ff170703160645g6619f5a6yd0c50f010b33bb1@mail.gmail.com>

On 3/16/07, magic hat <magic_hat60622 at yahoo.com> wrote:
>
> I need to deploy an app that requires SSL on a linux/apache 2.0 server
> that cannot be upgraded to apache 2.2.
>
> I'm a bit concerned that using pound and avoiding apache entirely will
> mess up my Plesk setup, but I'm willing to take a gamble on that, or any
> other approach that someone's found effective. Suggestions?



This is entirely doable (as we have just that very setup in production right
now).  I have a page for the docs site into Zed for review that details the
steps (sans SSL, but that's just apache config).  The key to the whole thing
is from this article (previously posted on the list):

http://times.usefulinc.com/2006/09/13-mongrel-apache20

I would also recommend using the latest pre-release mongrel_cluster, as
there are just too many good features in there to not use it.

Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070316/699686a0/attachment-0001.html 

From jan.svitok at gmail.com  Fri Mar 16 09:53:50 2007
From: jan.svitok at gmail.com (Jan Svitok)
Date: Fri, 16 Mar 2007 14:53:50 +0100
Subject: [Mongrel] need help writing a plugin - Still hoping for an
	answer :-)
In-Reply-To: <45FA903D.6060102@supercool.nl>
References: <45F54BDF.7030208@supercool.nl>
	<20070312103424.33499f2b.zedshaw@zedshaw.com>
	<45F5C620.8010507@supercool.nl> <45F940D1.4060002@supercool.nl>
	<8d9b3d920703160337s5587617dg28e0bb3210434ca1@mail.gmail.com>
	<45FA903D.6060102@supercool.nl>
Message-ID: <8d9b3d920703160653k5a1c3dd5qad1acab02d2c811d@mail.gmail.com>

On 3/16/07, Jeroen Houben <jeroen at supercool.nl> wrote:
> Jan Svitok wrote:
> > On 3/15/07, Jeroen Houben <jeroen at supercool.nl> wrote:
> >
> >> Jeroen Houben wrote:
> >>
> >>> Hi Zed, thanks for your reply.
> >>>
> >>> Okay I understand the theory, but how do I continue? I thought simply
> >>> returning from my process() method would do the trick, but the code
> >>> below doesn't work, it gives a 404 for files that do exists, but are not
> >>> flv. I just want any file that is not .flv to be served normally.
> >>>
> >
> > Hi,
> >
> > if nobody answers, maybe you can resort to reading the mongrel sources ;-)
> >
> > I suspect that the problem is that the "normal processing"
> > plugin is not there. See the lines just after those I posted. Or add
> > some traces there to see what's going on(like what handlers are tried
> > etc.)
> >
>
> I think you're right, adding some traces gives me this:
>
> outputtings handlers for /10/metadata.yml
> Streamert
>
> outputtings handlers for /favicon.ico
> Mongrel::Rails::RailsHandler
>
> outputtings handlers for /favicon.ico
> Mongrel::Rails::RailsHandler
>
> I wonder why it hasn't registered the Streamert handler in front of the
> rails handler. Here's my config
>
> uri "/movies",
>   :handler => plugin("/handlers/streamert"),
>   :in_front => true
>
>
> if I change the first line to  uri "/",
>
> things will work, but I then my plugin gets called for every request.
> Not very efficient, I mean, it's fine for what I'm going to do, but
> having it "listen" only to URLs under /movies seems more elegant.
>
> Anyways, thanks for your help!
>
> Jeroen

I guess it's designed to enable override for particular subtrees, e.
g. / for rails *Except* /img that will be handled by a special
handler.

Maybe there's a way to tell Rails handler to listen on / and /movies
or create another rails handler, though I think the first approach
will be easier - you probably don't want to have two rails handlers in
one mongrel, but I might be wrong.

From zedshaw at zedshaw.com  Fri Mar 16 10:58:44 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 16 Mar 2007 10:58:44 -0400
Subject: [Mongrel] need help writing a plugin - Still hoping for an
 answer :-)
In-Reply-To: <45FA903D.6060102@supercool.nl>
References: <45F54BDF.7030208@supercool.nl>
	<20070312103424.33499f2b.zedshaw@zedshaw.com>
	<45F5C620.8010507@supercool.nl> <45F940D1.4060002@supercool.nl>
	<8d9b3d920703160337s5587617dg28e0bb3210434ca1@mail.gmail.com>
	<45FA903D.6060102@supercool.nl>
Message-ID: <20070316105844.e8d98d10.zedshaw@zedshaw.com>

On Fri, 16 Mar 2007 13:40:29 +0100
Jeroen Houben <jeroen at supercool.nl> wrote:

> uri "/movies",
>   :handler => plugin("/handlers/streamert"),
>   :in_front => true

You're on the right track, the only thing is you need to register it to
"/" not "/movies".  Then, your handler will be registered to the same
path as Rails but in front of the RailsHandler.

If you need to make sure requests are only for /movies, add a small bit
of checking for that in your handler.

Otherwise that should work.  Just FYI, how this works is handlers are
put onto a uri in a chain (just an array of handlers).  Before your
config it looks like this:

"/" => [RailsHandler]

What you did was this:

"/" => [RailsHandler], "/movies" => [streamert]

So, it'll only run when /movies is requested, but NOT chain onto
RailsHandler next.  By doing uri "/" instead of uri "/movies" you get
this:

"/" => [streamert, RailsHandler]

Which is what you want.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From kuijsten at yahoo.com  Fri Mar 16 11:08:06 2007
From: kuijsten at yahoo.com (Tim Kuijsten)
Date: Fri, 16 Mar 2007 08:08:06 -0700 (PDT)
Subject: [Mongrel] cancel running request
Message-ID: <352914.84563.qm@web30902.mail.mud.yahoo.com>

Hi everybody,

I'm making a plugin to limit the maximum request size (for file
uploads). Instead of canceling the request after it's completely
in (with the method 'process'). I would like to cancel it based
on the CONTENT_LENGTH in the method request_begins. Usability
thingie ;-)

how can i cancel the running request and send a response, instead
of waiting? currently i have these 2 methods:

  def request_begins(params)
    return unless params[Mongrel::Const::REQUEST_METHOD] ==
'POST'

    req_size = params[Mongrel::Const::CONTENT_LENGTH].to_i || 0
    if req_size > MAX_REQUEST_SIZE
      @request_too_big = true
    else
      @request_too_big = false
    end
  end

  def process(request, response)
    if @request_too_big
      response.start(413, true) do |head,out|
        out << "Request too big, probably you are trying to
upload a file that is too big"
      end
    end
  end

tnx,

Tim


 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

From magic_hat60622 at yahoo.com  Fri Mar 16 11:53:48 2007
From: magic_hat60622 at yahoo.com (magic hat)
Date: Fri, 16 Mar 2007 08:53:48 -0700 (PDT)
Subject: [Mongrel] mongrel, apache 2.0 & ss
In-Reply-To: <ef13ff170703160645g6619f5a6yd0c50f010b33bb1@mail.gmail.com>
Message-ID: <952437.42399.qm@web60918.mail.yahoo.com>

I'm not quite to the point where I need to worry about multiple mongrel processes -- the ssl is actually what's giving me trouble. 

I tried adding 

 RequestHeader set X_FORWARDED_PROTO 'https' to my .conf file, but that makes apache barf. 



Patrick Berry <pberry at gmail.com> wrote: 

On 3/16/07, magic hat <magic_hat60622 at yahoo.com> wrote: I need to deploy an app that requires SSL on a linux/apache 2.0 server that cannot be upgraded to apache 2.2. 

I'm a bit concerned that using pound and avoiding apache entirely will mess up my Plesk setup, but I'm willing to take a gamble on that, or any other approach that someone's found effective. Suggestions? 

This is entirely doable (as we have just that very setup in production right now).  I have a page for the docs site into Zed for review that details the steps (sans SSL, but that's just apache config).  The key to the whole thing is from this article (previously posted on the list): 

http://times.usefulinc.com/2006/09/13-mongrel-apache20

I would also recommend using the latest pre-release mongrel_cluster, as there are just too many good features in there to not use it. 

Pat


 _______________________________________________
Mongrel-users mailing list
Mongrel-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

 
---------------------------------
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070316/faebaa4f/attachment.html 

From magic_hat60622 at yahoo.com  Fri Mar 16 12:22:32 2007
From: magic_hat60622 at yahoo.com (magic hat)
Date: Fri, 16 Mar 2007 09:22:32 -0700 (PDT)
Subject: [Mongrel] mongrel, apache 2.0 & ss
In-Reply-To: <ef13ff170703160645g6619f5a6yd0c50f010b33bb1@mail.gmail.com>
Message-ID: <876079.46635.qm@web60912.mail.yahoo.com>

Okay, thanks to all for the help. 

This is now working fine. I just needed a separate ssl conf file that mirrored my standard conf file with the exception of the last line: RequestHeader set X_FORWARDED_PROTO 'https'

Patrick Berry <pberry at gmail.com> wrote: 

On 3/16/07, magic hat <magic_hat60622 at yahoo.com> wrote: I need to deploy an app that requires SSL on a linux/apache 2.0 server that cannot be upgraded to apache 2.2. 

I'm a bit concerned that using pound and avoiding apache entirely will mess up my Plesk setup, but I'm willing to take a gamble on that, or any other approach that someone's found effective. Suggestions? 

This is entirely doable (as we have just that very setup in production right now).  I have a page for the docs site into Zed for review that details the steps (sans SSL, but that's just apache config).  The key to the whole thing is from this article (previously posted on the list): 

http://times.usefulinc.com/2006/09/13-mongrel-apache20

I would also recommend using the latest pre-release mongrel_cluster, as there are just too many good features in there to not use it. 

Pat


 _______________________________________________
Mongrel-users mailing list
Mongrel-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

 	 
---------------------------------
Looking for earth-friendly autos? 
 Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070316/95476387/attachment.html 

From pberry at gmail.com  Fri Mar 16 12:28:23 2007
From: pberry at gmail.com (Patrick Berry)
Date: Fri, 16 Mar 2007 09:28:23 -0700
Subject: [Mongrel] mongrel, apache 2.0 & s
In-Reply-To: <952437.42399.qm@web60918.mail.yahoo.com>
References: <ef13ff170703160645g6619f5a6yd0c50f010b33bb1@mail.gmail.com>
	<952437.42399.qm@web60918.mail.yahoo.com>
Message-ID: <ef13ff170703160928o19e31d3md98823c8f2950b3b@mail.gmail.com>

Is that set in the virtual host section where all the other SSL stuff is
being set?

Here is a snippet from our config:

<VirtualHost 132.241.82.93:443>
[...snip]
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
RequestHeader set X_FORWARDED_PROTO 'https'
[...snip]
</VirtualHost>

What exactly is configtest saying the problem is?

Pat

On 3/16/07, magic hat <magic_hat60622 at yahoo.com> wrote:
>
> I'm not quite to the point where I need to worry about multiple mongrel
> processes -- the ssl is actually what's giving me trouble.
>
> I tried adding
>
>  RequestHeader set X_FORWARDED_PROTO 'https' to my .conf file, but that makes apache barf.
>
>
> *Patrick Berry <pberry at gmail.com>* wrote:
>
>
>
> On 3/16/07, magic hat <magic_hat60622 at yahoo.com> wrote:
> >
> > I need to deploy an app that requires SSL on a linux/apache 2.0 server
> > that cannot be upgraded to apache 2.2.
> >
> > I'm a bit concerned that using pound and avoiding apache entirely will
> > mess up my Plesk setup, but I'm willing to take a gamble on that, or any
> > other approach that someone's found effective. Suggestions?
>
>
>
> This is entirely doable (as we have just that very setup in production
> right now).  I have a page for the docs site into Zed for review that
> details the steps (sans SSL, but that's just apache config).  The key to the
> whole thing is from this article (previously posted on the list):
>
> http://times.usefulinc.com/2006/09/13-mongrel-apache20
>
> I would also recommend using the latest pre-release mongrel_cluster, as
> there are just too many good features in there to not use it.
>
> Pat
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
> ------------------------------
> Bored stiff? <http://us.rd.yahoo.com/evt=49935/*http://games.yahoo.com>Loosen up...
> Download and play hundreds of games for free<http://us.rd.yahoo.com/evt=49935/*http://games.yahoo.com>on Yahoo! Games.
>
>
> _______________________________________________
> 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/20070316/0e27641b/attachment.html 

From patcito at gmail.com  Fri Mar 16 17:21:46 2007
From: patcito at gmail.com (Patrick Aljord)
Date: Fri, 16 Mar 2007 22:21:46 +0100
Subject: [Mongrel] how to send mp3 inline?
Message-ID: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>

hey all,
I'm trying to do a:
 send_file @file, :type => 'audio/mp3', :disposition => 'inline' ,:stream=>true

I tried with all browsers and it always asks me to download the file
or open it with a player. Is there a way to make it open in the
embeded player (QT,Windows media player,Mplayer etc)? Only with
konqueror if I open in new tab then I get the embeded player :/

Am I doing something wrong with rails or with mongrel? if it's with
mongrel , how could I configure it so it sends the right stuff?

thanx in advance

Pat

From alexey.verkhovsky at gmail.com  Fri Mar 16 22:54:16 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Fri, 16 Mar 2007 20:54:16 -0600
Subject: [Mongrel] "mongrel_rails stop" leaving undeleted .pid files
Message-ID: <3945c4270703161954o76f2c810g320b9c0d527b6bab@mail.gmail.com>

I'm looking at implementation of Mongrel::Stop.run:

    def run
      if @force
        @wait.to_i.times do |waiting|
          exit(0) if not File.exist? @pid_file
          sleep 1
        end

        Mongrel::send_signal("KILL", @pid_file) if File.exist? @pid_file
      else
        Mongrel::send_signal("TERM", @pid_file)
      end
    end

and a question arises: is there any good reason not to rm_f(@pid_file) after
sending that SIGKILL? More likely than not, this is how the PID files are
left undeleted.

Alex Verkhovsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070316/1263f7c8/attachment.html 

From christian at rishoj.net  Fri Mar 16 22:48:00 2007
From: christian at rishoj.net (=?ISO-8859-1?Q?Christian_Rish=F8j?=)
Date: Sat, 17 Mar 2007 03:48:00 +0100
Subject: [Mongrel] Monitoring reponses
Message-ID: <E57D1738-3C44-41A1-AFAA-A420431EB6B7@rishoj.net>

Hi,
Using Rails and Mongrel. While serving downloads, conditioned on  
verification of a key done in Rails, I would like to register when  
the response has been in its entirety to the client, as well as when  
the transfer was interrupted due to a client closing the connection.
How can I achieve this?
Christian



From christian at rishoj.net  Fri Mar 16 23:42:52 2007
From: christian at rishoj.net (=?ISO-8859-1?Q?Christian_Rish=F8j?=)
Date: Sat, 17 Mar 2007 04:42:52 +0100
Subject: [Mongrel] Monitoring reponses
In-Reply-To: <E57D1738-3C44-41A1-AFAA-A420431EB6B7@rishoj.net>
References: <E57D1738-3C44-41A1-AFAA-A420431EB6B7@rishoj.net>
Message-ID: <2DA4B186-6E29-4692-938F-BA66A517349C@rishoj.net>


On 17 Mar 2007, at 03:48, Christian Rish?j wrote:

> I would like to register when
> the response has been in its entirety to the client, as well as when
> the transfer was interrupted due to a client closing the connection.

That was not very clear, sorry. In essence, I need to register when a  
download has been fully served to a client. Any clues are much  
appreciated.

Christian

From mmmaui at gmail.com  Sat Mar 17 13:34:36 2007
From: mmmaui at gmail.com (=?UTF-8?B?TWFyayBVaHJtYWNoZXI=?=)
Date: Sat, 17 Mar 2007 17:34:36 +0000
Subject: [Mongrel] how to send mp3 inline?
In-Reply-To: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>
References: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>
Message-ID: <241926126-1174152867-cardhu_blackberry.rim.net-618133709-@bwe035-cell00.bisx.prod.on.blackberry>


  

-----Original Message-----
From: "Patrick Aljord" <patcito at gmail.com>
Date: Fri, 16 Mar 2007 22:21:46 
To:mongrel-users at rubyforge.org
Subject: [Mongrel] how to send mp3 inline?

hey all,
I'm trying to do a:
 send_file @file, :type => 'audio/mp3', :disposition => 'inline' ,:stream=>true

I tried with all browsers and it always asks me to download the file
or open it with a player. Is there a way to make it open in the
embeded player (QT,Windows media player,Mplayer etc)? Only with
konqueror if I open in new tab then I get the embeded player :/

Am I doing something wrong with rails or with mongrel? if it's with
mongrel , how could I configure it so it sends the right stuff?

thanx in advance

Pat
_______________________________________________
Mongrel-users mailing list
Mongrel-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users



From mmmaui at gmail.com  Sat Mar 17 13:49:21 2007
From: mmmaui at gmail.com (=?UTF-8?B?TWFyayBVaHJtYWNoZXI=?=)
Date: Sat, 17 Mar 2007 17:49:21 +0000
Subject: [Mongrel] how to send mp3 inline?
In-Reply-To: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>
References: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>
Message-ID: <2058371449-1174153753-cardhu_blackberry.rim.net-1736587801-@bwe038-cell00.bisx.prod.on.blackberry>

AAA_4tyGthygtytygthyg
  

-----Original Message-----
From: "Patrick Aljord" <patcito at gmail.com>
Date: Fri, 16 Mar 2007 22:21:46 
To:mongrel-users at rubyforge.org
Subject: [Mongrel] how to send mp3 inline?

hey all,
I'm trying to do a:
 send_file @file, :type => 'audio/mp3', :disposition => 'inline' ,:stream=>true

I tried with all browsers and it always asks me to download the file
or open it with a player. Is there a way to make it open in the
embeded player (QT,Windows media player,Mplayer etc)? Only with
konqueror if I open in new tab then I get the embeded player :/

Am I doing something wrong with rails or with mongrel? if it's with
mongrel , how could I configure it so it sends the right stuff?

thanx in advance

Pat
_______________________________________________
Mongrel-users mailing list
Mongrel-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users



From bill at tribley.org  Sat Mar 17 22:53:40 2007
From: bill at tribley.org (Bill Tribley)
Date: Sat, 17 Mar 2007 21:53:40 -0500
Subject: [Mongrel] mongrel, apache 2.0 & s
In-Reply-To: <ef13ff170703160928o19e31d3md98823c8f2950b3b@mail.gmail.com>
Message-ID: <2007317215340.225249@billp4>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070317/d2c5d1f0/attachment.html 

From rsanheim at gmail.com  Sat Mar 17 23:23:15 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Sat, 17 Mar 2007 22:23:15 -0500
Subject: [Mongrel] mongrel, apache 2.0 & s
In-Reply-To: <2007317215340.225249@billp4>
References: <ef13ff170703160928o19e31d3md98823c8f2950b3b@mail.gmail.com>
	<2007317215340.225249@billp4>
Message-ID: <fc113d400703172023s52434147tc64c1c17f23eb94e@mail.gmail.com>

On 3/17/07, Bill Tribley <bill at tribley.org> wrote:
>
> Apache 2.0 is a real dog, 2.2 is a whole lot better. Is politics or risk the
> reason for no upgrade? If so, you should consider the stability and security
> factors. I would strongly recommend against running Apache 2.0 in production
> when 2.2 is available.

Can you explain this some more?  I know 2.2 has mod_proxy_balancer and
some other new modules that everyone likes, but are you referring to
major improvements to the core codebase improving a lot between 2.0 ->
2.2?

- Rob

From bill at tribley.org  Sat Mar 17 23:54:03 2007
From: bill at tribley.org (Bill Tribley)
Date: Sat, 17 Mar 2007 22:54:03 -0500
Subject: [Mongrel] mongrel, apache 2.0 & s
In-Reply-To: <fc113d400703172023s52434147tc64c1c17f23eb94e@mail.gmail.com>
Message-ID: <200731722543.548520@billp4>

Hi Rob,
I tried to use 2.0 several times from 2002 - 2005 . I had problems with file uploads, integrating programs like Tomcat was really hard, in general my <limited> experience indicated that 2.0 was a great thing for Windows but not so hot for Linux. 2.2 was a major overhaul from what I understand.

I wrote to the Apache mailing list about my problems after trying to upgrade from 1.3 to 2.0.47 (should be mature, right!)  and got a flame reply that could be distilled to "you idiot, why don't you just upgrade to the latest version and write again", after which I downgraded to the latest 1.3.xx release and stayed there (my passion is not to tinker with my system, I expect the core components to just work without me becoming expert in them). 

Then early in 2006 I discovered that 2.2 had been released. This version is really stable, it had none of the issues I had seen with 2.0 and it offered easy Tomcat integration that worked as advertised without the mod_jk nightmare of 1.3 and 2.0 . So, I was sold. The thing was also faster on my machine (an old/slow P3) than 1.3 . It is a real speed demon on my latest server which is an older 1.9gHz P4 with 1Gb RAM.

 From what I can see, if you want to run the best, stable version of 2.x it is 2.2.x, not 2.0x. You should not have issues upgrading, as long as you follow all the directions and compile from source. I don't trust any of the binaries floating around, in my opinion perl or apache should be compiled from source.  These packages typically compile on almost any machine, very often the available rpms or other packaged binary distros are old. 

All the Ruby docs I have seen show a cluster of Mongrels proxied by Apache 2.2 . The main Ruby site is running 2.0.something, but rumor has it that it was not easy to get it all to work. The published Mongrel articles all refer to 2.2 . 2.2 is stable, why waste time on an outdated version?

Bill

On Sat, 17 Mar 2007 22:23:15 -0500, Rob Sanheim wrote:
> On 3/17/07, Bill Tribley <bill at tribley.org> wrote:
>
>> Apache 2.0 is a real dog, 2.2 is a whole lot better. Is politics or risk
>> the reason for no upgrade? If so, you should consider the stability and
>> security factors. I would strongly recommend against running Apache 2.0 in
>> production when 2.2 is available.
>>
>
> Can you explain this some more?  I know 2.2 has mod_proxy_balancer and some
> other new modules that everyone likes, but are you referring to major
> improvements to the core codebase improving a lot between 2.0 -> 2.2?
>
> - Rob
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
> ** Classified by CRM114 SS as good **
> CLASSIFY fails; success probability: 0.0024  pR: -2.6152
> Best match to file #1 (nonspam.css) prob: 0.9976  pR: 2.6152 Total features
> in input file: 2254
> #0 (spam.css): features: 1618819, hits: 46901, prob: 2.42e-03, pR:  -2.62 #1
> (nonspam.css): features: 1618667, hits: 41575, prob: 9.98e-01, pR:   2.62

From eden at mojiti.com  Sun Mar 18 02:02:27 2007
From: eden at mojiti.com (Eden Li)
Date: Sun, 18 Mar 2007 14:02:27 +0800
Subject: [Mongrel] how to send mp3 inline?
In-Reply-To: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>
References: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>
Message-ID: <1dd361e10703172302t6978be1emfa1e38a3c383e398@mail.gmail.com>

If you link to a raw audio/mp3 file, most browsers will force a
download of it because most don't include an mp3 player by default.
You need to link to an HTML page that loads up some sort of mp3 player
plugin explicitly (eg, via an object or embed tag).

On 3/17/07, Patrick Aljord <patcito at gmail.com> wrote:
> hey all,
> I'm trying to do a:
>  send_file @file, :type => 'audio/mp3', :disposition => 'inline' ,:stream=>true
>
> I tried with all browsers and it always asks me to download the file
> or open it with a player. Is there a way to make it open in the
> embeded player (QT,Windows media player,Mplayer etc)? Only with
> konqueror if I open in new tab then I get the embeded player :/
>
> Am I doing something wrong with rails or with mongrel? if it's with
> mongrel , how could I configure it so it sends the right stuff?

From nathan at nathanpowell.org  Sat Mar 17 23:09:19 2007
From: nathan at nathanpowell.org (n_powell)
Date: Sat, 17 Mar 2007 23:09:19 -0400
Subject: [Mongrel] mongrel, apache 2.0 & s
In-Reply-To: <2007317215340.225249@billp4>
References: <ef13ff170703160928o19e31d3md98823c8f2950b3b@mail.gmail.com>
	<2007317215340.225249@billp4>
Message-ID: <20070318030919.GY14661@nathanpowell.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Not to get all curmudgeony, but these html emails are impossible 
to read in mutt.

On Sat, Mar 17, 2007 at 09:53:40PM -0500 thus spake Bill Tribley:
> <html><head><meta name="Generator" content="PSI HTML/CSS Generator"/>
> <style type="text/css"><!--
> body{font-family:'Tahoma';font-size:12pt;font-color:'#000000';}
> LI{display:list-item;margin:0.00in;}
> p{display:block;margin:0.00in;}
> --></style>
> </head><BODY ><div><SPAN style="font-size:12pt;">Apache 2.0 is a real dog, 2.2 is a whole lot better. Is politics or risk the reason for no upgrade? If so, you should consider the stability and security factors. I would strongly recommend against running Apache 2.0 in production when 2.2 is available.<br /><br /></span></div>
> <div><SPAN style="font-size:12pt;">On Fri, 16 Mar 2007 09:28:23 -0700, Patrick Berry wrote:</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; Is that set in the virtual host section where all the other SSL stuff is</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; being set?</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; Here is a snippet from our config:</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; &lt;VirtualHost 132.241.82.93:443&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; [...snip]</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; SSLEngine on</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt SSLCertificateKeyFile</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; /etc/httpd/conf/ssl.key/server.key RequestHeader set X_FORWARDED_PROTO</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; 'https' [...snip] &lt;/VirtualHost&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; What exactly is configtest saying the problem is?</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; Pat</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; On 3/16/07, magic hat &lt;magic_hat60622 at yahoo.com &gt; wrote:&gt; I'm not quite to</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; the point where I need to worry about multiple mongrel processes -- the ssl</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt; is actually what's giving me trouble.</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; I tried adding</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; RequestHeader set X_FORWARDED_PROTO 'https' to my .conf file, but that</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; makes apache barf.</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; Patrick Berry &lt; pberry at gmail.com&gt; wrote:&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; On 3/16/07, magic hat &lt;magic_hat60622 at yahoo.com&gt; wrote:&gt; I need to</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; deploy an app that requires SSL on a linux/apache 2.0 server that cannot</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; be upgraded to apache 2.2.</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;&gt; I'm a bit concerned that using pound and avoiding apache entirely will</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;&gt; mess up my Plesk setup, but I'm willing to take a gamble on that, or</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;&gt; any other approach that someone's found effective. Suggestions?</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; This is entirely doable (as we have just that very setup in production</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; right now).&#160; I have a page for the docs site into Zed for review that</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; details the steps (sans SSL, but that's just apache config).&#160; The key to</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; the whole thing is from this article (previously posted on the list):</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; <a href="http://times.usefulinc.com/2006/09/13-mongrel-apache20">http://times.usefulinc.com/2006/09/13-mongrel-apache20</a></SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; I would also recommend using the latest pre-release mongrel_cluster, as</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; there are just too many good features in there to not use it.</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; Pat</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; _______________________________________________ Mongrel-users mailing</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; list Mongrel-users at rubyforge.org</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;&gt; <a href="http://rubyforge.org/mailman/listinfo/mongrel-users">http://rubyforge.org/mailman/listinfo/mongrel-users</a></SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; Bored stiff? Loosen up...</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; Download and play hundreds of games for free on Yahoo! Games.</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt;</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; _______________________________________________</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; Mongrel-users mailing list</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; Mongrel-users at rubyforge.org</SPAN></div>
> <div><SPAN style="font-size:12pt;">&gt;&gt; <a href="http://rubyforge.org/mailman/listinfo/mongrel-users">http://rubyforge.org/mailman/listinfo/mongrel-users</a></SPAN></div>
> </body></html>

> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

- -- 
nathan
nathan_at_nathanpowell_dot_org

The longer I live the more I see that I am never wrong about anything,
and that all the pains I have so humbly taken to verify my notions have only wasted my time.
		 ~ George Bernard Shaw
- ------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF/K1fv3H2lx1re5YRAhU7AJ9EljzLzhbtsHJhnwe9wcPS9b9lWACfRsn1
t03/HE5uFzkYytwy+/BPXBQ=
=6kSZ
-----END PGP SIGNATURE-----

From mikeisgreat at gmail.com  Sun Mar 18 10:21:07 2007
From: mikeisgreat at gmail.com (Michael Steinfeld)
Date: Sun, 18 Mar 2007 10:21:07 -0400
Subject: [Mongrel] mongrel timing out
Message-ID: <3d5db09e0703180721i465f1a97w939c4be73683c15a@mail.gmail.com>

I am not sure when it exactly occurred but I have 2 servers I am about to
migrate to apache+mongrel from lighty+fastcgi

oddly, both my servers seemed to have died at the same time everytime I
restart within a 24 hr period ( I don't know when, my logs don't show it ).
Can someone please point me in the direction of what I need to do to trace
the cause of this. Or what you would need from me to help?




This is a RHEL4 box running rails 1.2.2 and ruby 1.8.5

here is part of the log entry

Mongrel timed out this thread: shutdown
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:675:in `write'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:532:in
`write'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:506:in
`command'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:238:in
`close'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/mysql_adapter.rb:236:in

 `disconnect!'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3
/lib/active_record/connection_adapters/mysql_adapter.rb:231:in
 `reconnect!'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract_adapter.rb:93:

in `verify!'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3
/lib/active_record/connection_adapters/abstract/connection_spe
cification.rb:109:in `verify_active_connections!'
/usr/local/lib/ruby/gems/1.8/gems/activerecord- 1.15.3
/lib/active_record/connection_adapters/abstract/connection_spe
cification.rb:108:in `each_value'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_spe

cification.rb:108:in `verify_active_connections!'
/usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:111:in
`prepare_application'
/usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:39:in
`dispatch'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb:78:in
`process'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb:76:in
`synchronize'
/usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel/rails.rb:76:in
`process'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:618:in
`process_client'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in `each'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in
`process_client'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in `run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in
`initialize'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in `new'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in `run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in
`initialize'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in `new'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in `run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/configurator.rb:271:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/configurator.rb:270:in
`each'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/configurator.rb:270:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/bin/mongrel_rails:127:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/command.rb:211:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/bin/mongrel_rails:243
/usr/local/bin/mongrel_rails:16:in `load'
/usr/local/bin/mongrel_rails:16
Mongrel timed out this thread: shutdown
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:675:in `write'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:532:in
`write'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:506:in
`command'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:238:in
`close'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3
/lib/active_record/connection_adapters/mysql_adapter.rb:236:in
 `disconnect!'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/mysql_adapter.rb:231:in


Mongrel timed out this thread: shutdown
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:675:in `write'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:532:in
`write'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:506:in
`command'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:238:in
`close'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/mysql_adapter.rb:236:in
`disconnect!'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/mysql_adapter.rb:231:in
`reconnect!'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract_adapter.rb:93:in
`verify!'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:10

9:in `verify_active_connections!'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3
/lib/active_record/connection_adapters/abstract/connection_specification.rb:10
8:in `each_value'
/usr/local/lib/ruby/gems/1.8/gems/activerecord- 1.15.3
/lib/active_record/connection_adapters/abstract/connection_specification.rb:10
8:in `verify_active_connections!'
/usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:111:in
`prepare_application'
/usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:39:in
`dispatch'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb:78:in
`process'
/usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel/rails.rb:76:in
`synchronize'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb:76:in
`process'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:618:in
`process_client'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in `each'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in
`process_client'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0 /lib/mongrel.rb:736:in `run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in
`initialize'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in `new'
/usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel.rb:736:in `run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in
`initialize'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in `new'
/usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel.rb:720:in `run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/configurator.rb:271:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/configurator.rb:270:in
`each'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/configurator.rb:270:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/bin/mongrel_rails:127:in `run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel/command.rb:211:in
`run'
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/bin/mongrel_rails:243
/usr/local/bin/mongrel_rails:16:in `load'
/usr/local/bin/mongrel_rails:16
Mongrel timed out this thread: shutdown


-- 
-mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070318/e5288d07/attachment.html 

From patcito at gmail.com  Sun Mar 18 11:08:31 2007
From: patcito at gmail.com (Patrick Aljord)
Date: Sun, 18 Mar 2007 16:08:31 +0100
Subject: [Mongrel] how to send mp3 inline?
In-Reply-To: <1dd361e10703172302t6978be1emfa1e38a3c383e398@mail.gmail.com>
References: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>
	<1dd361e10703172302t6978be1emfa1e38a3c383e398@mail.gmail.com>
Message-ID: <6b6419750703180808p24c4f650x43390ac0501568e8@mail.gmail.com>

thanx that's exactly what I did as a work around. I was just wondering
there was another way.

On 3/18/07, Eden Li <eden at mojiti.com> wrote:
> If you link to a raw audio/mp3 file, most browsers will force a
> download of it because most don't include an mp3 player by default.
> You need to link to an HTML page that loads up some sort of mp3 player
> plugin explicitly (eg, via an object or embed tag).
>
> On 3/17/07, Patrick Aljord <patcito at gmail.com> wrote:
> > hey all,
> > I'm trying to do a:
> >  send_file @file, :type => 'audio/mp3', :disposition => 'inline' ,:stream=>true
> >
> > I tried with all browsers and it always asks me to download the file
> > or open it with a player. Is there a way to make it open in the
> > embeded player (QT,Windows media player,Mplayer etc)? Only with
> > konqueror if I open in new tab then I get the embeded player :/
> >
> > Am I doing something wrong with rails or with mongrel? if it's with
> > mongrel , how could I configure it so it sends the right stuff?
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From eden at mojiti.com  Sun Mar 18 13:21:33 2007
From: eden at mojiti.com (Eden Li)
Date: Mon, 19 Mar 2007 01:21:33 +0800
Subject: [Mongrel] how to send mp3 inline?
In-Reply-To: <6b6419750703180808p24c4f650x43390ac0501568e8@mail.gmail.com>
References: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>
	<1dd361e10703172302t6978be1emfa1e38a3c383e398@mail.gmail.com>
	<6b6419750703180808p24c4f650x43390ac0501568e8@mail.gmail.com>
Message-ID: <1dd361e10703181021r6d906b0w6c04240923442399@mail.gmail.com>

afaik, no.

On 3/18/07, Patrick Aljord <patcito at gmail.com> wrote:
> thanx that's exactly what I did as a work around. I was just wondering
> there was another way.

From mikeisgreat at gmail.com  Sun Mar 18 13:55:34 2007
From: mikeisgreat at gmail.com (Michael Steinfeld)
Date: Sun, 18 Mar 2007 13:55:34 -0400
Subject: [Mongrel] Performance Tuning Mysql and how mongrel is effected
Message-ID: <3d5db09e0703181055w6b126315w9191e633c093cf89@mail.gmail.com>

As a follow up from my previous post, I am pondering some changes to my env.

I read that with AR I should change the verification timeout to be
lower than the MySQL db Interactive_timeout. Now, I have done some
performancing tuning to mysql in LAMP env's but not RoR. MySQL typical
set the default interactive_timeout to 8hrs (28800) this has bitten me
a few times with sleeping processess or stale connections. What I have
done in the past was optimize mysql with the following variable
changes (/etc/my.cnf)

wait_timeout=60
connect_timeout=10
interactive_timeout=120
join_buffer_size=1M
query_cache_size=128M
query_cache_limit=2M
sort_buffer_size=8M
key_buffer = 256M
key_buffer_size=64M
...


According to the mongrel docs it says to use 4hrs - assuming you
didn't edit mysql default settings- but what I am curious to know, is
what most people set this to, those of us who do performance tweak
their mysql servers. Also, if there is anything recommended
mongrel/rails specific.


ActiveRecord::Base.verification_timeout = 14400


-- 
-mike

From ben at gimbo.net  Sun Mar 18 14:06:30 2007
From: ben at gimbo.net (Ben Osheroff)
Date: Sun, 18 Mar 2007 11:06:30 -0700
Subject: [Mongrel] how to send mp3 inline?
In-Reply-To: <6b6419750703180808p24c4f650x43390ac0501568e8@mail.gmail.com>
References: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>	<1dd361e10703172302t6978be1emfa1e38a3c383e398@mail.gmail.com>
	<6b6419750703180808p24c4f650x43390ac0501568e8@mail.gmail.com>
Message-ID: <45FD7FA6.7050408@gimbo.net>

you could try setting the Content-disposition header to "inline".  Might
work.



Patrick Aljord wrote:
> thanx that's exactly what I did as a work around. I was just wondering
> there was another way.
> 
> On 3/18/07, Eden Li <eden at mojiti.com> wrote:
>> If you link to a raw audio/mp3 file, most browsers will force a
>> download of it because most don't include an mp3 player by default.
>> You need to link to an HTML page that loads up some sort of mp3 player
>> plugin explicitly (eg, via an object or embed tag).
>>
>> On 3/17/07, Patrick Aljord <patcito at gmail.com> wrote:
>>> hey all,
>>> I'm trying to do a:
>>>  send_file @file, :type => 'audio/mp3', :disposition => 'inline' ,:stream=>true
>>>
>>> I tried with all browsers and it always asks me to download the file
>>> or open it with a player. Is there a way to make it open in the
>>> embeded player (QT,Windows media player,Mplayer etc)? Only with
>>> konqueror if I open in new tab then I get the embeded player :/
>>>
>>> Am I doing something wrong with rails or with mongrel? if it's with
>>> mongrel , how could I configure it so it sends the right stuff?
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 

From patcito at gmail.com  Sun Mar 18 14:57:55 2007
From: patcito at gmail.com (Patrick Aljord)
Date: Sun, 18 Mar 2007 19:57:55 +0100
Subject: [Mongrel] how to send mp3 inline?
In-Reply-To: <45FD7FA6.7050408@gimbo.net>
References: <6b6419750703161421m4341afa6mcd9d127d03cf5042@mail.gmail.com>
	<1dd361e10703172302t6978be1emfa1e38a3c383e398@mail.gmail.com>
	<6b6419750703180808p24c4f650x43390ac0501568e8@mail.gmail.com>
	<45FD7FA6.7050408@gimbo.net>
Message-ID: <6b6419750703181157i66de4beew22fd764c1fac458b@mail.gmail.com>

this is what I did in my view:
 <%= link_to_remote 'play in line',
:url=>{:action=>'playinline',:songurl=>a.url
,:disposition=>'inline'}%>
<div id="playa<%= Digest::MD5.hexdigest(a.url) %>">
</div>

in my controller:
def playinline
@songurl=params[:songurl]
@md5=Digest::MD5.hexdigest(params[:songurl])
end

def play
@tag=Rtag.find_by_url(params['songurl'])
@file=@tag.rdevice.lastmountpoint+ at tag.url[1..-1]
@file=@file[1..-1] if @file[0..1]=='//'
# render :layout=>false
Mongrel::DirHandler::add_mime_type('mp3','audio/mp3')
 send_file @file, :type => 'audio/mp3', :disposition => 'inline' ,:stream=>true
end

in my playinline.rjs:
page.replace_html 'playa'+ at md5, '<embed
src="'+url_for(:action=>'play',:disposition=>'inline',:songurl=>@songurl)+'"
width="300" height="42" ></embed>'

works great

Pat

From ezmobius at gmail.com  Sun Mar 18 18:06:08 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Sun, 18 Mar 2007 15:06:08 -0700
Subject: [Mongrel] mongrel timing out
In-Reply-To: <3d5db09e0703180721i465f1a97w939c4be73683c15a@mail.gmail.com>
References: <3d5db09e0703180721i465f1a97w939c4be73683c15a@mail.gmail.com>
Message-ID: <37CEB2DC-ED80-4B7C-885B-EC1C6A95993B@brainspl.at>

Michael-


	The "Mongrel timed out on this thread" message usually happens when  
your Rails action is taking too long to complete and more requests  
are queuing up in mongrel. Do you have any really long running  
actions in your app? Are you shelling out or using IO.popen to call  
external programs?

-Ezra

On Mar 18, 2007, at 7:21 AM, Michael Steinfeld wrote:

> I am not sure when it exactly occurred but I have 2 servers I am  
> about to migrate to apache+mongrel from lighty+fastcgi
>
> oddly, both my servers seemed to have died at the same time  
> everytime I restart within a 24 hr period ( I don't know when, my  
> logs don't show it ). Can someone please point me in the direction  
> of what I need to do to trace the cause of this. Or what you would  
> need from me to help?
>
>
>
>
> This is a RHEL4 box running rails 1.2.2 and ruby 1.8.5
>
> here is part of the log entry
>
> Mongrel timed out this thread: shutdown
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:675:in  
> `write'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/vendor/mysql.rb:532:in `write'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/vendor/mysql.rb:506:in `command'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/vendor/mysql.rb:238:in `close'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/mysql_adapter.rb:236:in
>  `disconnect!'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/mysql_adapter.rb:231:in
>  `reconnect!'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/abstract_adapter.rb:93:
> in `verify!'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/abstract/connection_spe
> cification.rb:109:in `verify_active_connections!'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord- 1.15.3/lib/ 
> active_record/connection_adapters/abstract/connection_spe
> cification.rb:108:in `each_value'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/abstract/connection_spe
> cification.rb:108:in `verify_active_connections!'
> /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb: 
> 111:in `prepare_application'
> /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb: 
> 39:in `dispatch'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb: 
> 78:in `process'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb: 
> 76:in `synchronize'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel/rails.rb: 
> 76:in `process'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:618:in  
> `process_client'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in  
> `each'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in  
> `process_client'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in  
> `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in  
> `initialize'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in  
> `new'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in  
> `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in  
> `initialize'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in  
> `new'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in  
> `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/ 
> configurator.rb:271:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/ 
> configurator.rb:270:in `each'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/ 
> configurator.rb:270:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/bin/mongrel_rails: 
> 127:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/ 
> command.rb:211:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/bin/mongrel_rails:243
> /usr/local/bin/mongrel_rails:16:in `load'
> /usr/local/bin/mongrel_rails:16
> Mongrel timed out this thread: shutdown
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:675:in  
> `write'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/vendor/mysql.rb:532:in `write'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/vendor/mysql.rb:506:in `command'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/vendor/mysql.rb:238:in `close'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/mysql_adapter.rb:236:in
>  `disconnect!'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/mysql_adapter.rb:231:in
>
> Mongrel timed out this thread: shutdown
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:675:in  
> `write'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/vendor/mysql.rb:532:in `write'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/vendor/mysql.rb:506:in `command'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/vendor/mysql.rb:238:in `close'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/mysql_adapter.rb:236:in  
> `disconnect!'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/mysql_adapter.rb:231:in `reconnect!'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/abstract_adapter.rb:93:in `verify!'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/abstract/ 
> connection_specification.rb:10
> 9:in `verify_active_connections!'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/ 
> active_record/connection_adapters/abstract/ 
> connection_specification.rb:10
> 8:in `each_value'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord- 1.15.3/lib/ 
> active_record/connection_adapters/abstract/ 
> connection_specification.rb:10
> 8:in `verify_active_connections!'
> /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb: 
> 111:in `prepare_application'
> /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb: 
> 39:in `dispatch'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb: 
> 78:in `process'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel/rails.rb: 
> 76:in `synchronize'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb: 
> 76:in `process'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:618:in  
> `process_client'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in  
> `each'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in  
> `process_client'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0 /lib/mongrel.rb: 
> 736:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in  
> `initialize'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in  
> `new'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel.rb: 
> 736:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in  
> `initialize'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in  
> `new'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel.rb: 
> 720:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/ 
> configurator.rb:271:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/ 
> configurator.rb:270:in `each'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/ 
> configurator.rb:270:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/bin/mongrel_rails: 
> 127:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel/ 
> command.rb:211:in `run'
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/bin/mongrel_rails:243
> /usr/local/bin/mongrel_rails:16:in `load'
> /usr/local/bin/mongrel_rails:16
> Mongrel timed out this thread: shutdown
>
>
> -- 
> -mike
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



From krisleech at interkonect.com  Mon Mar 19 09:15:34 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Mon, 19 Mar 2007 13:15:34 +0000
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <45EFEC02.8020908@interkonect.com>
References: <45EFEC02.8020908@interkonect.com>
Message-ID: <45FE8CF6.3010709@interkonect.com>

I started using webrick for the time being, here is a sample of URI's Im 
getting:

/cgi-bin/yERX6Basjg5G.cfm

And basically loads of random letters/numbers with different extensions, 
php, chtm etc.

NessusTest141144291.html

/../../../../../../../boot.ini

/SProtectLinux/showpage.cgi

All from one IP: 209.67.114.37

Anyone else getting this?


From michael.dauria at gmail.com  Mon Mar 19 10:09:57 2007
From: michael.dauria at gmail.com (Michael D'Auria)
Date: Mon, 19 Mar 2007 10:09:57 -0400
Subject: [Mongrel] bad URI(is not URI?): c:\boot.ini
In-Reply-To: <45FE8CF6.3010709@interkonect.com>
References: <45EFEC02.8020908@interkonect.com>
	<45FE8CF6.3010709@interkonect.com>
Message-ID: <1907e2ca0703190709x779a1158jdeefddc9d86f7bca@mail.gmail.com>

Nessus is a tool for detecting open holes in your system, looks like someone
is trying to exploit your web server.

On 3/19/07, Kris Leech <krisleech at interkonect.com> wrote:
>
> I started using webrick for the time being, here is a sample of URI's Im
> getting:
>
> /cgi-bin/yERX6Basjg5G.cfm
>
> And basically loads of random letters/numbers with different extensions,
> php, chtm etc.
>
> NessusTest141144291.html
>
> /../../../../../../../boot.ini
>
> /SProtectLinux/showpage.cgi
>
> All from one IP: 209.67.114.37
>
> Anyone else getting this?
>
> _______________________________________________
> 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/20070319/b04858cf/attachment.html 

From mikeisgreat at gmail.com  Mon Mar 19 13:28:25 2007
From: mikeisgreat at gmail.com (Michael Steinfeld)
Date: Mon, 19 Mar 2007 13:28:25 -0400
Subject: [Mongrel] mongrel timing out
In-Reply-To: <37CEB2DC-ED80-4B7C-885B-EC1C6A95993B@brainspl.at>
References: <3d5db09e0703180721i465f1a97w939c4be73683c15a@mail.gmail.com>
	<37CEB2DC-ED80-4B7C-885B-EC1C6A95993B@brainspl.at>
Message-ID: <3d5db09e0703191028vb98fc61s1d11f2bd1ef07ccc@mail.gmail.com>

Hi Ezra,

My mistake was that I didn't install the mysql gem. I did think it was
installed already, but it wasn't so once I did--about 24hrs ago-- my
mongrels have not died. Thanks for responding though.

On another note, do you typically change you mysql settings? What do
you set your interactive_timeout to in environments.rb?

Thanks,

Mike

On 3/18/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> Michael-
>
>
>         The "Mongrel timed out on this thread" message usually happens when
> your Rails action is taking too long to complete and more requests
> are queuing up in mongrel. Do you have any really long running
> actions in your app? Are you shelling out or using IO.popen to call
> external programs?
>
> -Ezra
>
> On Mar 18, 2007, at 7:21 AM, Michael Steinfeld wrote:
>
> > I am not sure when it exactly occurred but I have 2 servers I am
> > about to migrate to apache+mongrel from lighty+fastcgi
> >
> > oddly, both my servers seemed to have died at the same time
> > everytime I restart within a 24 hr period ( I don't know when, my
> > logs don't show it ). Can someone please point me in the direction
> > of what I need to do to trace the cause of this. Or what you would
> > need from me to help?
> >
> >
> >
> >
> > This is a RHEL4 box running rails 1.2.2 and ruby 1.8.5
> >
> > here is part of the log entry
> >
> > Mongrel timed out this thread: shutdown
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:675:in
> > `write'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/vendor/mysql.rb:532:in `write'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/vendor/mysql.rb:506:in `command'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/vendor/mysql.rb:238:in `close'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/mysql_adapter.rb:236:in
> >  `disconnect!'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/mysql_adapter.rb:231:in
> >  `reconnect!'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/abstract_adapter.rb:93:
> > in `verify!'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/abstract/connection_spe
> > cification.rb:109:in `verify_active_connections!'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord- 1.15.3/lib/
> > active_record/connection_adapters/abstract/connection_spe
> > cification.rb:108:in `each_value'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/abstract/connection_spe
> > cification.rb:108:in `verify_active_connections!'
> > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:
> > 111:in `prepare_application'
> > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:
> > 39:in `dispatch'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb:
> > 78:in `process'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb:
> > 76:in `synchronize'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel/rails.rb:
> > 76:in `process'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:618:in
> > `process_client'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in
> > `each'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in
> > `process_client'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in
> > `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in
> > `initialize'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in
> > `new'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in
> > `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in
> > `initialize'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in
> > `new'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in
> > `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/
> > configurator.rb:271:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/
> > configurator.rb:270:in `each'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/
> > configurator.rb:270:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/bin/mongrel_rails:
> > 127:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/
> > command.rb:211:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/bin/mongrel_rails:243
> > /usr/local/bin/mongrel_rails:16:in `load'
> > /usr/local/bin/mongrel_rails:16
> > Mongrel timed out this thread: shutdown
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:675:in
> > `write'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/vendor/mysql.rb:532:in `write'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/vendor/mysql.rb:506:in `command'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/vendor/mysql.rb:238:in `close'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/mysql_adapter.rb:236:in
> >  `disconnect!'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/mysql_adapter.rb:231:in
> >
> > Mongrel timed out this thread: shutdown
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:675:in
> > `write'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/vendor/mysql.rb:532:in `write'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/vendor/mysql.rb:506:in `command'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/vendor/mysql.rb:238:in `close'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/mysql_adapter.rb:236:in
> > `disconnect!'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/mysql_adapter.rb:231:in `reconnect!'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/abstract_adapter.rb:93:in `verify!'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/abstract/
> > connection_specification.rb:10
> > 9:in `verify_active_connections!'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/
> > active_record/connection_adapters/abstract/
> > connection_specification.rb:10
> > 8:in `each_value'
> > /usr/local/lib/ruby/gems/1.8/gems/activerecord- 1.15.3/lib/
> > active_record/connection_adapters/abstract/
> > connection_specification.rb:10
> > 8:in `verify_active_connections!'
> > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:
> > 111:in `prepare_application'
> > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:
> > 39:in `dispatch'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb:
> > 78:in `process'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel/rails.rb:
> > 76:in `synchronize'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/rails.rb:
> > 76:in `process'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:618:in
> > `process_client'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in
> > `each'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:617:in
> > `process_client'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0 /lib/mongrel.rb:
> > 736:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in
> > `initialize'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:736:in
> > `new'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel.rb:
> > 736:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in
> > `initialize'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel.rb:720:in
> > `new'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel.rb:
> > 720:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/
> > configurator.rb:271:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/
> > configurator.rb:270:in `each'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/lib/mongrel/
> > configurator.rb:270:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/bin/mongrel_rails:
> > 127:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel- 1.0/lib/mongrel/
> > command.rb:211:in `run'
> > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0/bin/mongrel_rails:243
> > /usr/local/bin/mongrel_rails:16:in `load'
> > /usr/local/bin/mongrel_rails:16
> > Mongrel timed out this thread: shutdown
> >
> >
> > --
> > -mike
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
>
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
-mike

From mental at rydia.net  Tue Mar 20 00:59:25 2007
From: mental at rydia.net (MenTaLguY)
Date: Tue, 20 Mar 2007 00:59:25 -0400
Subject: [Mongrel] [ANN] fastthread 1.0
Message-ID: <1174366765.27800.5.camel@localhost.localdomain>

Well, just when I thought I was out of the fastthread business...

Okay, in brief:

fastthread is a Ruby extension which re-implements the primitives in
Ruby's thread.rb in C.  It was merged into 1.8.6, replacing the old
thread.rb implementation, but the version that was merged had a couple
serious bugs.

So -- now I release fastthread 1.0, which is basically the Ruby 1.8.6
version with the fixes applied.  You can use it as a hotfix for 1.8.6
until the next 1.8.x version is released, and of course it should still
work for speeding up older versions of 1.8 as well.

Gems and source are available via the mongrel RubyForge project:

http://rubyforge.org/frs/?group_id=1306

Let me know if you guys have any more problems.

-mental
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070320/f123ad0a/attachment.bin 

From rubyforge at aanet.com.au  Tue Mar 20 06:11:25 2007
From: rubyforge at aanet.com.au (Jason)
Date: Tue, 20 Mar 2007 21:11:25 +1100
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <1174366765.27800.5.camel@localhost.localdomain>
Message-ID: <20070320101130.9B8EA2D4399@mx.aanet.com.au>

Hi Mental,

Using the new 1.0, I ran the memory leak program referred to on:
http://pastie.caboo.se/10194

Unfortunately I am still seeing a memory leak.  Am I doing something wrong?

Not using fastthread: memory climbs to 97.1 MiB and stabilizes once the
"waiting for nnn threads" messages start.

Using fastthread: the memory never stops climbing maxing out at 243.6 MiB.

Appreciate your thoughts.

Thanks,
Jason

-----Original Message-----
From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of MenTaLguY
Sent: Tuesday, 20 March 2007 3:59 PM
To: ruby-talk ML; mongrel-users
Subject: [Mongrel] [ANN] fastthread 1.0

Well, just when I thought I was out of the fastthread business...

Okay, in brief:

fastthread is a Ruby extension which re-implements the primitives in Ruby's
thread.rb in C.  It was merged into 1.8.6, replacing the old thread.rb
implementation, but the version that was merged had a couple serious bugs.

So -- now I release fastthread 1.0, which is basically the Ruby 1.8.6
version with the fixes applied.  You can use it as a hotfix for 1.8.6 until
the next 1.8.x version is released, and of course it should still work for
speeding up older versions of 1.8 as well.

Gems and source are available via the mongrel RubyForge project:

http://rubyforge.org/frs/?group_id=1306

Let me know if you guys have any more problems.

-mental


From wayneeseguin at gmail.com  Tue Mar 20 07:55:01 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 20 Mar 2007 07:55:01 -0400
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <1174366765.27800.5.camel@localhost.localdomain>
References: <1174366765.27800.5.camel@localhost.localdomain>
Message-ID: <0B897791-8E40-4958-8855-999D87D169F8@gmail.com>


On Mar 20, 2007, at 00:59 , MenTaLguY wrote:
> fastthread is a Ruby extension which re-implements the primitives in
> Ruby's thread.rb in C.  It was merged into 1.8.6, replacing the old
> thread.rb implementation, but the version that was merged had a couple
> serious bugs.

Mental,

What might these serious bugs be?

Thanks,

   ~Wayne


From gethemant at gmail.com  Tue Mar 20 08:15:37 2007
From: gethemant at gmail.com (hemant)
Date: Tue, 20 Mar 2007 17:45:37 +0530
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
References: <1174366765.27800.5.camel@localhost.localdomain>
	<0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
Message-ID: <fb283d5e0703200515n400dd2e9k8a04428cfc362864@mail.gmail.com>

On 3/20/07, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:
>
> On Mar 20, 2007, at 00:59 , MenTaLguY wrote:
> > fastthread is a Ruby extension which re-implements the primitives in
> > Ruby's thread.rb in C.  It was merged into 1.8.6, replacing the old
> > thread.rb implementation, but the version that was merged had a couple
> > serious bugs.
>
> Mental,
>
> What might these serious bugs be?
>
> Thanks,
>
>    ~Wayne
>

With a freshly created plain vanilla rails app with no
code/controller/model added, when i attempt to start it, i get:

** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:477:in
`const_missing': uninitialized constant
ActiveRecord::ConnectionAdapters::TwelveByteKey::Mutex (NameError)
        from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/frontbase_adapter.rb:55
        from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in
`require'
        from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:342:in
`new_constants_in'
        from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in
`require'
        from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record.rb:81
        from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record.rb:80
        from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
         ... 11 levels...
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:83:in
`run'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in
`run'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
        from /usr/bin/mongrel_rails:18


This is when, I have ruby 1.8.6 installed and fastthread gem version
1.0 is also installed. Any ideas why is this?

From aglarond at gmail.com  Tue Mar 20 09:17:07 2007
From: aglarond at gmail.com (Dimitri Aivaliotis)
Date: Tue, 20 Mar 2007 14:17:07 +0100
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <20070315055912.36c9d1b9.zedshaw@zedshaw.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
Message-ID: <55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>

Hey Zed,

On 3/15/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> On Wed, 14 Mar 2007 11:23:41 -0400
> Matt Zukowski <mzukowski at urbacon.net> wrote:

> Sorry Matt, I've been travelling a lot lately and missed this.
>
> > !!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
>
> It says tell ZED not the mongrel-users mailing list. :-)
>
> Anyway, the exception is a weird one since it's saying that you've
> opened this port and then it's closed right away.  You'll have to give
> me sample code and the platform information so I can replicate it
> better.  I'm thinking it might be something strange about this platform
> when a client closes right at the accept point.

Was there any follow-up here?  Anyways, I've got the same problem as
Matt.  My OS is FreeBSD (6.2-RELEASE); the problem happens with and
without accf_http loaded; below is a minimal test script to reproduce
the problem and a sample of the log output.  Be sure to kill the
process shortly after starting it, or you'll fill the partition where
the log is written.

- Dimitri

--- begin script "test.rb" ---
#!/usr/bin/env ruby

require 'mongrel'

$mongrel_debug_client = true

Mongrel::Configurator.new do
  listener do
    uri "/", :handler => Mongrel::DirHandler.new(".")
  end
  daemonize( :cwd => "/tmp", :log_file => "/tmp/test.log" )
  run
end.join
--- end script "test.rb" ---

--- begin log ---
!!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
~/.gems/gems/mongrel-1.0.1/lib/mongrel.rb:723:in `accept'
~/.gems/gems/mongrel-1.0.1/lib/mongrel.rb:723:in `run'
~/.gems/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `initialize'
~/.gems/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `new'
~/.gems/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `run'
~/.gems/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in `run'
~/.gems/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `each'
~/.gems/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `run'
./test.rb:12:in `cloaker_'
~/.gems/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:51:in `call'
~/.gems/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:51:in `initialize'
./test.rb:7:in `new'
./test.rb:7
--- end log ---

From aglarond at gmail.com  Tue Mar 20 09:53:39 2007
From: aglarond at gmail.com (Dimitri Aivaliotis)
Date: Tue, 20 Mar 2007 14:53:39 +0100
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
Message-ID: <55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>

Alright, solved my problem.  Don't know if it'll help Matt, as well.
The key is in the documentation comment for daemonize:

    # You must call this *before* frameworks that open files
    # as otherwise the files will be closed by this function.

Looking at the examples/builder.rb script, I see that daemonize is
indeed called before listener (perhaps this should be made more
explicit in the docs).  So, below is a working test script.  The one
other thing I added, was to specify the port to listen on. :)

Oh, no pid file is created, no matter if I give :pid_file to the
Configurator.new call or to the daemonize call as in builder.rb.

- Dimitri


--- begin script "test.rb" ---
#!/usr/bin/env ruby

require 'mongrel'

$mongrel_debug_client = true

Mongrel::Configurator.new( :port => 9000 ) do
  daemonize( :cwd => "/tmp", :log_file => "/tmp/test.log" )
  listener do
    uri "/", :handler => Mongrel::DirHandler.new(".")
  end
  run
end.join
--- end script "test.rb" ---

From zedshaw at zedshaw.com  Tue Mar 20 10:04:58 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 20 Mar 2007 10:04:58 -0400
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
Message-ID: <20070320100458.835c53d7.zedshaw@zedshaw.com>

On Tue, 20 Mar 2007 14:17:07 +0100
"Dimitri Aivaliotis" <aglarond at gmail.com> wrote:

> Hey Zed,
> 
> On 3/15/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> > On Wed, 14 Mar 2007 11:23:41 -0400
> > Matt Zukowski <mzukowski at urbacon.net> wrote:
> 
> > Sorry Matt, I've been travelling a lot lately and missed this.
> >
> > > !!!!!! UNHANDLED EXCEPTION! closed stream.  TELL ZED HE'S A MORON.
> >
> > It says tell ZED not the mongrel-users mailing list. :-)
> >
> > Anyway, the exception is a weird one since it's saying that you've
> > opened this port and then it's closed right away.  You'll have to give
> > me sample code and the platform information so I can replicate it
> > better.  I'm thinking it might be something strange about this platform
> > when a client closes right at the accept point.
> 
> Was there any follow-up here?  Anyways, I've got the same problem as
> Matt.  My OS is FreeBSD (6.2-RELEASE); the problem happens with and
> without accf_http loaded; below is a minimal test script to reproduce
> the problem and a sample of the log output.  Be sure to kill the
> process shortly after starting it, or you'll fill the partition where
> the log is written.

No, I downloaded the latest 6.2 fbsd so I can try to debug this, but
I've got a lot going on right now.  Really it seems fbsd has decided to
change the semantics of accept so that you get an errno when the client
closes before the accept completes.

Hey, if you could change the statement that prints out that message to
also print out what exception class and then shoot me the new stack
trace that'd help quite a bit.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From zedshaw at zedshaw.com  Tue Mar 20 10:44:15 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 20 Mar 2007 10:44:15 -0400
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
Message-ID: <20070320104415.98b33127.zedshaw@zedshaw.com>

On Tue, 20 Mar 2007 14:53:39 +0100
"Dimitri Aivaliotis" <aglarond at gmail.com> wrote:

> Alright, solved my problem.  Don't know if it'll help Matt, as well.
> The key is in the documentation comment for daemonize:
> 
>     # You must call this *before* frameworks that open files
>     # as otherwise the files will be closed by this function.

Aha! Classic PEBKAC eh?  :-)

> 
> Oh, no pid file is created, no matter if I give :pid_file to the
> Configurator.new call or to the daemonize call as in builder.rb.

Make sure you give a full path for all your files you configure.  If
not, let me know and I'll check it out.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From bradley at railsmachine.com  Tue Mar 20 10:53:12 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Tue, 20 Mar 2007 10:53:12 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
Message-ID: <45FFF558.2090908@railsmachine.com>

Hi all...

Hopefully this is the last prelease. If people on non-linux systems 
could post back any problems with cluster::status, I'd appreciate it.

Install with:
gem install mongrel_cluster --source http://mongrel.rubyforge.org/releases/

Note: This is only an update to mongrel_cluster and not Mongrel or other 
gems.

Details about what's new (if you missed the first prerelease):
http://blog.railsmachine.com/2007/2/26/mongrel_cluster-prerelease-1-0-1-1

Thanks,
Bradley Taylor
http://railsmachine.com

From aglarond at gmail.com  Tue Mar 20 11:16:01 2007
From: aglarond at gmail.com (Dimitri Aivaliotis)
Date: Tue, 20 Mar 2007 16:16:01 +0100
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <20070320100458.835c53d7.zedshaw@zedshaw.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<20070320100458.835c53d7.zedshaw@zedshaw.com>
Message-ID: <55c107bf0703200816hcc2cbe7tcedfbaee9c234677@mail.gmail.com>

On 3/20/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:

> No, I downloaded the latest 6.2 fbsd so I can try to debug this, but
> I've got a lot going on right now.  Really it seems fbsd has decided to
> change the semantics of accept so that you get an errno when the client
> closes before the accept completes.
>
> Hey, if you could change the statement that prints out that message to
> also print out what exception class and then shoot me the new stack
> trace that'd help quite a bit.

I've got the exception class now: IOError, but the stack trace remains
the same.  How else should I change the following to give you the
information you need?

          rescue Object => exc
            STDERR.puts "!!!!!! UNHANDLED EXCEPTION! #{exc.class}.
TELL ZED HE'S A MORON."
            STDERR.puts $!.backtrace.join("\n") if $mongrel_debug_client
          end

- Dimitri

From aglarond at gmail.com  Tue Mar 20 11:21:44 2007
From: aglarond at gmail.com (Dimitri Aivaliotis)
Date: Tue, 20 Mar 2007 16:21:44 +0100
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <20070320104415.98b33127.zedshaw@zedshaw.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
	<20070320104415.98b33127.zedshaw@zedshaw.com>
Message-ID: <55c107bf0703200821j681c0b9cl65065d0f82726174@mail.gmail.com>

On 3/20/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> On Tue, 20 Mar 2007 14:53:39 +0100
> "Dimitri Aivaliotis" <aglarond at gmail.com> wrote:
>
> > Alright, solved my problem.  Don't know if it'll help Matt, as well.
> > The key is in the documentation comment for daemonize:
> >
> >     # You must call this *before* frameworks that open files
> >     # as otherwise the files will be closed by this function.
>
> Aha! Classic PEBKAC eh?  :-)

Yep.  Could you change the docs slightly to prevent other idiots like
myself from falling into the same trap?  Something like the following
right after what's quoted above:

# (This includes +listener+ blocks - call daemonize before you set up
your listeners.)


> >
> > Oh, no pid file is created, no matter if I give :pid_file to the
> > Configurator.new call or to the daemonize call as in builder.rb.
>
> Make sure you give a full path for all your files you configure.  If
> not, let me know and I'll check it out.

I am using full paths: :pid_file => "/tmp/test.pid"

What other info can I give you to help debug this?

- Dimitri

From mzukowski at urbacon.net  Tue Mar 20 11:24:00 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Tue, 20 Mar 2007 11:24:00 -0400
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net>
	<45F8137D.2090707@urbacon.net>	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
Message-ID: <45FFFC90.2010902@urbacon.net>

Putting the daemonize before the listener call fixes the problem for me
as well.

Below is a skeleton camping app script that should reproduce the
original problem. Just run it using the ruby interpreter.

This is on a Linux 2.6.x box (openSuSE 10.2) so it's definitely not just
a BSD issue.

--------------------

require 'rubygems'
require 'camping'
require 'mongrel/camping'

Camping.goes :MyDaemon

module MyDaemon
        module Controllers
                class Foo < R '/'
                        def get
                                render :foo
                        end
                end
        end

        module Views
                def foo
                        xhtml_strict { head { title "Test" }; body {
"Blah" } }
                end
        end
end

if __FILE__ == $0

  config = Mongrel::Configurator.new :host => "0.0.0.0" do
                # putting daemonize here works
                #daemonize :log_file => '/tmp/mydaemon.log', :cwd =>
File.dirname(File.expand_path(__FILE__))
          listener :port => 9999 do
                  uri '/', :handler =>
Mongrel::Camping::CampingHandler.new(MyDaemon)
                  setup_signals
                end

                # putting it here doesn't :(
                daemonize :log_file => '/tmp/mydaemon.log', :cwd =>
File.dirname(File.expand_path(__FILE__))
        end

        config.run.join

end


This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.



From mzukowski at urbacon.net  Tue Mar 20 11:44:16 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Tue, 20 Mar 2007 11:44:16 -0400
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <45FFFC90.2010902@urbacon.net>
References: <45F6D212.3040002@urbacon.net>	<45F8137D.2090707@urbacon.net>	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>	<55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
	<45FFFC90.2010902@urbacon.net>
Message-ID: <46000150.3090401@urbacon.net>

Sorry, I jumped back into the conversation without seeing the
follow-ups, so my last post was a bit redundant.

But just to reiterate what Dimitri said earlier: putting the daemonize
call before the listener is probably not enough. You also have to make
sure that you do not open any IOs (files, etc.) until after the
daemonize call. For example, I had a log file open before daemonize and
ended up with 'IOError closed stream'

I do think though that there's probably some way to fix this on the
mongrel side. WEBRick seems to be able to daemonize itself without any
IO voodoo.

Matt Zukowski wrote:
> Putting the daemonize before the listener call fixes the problem for me
> as well.
> 
> Below is a skeleton camping app script that should reproduce the
> original problem. Just run it using the ruby interpreter.
> 
> This is on a Linux 2.6.x box (openSuSE 10.2) so it's definitely not just
> a BSD issue.
> 
> --------------------
> 
> require 'rubygems'
> require 'camping'
> require 'mongrel/camping'
> 
> Camping.goes :MyDaemon
> 
> module MyDaemon
>         module Controllers
>                 class Foo < R '/'
>                         def get
>                                 render :foo
>                         end
>                 end
>         end
> 
>         module Views
>                 def foo
>                         xhtml_strict { head { title "Test" }; body {
> "Blah" } }
>                 end
>         end
> end
> 
> if __FILE__ == $0
> 
>   config = Mongrel::Configurator.new :host => "0.0.0.0" do
>                 # putting daemonize here works
>                 #daemonize :log_file => '/tmp/mydaemon.log', :cwd =>
> File.dirname(File.expand_path(__FILE__))
>           listener :port => 9999 do
>                   uri '/', :handler =>
> Mongrel::Camping::CampingHandler.new(MyDaemon)
>                   setup_signals
>                 end
> 
>                 # putting it here doesn't :(
>                 daemonize :log_file => '/tmp/mydaemon.log', :cwd =>
> File.dirname(File.expand_path(__FILE__))
>         end
> 
>         config.run.join
> 
> end
> 
> 
> This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.
> 
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From mail at flydown.org  Tue Mar 20 13:30:25 2007
From: mail at flydown.org (Michele)
Date: Tue, 20 Mar 2007 18:30:25 +0100
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <45FFF558.2090908@railsmachine.com>
References: <45FFF558.2090908@railsmachine.com>
Message-ID: <182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>

Bradley,

It seems to work on FreeBSD (I had to delete all gems before it  
actually worked), even though I still get this:

Checking all mongrel_clusters...
mongrel_rails cluster::status -C config.yml
ps: Process environment requires procfs(5)
ps: Process environment requires procfs(5)
ps: Process environment requires procfs(5)
ps: Process environment requires procfs(5)
ps: Process environment requires procfs(5)

Best,
- MF

--
Michele Finotto
http://finotto.org/
http://16bugs.com/
http://pagety.com/


On Mar 20, 2007, at 15:53 , Bradley Taylor wrote:

> Hi all...
>
> Hopefully this is the last prelease. If people on non-linux systems
> could post back any problems with cluster::status, I'd appreciate it.
>
> Install with:
> gem install mongrel_cluster --source http://mongrel.rubyforge.org/ 
> releases/
>
> Note: This is only an update to mongrel_cluster and not Mongrel or  
> other
> gems.
>
> Details about what's new (if you missed the first prerelease):
> http://blog.railsmachine.com/2007/2/26/mongrel_cluster- 
> prerelease-1-0-1-1
>
> Thanks,
> Bradley Taylor
> http://railsmachine.com


From rsanheim at gmail.com  Tue Mar 20 14:35:33 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Tue, 20 Mar 2007 13:35:33 -0500
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <55c107bf0703200816hcc2cbe7tcedfbaee9c234677@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<20070320100458.835c53d7.zedshaw@zedshaw.com>
	<55c107bf0703200816hcc2cbe7tcedfbaee9c234677@mail.gmail.com>
Message-ID: <fc113d400703201135t1573f52bka8ca636dc7e75f20@mail.gmail.com>

On 3/20/07, Dimitri Aivaliotis <aglarond at gmail.com> wrote:
> On 3/20/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> > No, I downloaded the latest 6.2 fbsd so I can try to debug this, but
> > I've got a lot going on right now.  Really it seems fbsd has decided to
> > change the semantics of accept so that you get an errno when the client
> > closes before the accept completes.
> >
> > Hey, if you could change the statement that prints out that message to
> > also print out what exception class and then shoot me the new stack
> > trace that'd help quite a bit.
>
> I've got the exception class now: IOError, but the stack trace remains
> the same.  How else should I change the following to give you the
> information you need?
>
>           rescue Object => exc
>             STDERR.puts "!!!!!! UNHANDLED EXCEPTION! #{exc.class}.
> TELL ZED HE'S A MORON."
>             STDERR.puts $!.backtrace.join("\n") if $mongrel_debug_client
>           end
>
> - Dimitri

Try something like this:

STDERR.puts exc.backtrace.join("\n")

- rob

From mental at rydia.net  Tue Mar 20 19:18:33 2007
From: mental at rydia.net (MenTaLguY)
Date: Tue, 20 Mar 2007 19:18:33 -0400
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
References: <1174366765.27800.5.camel@localhost.localdomain>
	<0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
Message-ID: <1174432713.27800.21.camel@localhost.localdomain>

On Tue, 2007-03-20 at 07:55 -0400, Wayne E. Seguin wrote:
> Mental,
> 
> What might these serious bugs be?

ConditionVariable#wake could fail to wake threads, and also under some
wait lists could become corrupt.

-mental

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070320/02f2e5fb/attachment.bin 

From mental at rydia.net  Tue Mar 20 19:19:36 2007
From: mental at rydia.net (MenTaLguY)
Date: Tue, 20 Mar 2007 19:19:36 -0400
Subject: [Mongrel] Fastthread memory leak?
In-Reply-To: <6780.57.70.22.34.1173928497.squirrel@mail.aanet.com.au>
References: <43100.57.70.22.34.1173910419.squirrel@mail.aanet.com.au>
	<f59015b9cfd2db5676e0070ed5083a7a@localhost>
	<6780.57.70.22.34.1173928497.squirrel@mail.aanet.com.au>
Message-ID: <1174432776.27800.23.camel@localhost.localdomain>

On Thu, 2007-03-15 at 13:14 +1000, rubyforge at aanet.com.au wrote:
> Any ideas?

Give fastthread 1.0 a try if you can.

-mental
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070320/347ec756/attachment.bin 

From mental at rydia.net  Tue Mar 20 19:24:41 2007
From: mental at rydia.net (MenTaLguY)
Date: Tue, 20 Mar 2007 19:24:41 -0400
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <fb283d5e0703200515n400dd2e9k8a04428cfc362864@mail.gmail.com>
References: <1174366765.27800.5.camel@localhost.localdomain>
	<0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
	<fb283d5e0703200515n400dd2e9k8a04428cfc362864@mail.gmail.com>
Message-ID: <1174433081.27800.28.camel@localhost.localdomain>

On Tue, 2007-03-20 at 17:45 +0530, hemant wrote:
> With a freshly created plain vanilla rails app with no
> code/controller/model added, when i attempt to start it, i get:
> 
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Starting Rails with development environment...
> /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:477:in
> `const_missing': uninitialized constant
> ActiveRecord::ConnectionAdapters::TwelveByteKey::Mutex (NameError)

> This is when, I have ruby 1.8.6 installed and fastthread gem version
> 1.0 is also installed. Any ideas why is this?

Are you requiring thread or fastthread?  The problem is that ::Mutex is
not defined, which suggests that thread/fastthread has not been loaded
yet.

-mental

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070320/2bb02386/attachment.bin 

From gethemant at gmail.com  Wed Mar 21 00:39:32 2007
From: gethemant at gmail.com (hemant)
Date: Wed, 21 Mar 2007 10:09:32 +0530
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <1174433081.27800.28.camel@localhost.localdomain>
References: <1174366765.27800.5.camel@localhost.localdomain>
	<0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
	<fb283d5e0703200515n400dd2e9k8a04428cfc362864@mail.gmail.com>
	<1174433081.27800.28.camel@localhost.localdomain>
Message-ID: <fb283d5e0703202139p24297970y58f2ff0e994edfe7@mail.gmail.com>

On 3/21/07, MenTaLguY <mental at rydia.net> wrote:
> On Tue, 2007-03-20 at 17:45 +0530, hemant wrote:
> > With a freshly created plain vanilla rails app with no
> > code/controller/model added, when i attempt to start it, i get:
> >
> > ** Starting Mongrel listening at 0.0.0.0:3000
> > ** Starting Rails with development environment...
> > /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:477:in
> > `const_missing': uninitialized constant
> > ActiveRecord::ConnectionAdapters::TwelveByteKey::Mutex (NameError)
>
> > This is when, I have ruby 1.8.6 installed and fastthread gem version
> > 1.0 is also installed. Any ideas why is this?
>
> Are you requiring thread or fastthread?  The problem is that ::Mutex is
> not defined, which suggests that thread/fastthread has not been loaded
> yet.
>


Well, yes Mutex constant is not defined, but i wonder why?  As far my
code is concerned, i am not doing a explicit require on either thread
or fastthread. I guess its mongrel, which would do a require 'thread'.


-- 
gnufied

From mental at rydia.net  Wed Mar 21 01:01:15 2007
From: mental at rydia.net (MenTaLguY)
Date: Wed, 21 Mar 2007 01:01:15 -0400
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <fb283d5e0703202139p24297970y58f2ff0e994edfe7@mail.gmail.com>
References: <1174366765.27800.5.camel@localhost.localdomain>
	<0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
	<fb283d5e0703200515n400dd2e9k8a04428cfc362864@mail.gmail.com>
	<1174433081.27800.28.camel@localhost.localdomain>
	<fb283d5e0703202139p24297970y58f2ff0e994edfe7@mail.gmail.com>
Message-ID: <1174453275.27800.37.camel@localhost.localdomain>

On Wed, 2007-03-21 at 10:09 +0530, hemant wrote:
> Well, yes Mutex constant is not defined, but i wonder why?  As far my
> code is concerned, i am not doing a explicit require on either thread
> or fastthread.

Could you please humor me and try?

-mental

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070321/d11e7341/attachment-0001.bin 

From gethemant at gmail.com  Wed Mar 21 01:31:22 2007
From: gethemant at gmail.com (hemant)
Date: Wed, 21 Mar 2007 11:01:22 +0530
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <1174453275.27800.37.camel@localhost.localdomain>
References: <1174366765.27800.5.camel@localhost.localdomain>
	<0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
	<fb283d5e0703200515n400dd2e9k8a04428cfc362864@mail.gmail.com>
	<1174433081.27800.28.camel@localhost.localdomain>
	<fb283d5e0703202139p24297970y58f2ff0e994edfe7@mail.gmail.com>
	<1174453275.27800.37.camel@localhost.localdomain>
Message-ID: <fb283d5e0703202231p4a88f591ne452d59acc61b4e1@mail.gmail.com>

On 3/21/07, MenTaLguY <mental at rydia.net> wrote:
> On Wed, 2007-03-21 at 10:09 +0530, hemant wrote:
> > Well, yes Mutex constant is not defined, but i wonder why?  As far my
> > code is concerned, i am not doing a explicit require on either thread
> > or fastthread.
>
> Could you please humor me and try?
>

Well mental,

I have similar setup at couple of machines, where we upgraded to ruby
1.8.6, but machines on which mongrel is still able to start is using
fastthread :

fastthread (0.6.3)


On the other hand, the machine on which i am having problem is having
fastthread 1.0 ( i updated to fastthread 1.0)

So i added require 'thread' at the top of environment.rb file, yet i
get the above said error. I also tried adding require 'fastthread' in
place of environment.rb, to no avail.

On the other hand, if i start IRB and do :

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'fastthread'
=> true
irb(main):003:0> mut = Mutex.new
=> #<Mutex:0xb7be3554>
irb(main):004:0>


it works without problems.

From gethemant at gmail.com  Wed Mar 21 01:57:35 2007
From: gethemant at gmail.com (hemant)
Date: Wed, 21 Mar 2007 11:27:35 +0530
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <fb283d5e0703202231p4a88f591ne452d59acc61b4e1@mail.gmail.com>
References: <1174366765.27800.5.camel@localhost.localdomain>
	<0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
	<fb283d5e0703200515n400dd2e9k8a04428cfc362864@mail.gmail.com>
	<1174433081.27800.28.camel@localhost.localdomain>
	<fb283d5e0703202139p24297970y58f2ff0e994edfe7@mail.gmail.com>
	<1174453275.27800.37.camel@localhost.localdomain>
	<fb283d5e0703202231p4a88f591ne452d59acc61b4e1@mail.gmail.com>
Message-ID: <fb283d5e0703202257y1bb11803t2f7cbfdacd9dc1f@mail.gmail.com>

On 3/21/07, hemant <gethemant at gmail.com> wrote:
> On 3/21/07, MenTaLguY <mental at rydia.net> wrote:
> > On Wed, 2007-03-21 at 10:09 +0530, hemant wrote:
> > > Well, yes Mutex constant is not defined, but i wonder why?  As far my
> > > code is concerned, i am not doing a explicit require on either thread
> > > or fastthread.
> >
> > Could you please humor me and try?
> >
>
> Well mental,
>
> I have similar setup at couple of machines, where we upgraded to ruby
> 1.8.6, but machines on which mongrel is still able to start is using
> fastthread :
>
> fastthread (0.6.3)
>
>
> On the other hand, the machine on which i am having problem is having
> fastthread 1.0 ( i updated to fastthread 1.0)
>
> So i added require 'thread' at the top of environment.rb file, yet i
> get the above said error. I also tried adding require 'fastthread' in
> place of environment.rb, to no avail.
>
> On the other hand, if i start IRB and do :
>
> irb(main):001:0> require 'rubygems'
> => true
> irb(main):002:0> require 'fastthread'
> => true
> irb(main):003:0> mut = Mutex.new
> => #<Mutex:0xb7be3554>
> irb(main):004:0>
>
>
> it works without problems.
>

Ok mental, problem is solved now, we just reinstalled all the concerned gems.
But sadly still can't say, why was the above problem.

From mental at rydia.net  Wed Mar 21 02:19:59 2007
From: mental at rydia.net (MenTaLguY)
Date: Wed, 21 Mar 2007 02:19:59 -0400
Subject: [Mongrel] [ANN] fastthread 1.0
In-Reply-To: <fb283d5e0703202257y1bb11803t2f7cbfdacd9dc1f@mail.gmail.com>
References: <1174366765.27800.5.camel@localhost.localdomain>
	<0B897791-8E40-4958-8855-999D87D169F8@gmail.com>
	<fb283d5e0703200515n400dd2e9k8a04428cfc362864@mail.gmail.com>
	<1174433081.27800.28.camel@localhost.localdomain>
	<fb283d5e0703202139p24297970y58f2ff0e994edfe7@mail.gmail.com>
	<1174453275.27800.37.camel@localhost.localdomain>
	<fb283d5e0703202231p4a88f591ne452d59acc61b4e1@mail.gmail.com>
	<fb283d5e0703202257y1bb11803t2f7cbfdacd9dc1f@mail.gmail.com>
Message-ID: <1174457999.27800.41.camel@localhost.localdomain>

On Wed, 2007-03-21 at 11:27 +0530, hemant wrote:
> Ok mental, problem is solved now, we just reinstalled all the concerned gems.
> But sadly still can't say, why was the above problem.

Unless someone else reports the same problem, the most important thing
is that it works for you now. :)

-mental
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070321/d2150fa4/attachment.bin 

From aglarond at gmail.com  Wed Mar 21 05:41:07 2007
From: aglarond at gmail.com (Dimitri Aivaliotis)
Date: Wed, 21 Mar 2007 10:41:07 +0100
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <fc113d400703201135t1573f52bka8ca636dc7e75f20@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<20070320100458.835c53d7.zedshaw@zedshaw.com>
	<55c107bf0703200816hcc2cbe7tcedfbaee9c234677@mail.gmail.com>
	<fc113d400703201135t1573f52bka8ca636dc7e75f20@mail.gmail.com>
Message-ID: <55c107bf0703210241p36452545ue0d483d58d42651@mail.gmail.com>

On 3/20/07, Rob Sanheim <rsanheim at gmail.com> wrote:

>
> Try something like this:
>
> STDERR.puts exc.backtrace.join("\n")

Sorry if I'm being obtuse, but in this case

exc == $!

This doesn't help me to get more of a stack trace.

- Dimitri

From rsanheim at gmail.com  Wed Mar 21 09:13:21 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 21 Mar 2007 08:13:21 -0500
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <55c107bf0703210241p36452545ue0d483d58d42651@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<20070320100458.835c53d7.zedshaw@zedshaw.com>
	<55c107bf0703200816hcc2cbe7tcedfbaee9c234677@mail.gmail.com>
	<fc113d400703201135t1573f52bka8ca636dc7e75f20@mail.gmail.com>
	<55c107bf0703210241p36452545ue0d483d58d42651@mail.gmail.com>
Message-ID: <fc113d400703210613p4c349dd1kc2a31ab94b95b2ba@mail.gmail.com>

Yes, but you have that if clause on the end in your code - are you
sure that evaluates to true?

- rob

On 3/21/07, Dimitri Aivaliotis <aglarond at gmail.com> wrote:
> On 3/20/07, Rob Sanheim <rsanheim at gmail.com> wrote:
>
> >
> > Try something like this:
> >
> > STDERR.puts exc.backtrace.join("\n")
>
> Sorry if I'm being obtuse, but in this case
>
> exc == $!
>
> This doesn't help me to get more of a stack trace.
>
> - Dimitri
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From sebastienmaurette at yahoo.fr  Fri Mar 23 07:04:25 2007
From: sebastienmaurette at yahoo.fr (=?ISO-8859-1?Q?S=E9bastien_Maurette?=)
Date: Fri, 23 Mar 2007 11:04:25 +0000
Subject: [Mongrel] upload progress bar don't work...please help
Message-ID: <4603B439.7050602@yahoo.fr>

Hello,

I'm trying to install the upload_progress gem and i can't see the upload 
progress status.

My config is :

apache2 with mod_proxy
mongrel
rails

upload.rb : ##############

require 'rubygems'
require 'drb'
require 'gem_plugin'
GemPlugin::Manager.instance.load 'mongrel' => GemPlugin::INCLUDE
DRb.start_service 'druby://0.0.0.0:2999', Mongrel::UploadProgress.new
DRb.thread.join

mongrel_upload_progress.conf : ##########

uri "/",
  :handler => plugin("/handlers/upload",
                       :path_info => '/files/upload',
                       :frequency => 1,
                       :drb => 'druby://0.0.0.0:2999'),
  :in_front => true

routes.rb :

map.connect '/files/',:controller=>"files"

files_controller : #####################

class FilesController < ApplicationController
  session :off, :only => :progress
 
  def index
  end
 
  def progress
    render :update do |page|
      @status = Mongrel::Uploads.check(params[:upload_id])
      logger.info(params[:upload_id])
      page.upload_progress.update(@status[:size], @status[:received]) if 
@status
    end
  end
 
  def upload
    render :text => %(UPLOADED: #{params.inspect}.<script 
type="text/javascript">window.parent.UploadProgress.finish();</script>)
  end
end


When i try to upload a file i got this log in my production_log :


Processing FilesController#progress (for my_IP at 2007-03-23 10:42:56) 
[POST]
  Parameters: {"action"=>"progress", "controller"=>"files", 
"upload_id"=>"1174642904"}
1174642904
Completed in 0.00594 (168 reqs/sec) | Rendering: 0.00572 (96%) | DB: 
0.00000 (0%) | 200 OK 
[http://IP_SERVEUR/files/progress?upload_id=1174642904]


Processing FilesController#progress (for my_IP at 2007-03-23 10:42:59) 
[POST]
  Parameters: {"action"=>"progress", "controller"=>"files", 
"upload_id"=>"1174642904"}
1174642904
Completed in 0.00597 (167 reqs/sec) | Rendering: 0.00574 (96%) | DB: 
0.00000 (0%) | 200 OK 
[http://IP_SERVEUR/files/progress?upload_id=1174642904]


Processing FilesController#progress (for my_IP at 2007-03-23 10:43:02) 
[POST]
  Parameters: {"action"=>"progress", "controller"=>"files", 
"upload_id"=>"1174642904"}
1174642904
Completed in 0.00892 (112 reqs/sec) | Rendering: 0.00858 (96%) | DB: 
0.00000 (0%) | 200 OK 
[http://IP_SERVEUR/files/progress?upload_id=1174642904]


Processing FilesController#progress (for my_IP at 2007-03-23 10:43:05) 
[POST]
  Parameters: {"action"=>"progress", "controller"=>"files", 
"upload_id"=>"1174642904"}
1174642904
Completed in 0.00581 (172 reqs/sec) | Rendering: 0.00558 (96%) | DB: 
0.00000 (0%) | 200 OK 
[http://IP_SERVEUR/files/progress?upload_id=1174642904]


Processing FilesController#progress (for my_IP at 2007-03-23 10:43:08) 
[POST]
  Parameters: {"action"=>"progress", "controller"=>"files", 
"upload_id"=>"1174642904"}
1174642904
Completed in 0.00578 (173 reqs/sec) | Rendering: 0.00556 (96%) | DB: 
0.00000 (0%) | 200 OK 
[http://IP_SERVEUR/files/progress?upload_id=1174642904]


Processing FilesController#upload (for my_IP at 2007-03-23 10:43:09) [POST]
  Session ID: 85a4fa5dc5f0c442742c393746455108
  Parameters: {"commit"=>"Upload", "action"=>"upload", 
"controller"=>"files", "upload_id"=>"1174642904", 
"data"=>#<File:/tmp/CGI.6545.0>}
Completed in 0.00026 (3862 reqs/sec) | Rendering: 0.00006 (22%) | DB: 
0.00000 (0%) | 200 OK [http://IP_SERVEUR/files/upload?upload_id=1174642904]



The @status is always nil.

I don't know what ito do, is anyone have this problem before ?

Thanks for your help.

Seb.

ps: sorry for my english ...





	

	
		
___________________________________________________________________________ 
Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire.
http://fr.mail.yahoo.com

From krisleech at interkonect.com  Fri Mar 23 06:45:03 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Fri, 23 Mar 2007 10:45:03 +0000
Subject: [Mongrel] https load balancer for windows?
In-Reply-To: <001e01c76240$12328c00$7800a8c0@intranet.syntune.com>
References: <001e01c76240$12328c00$7800a8c0@intranet.syntune.com>
Message-ID: <4603AFAF.1010208@interkonect.com>

Erik Runeland wrote:
>
> Hello,
>
> I noticed that mongrel would work very nicely with something called 
> Pound to get https access to a rails app. However, I think Pound isn?t 
> available for the windows platform? Is there any other nice 
> lightweight load balancer like Pound that I could take a look at to 
> get https with mongrel and rails?
>
Could you not use Apache and mod_proxy?
>
> Cheers,
>
> /Erik
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users



From erik at runeland.se  Fri Mar 23 07:31:05 2007
From: erik at runeland.se (Erik Runeland)
Date: Fri, 23 Mar 2007 12:31:05 +0100
Subject: [Mongrel] https load balancer for windows?
In-Reply-To: <4603AFAF.1010208@interkonect.com>
References: <001e01c76240$12328c00$7800a8c0@intranet.syntune.com>
	<4603AFAF.1010208@interkonect.com>
Message-ID: <004101c76d3e$bec01dd0$7800a8c0@intranet.syntune.com>

Thanx for the suggestion, but I was thinking I'd not have to set that beast
up..

Pound seems like a more lightweight solution in a way, but I guess there is
no such option for windows.

/Erik

> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users-
> bounces at rubyforge.org] On Behalf Of Kris Leech
> Sent: den 23 mars 2007 11:45
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] https load balancer for windows?
> 
> Erik Runeland wrote:
> >
> > Hello,
> >
> > I noticed that mongrel would work very nicely with something called
> > Pound to get https access to a rails app. However, I think Pound isn't
> > available for the windows platform? Is there any other nice
> > lightweight load balancer like Pound that I could take a look at to
> > get https with mongrel and rails?
> >
> Could you not use Apache and mod_proxy?
> >
> > Cheers,
> >
> > /Erik
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> 
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From kuijsten at yahoo.com  Sat Mar 24 12:46:21 2007
From: kuijsten at yahoo.com (Tim Kuijsten)
Date: Sat, 24 Mar 2007 09:46:21 -0700 (PDT)
Subject: [Mongrel] max upload size!
Message-ID: <735351.63203.qm@web30915.mail.mud.yahoo.com>

As suggested in "max upload size?"
http://www.mail-archive.com/mongrel-users at rubyforge.org/msg02325.html
I created a plugin that disconnects (raises an error which
terminates the socket) if the specified content-length is higher
than 200 MB (by default). 

I don't know the behaviour if the specified content length is
different than the actual uploaded data or if no content-length
is given and chucked uploads are used.

I wanted to fix this by using the request_progress(params, clen,
total) method but clen represents the number of bytes that still
have to come in, not the number of received bytes.

How does mongrel deal with uploads when it does not know the
total content length?

And my second question:
Zed suggests in his post "and then attach that to the front of
your rails request". Currently my plugin raises an error and
disconnects the socket without send a reply at all (and the
Apache proxy keeps accepting incoming data making the user wait
till the upload is "completed" to discover it didn't upload). How
can I send an HTTP 413 and disconnect on request_begins. I tried
passing in the socket into request_begins as a second parameter
but I don't like to mess with the mongrel sources and rather keep
everything in the plugin.

I made a small writeup on my blog where you can also download the
plugin as a gem: http://slasaus.netsend.nl/articles/show/7

The solutions should get more user friendly by aborting the
upload from the client's perspective too, but at least it already
prevents full hard disks ;-)

Tim


 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

From thio.ben at gmail.com  Sat Mar 24 13:20:19 2007
From: thio.ben at gmail.com (Ben Thio)
Date: Sun, 25 Mar 2007 01:20:19 +0800
Subject: [Mongrel] BAD CLIENT error with mobile phone access
Message-ID: <0C3B6009-DEB4-44DD-9330-2C985891B123@gmail.com>

Hello!

Can someone help a newbie?

I'm using Instant Rails which has Mongrel configured inside.

I'm running a web application and everything works fine.

However, when I try to access my site using my mobile phone (a Nokia  
3230) and its in-built web browser, i get the following error:

Bad Client (XXX.XXX.XXX.XXX):Invalid HTTP format, parsing fails

I believe it is because I am not using a standard browser.

If I am not too concerned about security here, how would I fix this?  
Can someone advise?

Thanks!

Ben

From kylekochis at gmail.com  Sat Mar 24 13:45:07 2007
From: kylekochis at gmail.com (Kyle Kochis)
Date: Sat, 24 Mar 2007 11:45:07 -0600
Subject: [Mongrel] BAD CLIENT error with mobile phone access
In-Reply-To: <0C3B6009-DEB4-44DD-9330-2C985891B123@gmail.com>
References: <0C3B6009-DEB4-44DD-9330-2C985891B123@gmail.com>
Message-ID: <6a7034b0703241045l6aced151j450b7057a67f4836@mail.gmail.com>

First, don't use Instant Rails for production. It should only be used for
development. period.
The reason for this error is because Mongrel is very strict on HTTP and
kills things that aren't valid.
Someone else on the list might be able to help you on actually getting
mongrel to play nice with your phone. But keep in mind that you still can't
guarantee that every phone or hand-held out there is going to send in valid
(or even sorta kinda valid) requests that will work with mongrel.
Kyle

On 3/24/07, Ben Thio <thio.ben at gmail.com> wrote:
>
> Hello!
>
> Can someone help a newbie?
>
> I'm using Instant Rails which has Mongrel configured inside.
>
> I'm running a web application and everything works fine.
>
> However, when I try to access my site using my mobile phone (a Nokia
> 3230) and its in-built web browser, i get the following error:
>
> Bad Client (XXX.XXX.XXX.XXX):Invalid HTTP format, parsing fails
>
> I believe it is because I am not using a standard browser.
>
> If I am not too concerned about security here, how would I fix this?
> Can someone advise?
>
> Thanks!
>
> Ben
> _______________________________________________
> 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/20070324/0466012a/attachment.html 

From pberry at gmail.com  Sat Mar 24 13:46:13 2007
From: pberry at gmail.com (Patrick Berry)
Date: Sat, 24 Mar 2007 10:46:13 -0700
Subject: [Mongrel] BAD CLIENT error with mobile phone access
In-Reply-To: <0C3B6009-DEB4-44DD-9330-2C985891B123@gmail.com>
References: <0C3B6009-DEB4-44DD-9330-2C985891B123@gmail.com>
Message-ID: <ef13ff170703241046g52baad3ckaa135511974dea14@mail.gmail.com>

On 3/24/07, Ben Thio <thio.ben at gmail.com> wrote:
>
> Hello!
>
> Can someone help a newbie?
>
> I'm using Instant Rails which has Mongrel configured inside.
>
> I'm running a web application and everything works fine.
>
> However, when I try to access my site using my mobile phone (a Nokia
> 3230) and its in-built web browser, i get the following error:
>
> Bad Client (XXX.XXX.XXX.XXX):Invalid HTTP format, parsing fails
>
> I believe it is because I am not using a standard browser.
>
> If I am not too concerned about security here, how would I fix this?
> Can someone advise?
>
> Thanks!
>
> Ben



Zed has a great bit about this in the FAQ:
http://mongrel.rubyforge.org/faq.html
What does BAD CLIENT mean?

It means that a request came in which Mongrel rejects because it doesn't
follow the RFC grammar. Mongrel is pretty relaxed about most requests, but
in order to block the majority of security attacks for web servers it is
strict about characters used, header formats, status line formats, etc. This
is also based on matching the RFC's grammar specification to a Ragel grammar
specification, so it's easy to compare.

If you need to know why the client is triggering this, then simply hit your
Mongrel processes with USR1 signals and they'll log the full request data
and parameters that were collected. Then, if you think the request is valid
send me this data and I'll look. If it's not valid than fix the client.

Mongrel takes the stance that all clients are written by software developers
and that they should follow the standard. By doing this it reduces the bugs
and potential security holes found in many other web servers. It also means
that if you absolutely have to allow a bad client, then you'll need to not
use Mongrel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070324/3ab0d29c/attachment.html 

From bhjackson at gmail.com  Sat Mar 24 17:13:38 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Sat, 24 Mar 2007 18:13:38 -0300
Subject: [Mongrel] Mongrel Performance Tuning questions
Message-ID: <cb03bffe0703241413k7d2503ddr3f66fbf813e7ba9d@mail.gmail.com>

Hi all,

Starting out with load testing for one of my rails apps and am pretty
confused about what the 'best' way to do this is. I read the tuning
article at http://mongrel.rubyforge.org/docs/how_many_mongrels.html
but am getting some weird numbers from the tests recommended at the
bottom:

httperf --server www.theserver.com --port 80 --uri /tested --num-conns
<10 second count>
httperf --server www.theserver.com --port 80 --uri /tested --num-conns
<10 second count> --rate <reported req/sec>

I'm running this with 1 mongrel behind nginx with 6 workers. Serving
up static files seems fine, about 50 reqs/sec with 240 requests at a
rate of 120 for a small gif.

When running the first line, I started with 10 connections to my rails
page, which ran around 7-8 seconds (1.4 reqs/s). With 20 connections
it was up to 29 (0.7 reqs/s). Something seems wrong here.

Tried some heavier loads. With 100 requests and a rate of 50 it's at
20 seconds and 4.9 reqs/s. With 240 requests and a rate of 120 I get
54 seconds and 4.4 reqs/s.

I tested with 2 mongrels and brought the last test up to 25.4
reqs/sec, but AFAIK one mongrel should be able to handle up to 120,
right? Any and all advice will be much appreciated. Thanks,

Ben

From alexey.verkhovsky at gmail.com  Sat Mar 24 17:34:47 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Sat, 24 Mar 2007 15:34:47 -0600
Subject: [Mongrel] Mongrel Performance Tuning questions
In-Reply-To: <cb03bffe0703241413k7d2503ddr3f66fbf813e7ba9d@mail.gmail.com>
References: <cb03bffe0703241413k7d2503ddr3f66fbf813e7ba9d@mail.gmail.com>
Message-ID: <3945c4270703241434g25ee2033mc6a69c4a79397cc6@mail.gmail.com>

Check if you aren't running that Mongrel in development mode.

Before testing with various concurrent loads, tune the request-response time
of all your pages first by timing them WITHOUT any concurrency. Until you
have reasonably fast pages, concurrent load just complicates the picture.

Use ab (Apache Benchmark) to do the timing, like this:
  ab2 -c 1 -n 10 <url>

This will send the same request 10 times, one request at a time.

If the mean time is not as fast as you want it to be, look at the logs to
see if you have any slow queries, and if that doesn't help, use
script/performance/profiler to figure out where is the time wasted.

Alex Verkhovsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070324/d7eb5fda/attachment.html 

From bhjackson at gmail.com  Sat Mar 24 21:38:11 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Sat, 24 Mar 2007 22:38:11 -0300
Subject: [Mongrel] Mongrel Performance Tuning questions
In-Reply-To: <3945c4270703241434g25ee2033mc6a69c4a79397cc6@mail.gmail.com>
References: <cb03bffe0703241413k7d2503ddr3f66fbf813e7ba9d@mail.gmail.com>
	<3945c4270703241434g25ee2033mc6a69c4a79397cc6@mail.gmail.com>
Message-ID: <cb03bffe0703241838u26a50b02g6686839c90d7c3a4@mail.gmail.com>

> Use ab (Apache Benchmark) to do the timing, like this:
>   ab2 -c 1 -n 10 <url>
>
> This will send the same request 10 times, one request at a time.
>
> If the mean time is not as fast as you want it to be, look at the logs to
> see if you have any slow queries, and if that doesn't help, use
> script/performance/profiler to figure out where is the time wasted.

How fast should I shoot for the mean time to be for a normal homepage
on a VPS? I'm getting 2.27 reqs/sec for the rails page and 2.11 for
the static image with 10 requests each.

Thanks,

Ben

From sw-ng at scottwalter.com  Sat Mar 24 22:30:14 2007
From: sw-ng at scottwalter.com (Scott Walter)
Date: Sat, 24 Mar 2007 21:30:14 -0500
Subject: [Mongrel] Can't seem to get rewrite rules to work with Apache
Message-ID: <4589053F-0910-484C-B26D-00BB93F164AC@scottwalter.com>

Hi,

I'm struggling to get an Apache rewrite rule to work.   I have a  
simple rule that for a request to "a.html" will be sent to "b.html".   
However the requests for "a.html" are always sent to my Rails apps.   
Here is my  Apache configuration:

<VirtualHost 216.154.219.19:80>
<Directory /u/apps/simplelog_2.0.2/public/>
Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
DirectoryIndex index.php index.html
</Directory>
ServerName scottwalter.com
DocumentRoot /u/apps/simplelog_2.0.2/public
SuexecUserGroup webadmin webadmin
RewriteEngine On
RewriteRule ^a\.html$ b.html
ProxyPass / http://127.0.0.1:3002/
ProxyPassReverse / http://127.0.0.1:3002/
ProxyPreserveHost on
ServerAlias "www.scottwalter.com"
ServerAdmin "support at scottwalter.com"
CustomLog "/u/apps/simplelog_2.0.2/log/access_log" "combined"
ErrorLog "/u/apps/simplelog_2.0.2/log/error_log"
</VirtualHost>

Does anyone have any ideas? 
   

From krisleech at interkonect.com  Sun Mar 25 10:52:59 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Sun, 25 Mar 2007 15:52:59 +0100
Subject: [Mongrel] Mongrel & Mint (PHP related)
Message-ID: <46068CCB.8000901@interkonect.com>

Hi, Does anyone have  the Mint stats package setup with their Rails 
application. I have uploaded Mint to the public folder, but when I try 
and request domain.com/mint/index.php the page is served as a download 
instead of being processed by mod_php. Im guessing this isn't really a 
Mongrel problem but what I actually need to do is prevent Apache 
proxying certain requests to Mongrel. How do I do this?

Many thanks.


From pberry at gmail.com  Sun Mar 25 12:55:16 2007
From: pberry at gmail.com (Patrick Berry)
Date: Sun, 25 Mar 2007 09:55:16 -0700
Subject: [Mongrel] Mongrel & Mint (PHP related)
In-Reply-To: <46068CCB.8000901@interkonect.com>
References: <46068CCB.8000901@interkonect.com>
Message-ID: <ef13ff170703250955u4a47637dm6e09fde2f884aa62@mail.gmail.com>

On 3/25/07, Kris Leech <krisleech at interkonect.com> wrote:
>
> Hi, Does anyone have  the Mint stats package setup with their Rails
> application. I have uploaded Mint to the public folder, but when I try
> and request domain.com/mint/index.php the page is served as a download
> instead of being processed by mod_php. Im guessing this isn't really a
> Mongrel problem but what I actually need to do is prevent Apache
> proxying certain requests to Mongrel. How do I do this?
>
> Many thanks.



The apache docs have some nice info on this:
http://mongrel.rubyforge.org/docs/apache.html

Here are some basic proxypass rules you can add to tell the ProxyPass not to
forward on requests to certain documents/requests:


ProxyPass /images !
ProxyPass /stylesheets !


These directives would go in your VirtualHost config.

Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070325/603ca4a2/attachment.html 

From pberry at gmail.com  Sun Mar 25 13:07:43 2007
From: pberry at gmail.com (Patrick Berry)
Date: Sun, 25 Mar 2007 10:07:43 -0700
Subject: [Mongrel] Can't seem to get rewrite rules to work with Apache
In-Reply-To: <4589053F-0910-484C-B26D-00BB93F164AC@scottwalter.com>
References: <4589053F-0910-484C-B26D-00BB93F164AC@scottwalter.com>
Message-ID: <ef13ff170703251007m517837b0ua38f6e6ccd3cc296@mail.gmail.com>

On 3/24/07, Scott Walter <sw-ng at scottwalter.com> wrote:
>
> Hi,
>
> I'm struggling to get an Apache rewrite rule to work.   I have a
> simple rule that for a request to "a.html" will be sent to "b.html".
> However the requests for "a.html" are always sent to my Rails apps.
> Here is my  Apache configuration:
>
> <VirtualHost 216.154.219.19:80>
>
RewriteRule ^a\.html$ b.html
> </VirtualHost>
>
> Does anyone have any ideas?


If I'm not mistaken you need to tell Apache what to do when the first part
of the rule matches.

RewriteRule ^a\.html$ b.html [R]

Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070325/f7443ac3/attachment-0001.html 

From ry at tinyclouds.org  Sun Mar 25 20:57:54 2007
From: ry at tinyclouds.org (Ry Dahl)
Date: Mon, 26 Mar 2007 02:57:54 +0200
Subject: [Mongrel] Streaming content
Message-ID: <21ee31950703251757u686093afi69e72088b4b734da@mail.gmail.com>

Hello

I'm attempting to write a mongrel plug-in which would stream a response.

At first I was doing this

  def process(request, response)
    response.start do |head,out|
      head['Content-Type'] = 'text/html'
      %w{o m g}.each { |c|  out.puts c; sleep 5; }
    end
    response.done = true
  end

But then I looked at HttpResponse and decided that this probably isn't
sending anything to the socket while I'm in the OMG loop:

    def start(status=200, finalize=false)
      @status = status.to_i
      yield @header, @body
      finished if finalize
    end

So I thought using HttpResponse#write might work -

  def process(request, response)
    %w{o m g}.each { |c| response.write(c); sleep 5; }
    response.done = true
  end

but that also didn't work. How can I stream content?

THANKS!

From noodlet at gmail.com  Mon Mar 26 04:58:46 2007
From: noodlet at gmail.com (Vincent Bray)
Date: Mon, 26 Mar 2007 15:58:46 +0700
Subject: [Mongrel] Can't seem to get rewrite rules to work with Apache
In-Reply-To: <4589053F-0910-484C-B26D-00BB93F164AC@scottwalter.com>
References: <4589053F-0910-484C-B26D-00BB93F164AC@scottwalter.com>
Message-ID: <813716b60703260158v48cbd242kf383fbc9c9114802@mail.gmail.com>

On 25/03/07, Scott Walter <sw-ng at scottwalter.com> wrote:
> Here is my  Apache configuration:
>
> <VirtualHost 216.154.219.19:80>
[snip]
> RewriteEngine On
> RewriteRule ^a\.html$ b.html
[snip]
> </VirtualHost>

Because your rule is in vhost context (and not in your Directory
block) you must include the leading slash. You may also want to bypass
the ProxyPass, or switch to using [P] instead.

ProxyPass /a.html !
ProxyPass /b.html !
ProxyPass / http://127.0.0.1:3002/
ProxyPassReverse / http://127.0.0.1:3002/
ProxyPreserveHost On
RewriteEngine On
RewriteRule ^/a.html /b.html

.. or ..

RewriteEngine On
RewriteCond %{REQUEST_URI} !^(a|b)\.html
RewriteRule . http://127.0.0.1:3002%{REQUEST_URI} [P]
ProxyPassReverse / http://127.0.0.1:3002/
ProxyPreserveHost On

I suspect this question really belongs on an apache support list.

-- 
noodl

From krisleech at interkonect.com  Mon Mar 26 07:46:04 2007
From: krisleech at interkonect.com (Kris Leech)
Date: Mon, 26 Mar 2007 12:46:04 +0100
Subject: [Mongrel] Mongrel & Mint (PHP related)
In-Reply-To: <ef13ff170703250955u4a47637dm6e09fde2f884aa62@mail.gmail.com>
References: <46068CCB.8000901@interkonect.com>
	<ef13ff170703250955u4a47637dm6e09fde2f884aa62@mail.gmail.com>
Message-ID: <4607B27C.5010609@interkonect.com>

Patrick Berry wrote:
>
>
> On 3/25/07, *Kris Leech* <krisleech at interkonect.com 
> <mailto:krisleech at interkonect.com>> wrote:
>
>     Hi, Does anyone have  the Mint stats package setup with their Rails
>     application. I have uploaded Mint to the public folder, but when I try
>     and request domain.com/mint/index.php
>     <http://domain.com/mint/index.php> the page is served as a download
>     instead of being processed by mod_php. Im guessing this isn't really a
>     Mongrel problem but what I actually need to do is prevent Apache
>     proxying certain requests to Mongrel. How do I do this?
>
>     Many thanks.
>
>
>
> The apache docs have some nice info on this:
> http://mongrel.rubyforge.org/docs/apache.html
>
> Here are some basic proxypass rules you can add to tell the ProxyPass 
> not to forward on requests to certain documents/requests:
>
> |
> ProxyPass /images ! 
> ProxyPass /stylesheets ! |
>  
> These directives would go in your VirtualHost config.
Thanks, I set a proxypass for both the mint folder and php-fastcgi 
folder's so they are not proxied. I do not have mint in my Rails public 
folder but in the Apache document root. It works!
>
> Pat
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users



From blindance at gmail.com  Mon Mar 26 08:00:06 2007
From: blindance at gmail.com (blindance at gmail.com)
Date: Mon, 26 Mar 2007 21:00:06 +0900
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
Message-ID: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>

Konnichiwa Mongrel users,


mongrel_service cannot run as a windows service under my environment,
with the windows message :
"error 1053 : The service did not respond to the start or control
request in a timely fashion."



>From a part of "ServiceFB.log" at c:/ruby/bin,
mongrel_service failed to get the process name of "service.exe".

>ServiceController.RunMode()
>CurrentPID: 540
>ParentPID: 716
>Parent Name: <unknown>
>ServiceController.RunMode() done


and a part of "gem list" is ;
>mongrel (1.0.1)
>mongrel_service (0.3.1)
>rails (1.2.3, 1.2.2)
>win32-service (0.5.2)



I guess that the reason is my environment a bit complex and weird,
* Windows XP Professional x64 Version2003 SP1
* over VMWare Server 1.0.1
*   over Windows Server 2003 R2 Standard x64

In fact,
I've confirmed that the mongrel_service and my webapp run well as a
windows service under Windows XP 32bit edition,
and both of
> mongrel_rails start
> mongrel_service console single -c [path/to/mywebapp] -p 3000 -e development
run correctry even on such win64 stacks.


Can anyone shed any light?

From sebastienmaurette at yahoo.fr  Mon Mar 26 09:37:08 2007
From: sebastienmaurette at yahoo.fr (=?ISO-8859-1?Q?S=E9bastien_Maurette?=)
Date: Mon, 26 Mar 2007 14:37:08 +0100
Subject: [Mongrel] upload progress bar don't work...please help
In-Reply-To: <4603B439.7050602@yahoo.fr>
References: <4603B439.7050602@yahoo.fr>
Message-ID: <4607CC84.3060702@yahoo.fr>

Hello,

The problem is solved.
The solution is to turn off the Apache mod_security ...

bye

S?bastien Maurette a ?crit :
> Hello,
>
> I'm trying to install the upload_progress gem and i can't see the upload 
> progress status.
>
> My config is :
>
> apache2 with mod_proxy
> mongrel
> rails
>
> upload.rb : ##############
>
> require 'rubygems'
> require 'drb'
> require 'gem_plugin'
> GemPlugin::Manager.instance.load 'mongrel' => GemPlugin::INCLUDE
> DRb.start_service 'druby://0.0.0.0:2999', Mongrel::UploadProgress.new
> DRb.thread.join
>
> mongrel_upload_progress.conf : ##########
>
> uri "/",
>   :handler => plugin("/handlers/upload",
>                        :path_info => '/files/upload',
>                        :frequency => 1,
>                        :drb => 'druby://0.0.0.0:2999'),
>   :in_front => true
>
> routes.rb :
>
> map.connect '/files/',:controller=>"files"
>
> files_controller : #####################
>
> class FilesController < ApplicationController
>   session :off, :only => :progress
>  
>   def index
>   end
>  
>   def progress
>     render :update do |page|
>       @status = Mongrel::Uploads.check(params[:upload_id])
>       logger.info(params[:upload_id])
>       page.upload_progress.update(@status[:size], @status[:received]) if 
> @status
>     end
>   end
>  
>   def upload
>     render :text => %(UPLOADED: #{params.inspect}.<script 
> type="text/javascript">window.parent.UploadProgress.finish();</script>)
>   end
> end
>
>
> When i try to upload a file i got this log in my production_log :
>
>
> Processing FilesController#progress (for my_IP at 2007-03-23 10:42:56) 
> [POST]
>   Parameters: {"action"=>"progress", "controller"=>"files", 
> "upload_id"=>"1174642904"}
> 1174642904
> Completed in 0.00594 (168 reqs/sec) | Rendering: 0.00572 (96%) | DB: 
> 0.00000 (0%) | 200 OK 
> [http://IP_SERVEUR/files/progress?upload_id=1174642904]
>
>
> Processing FilesController#progress (for my_IP at 2007-03-23 10:42:59) 
> [POST]
>   Parameters: {"action"=>"progress", "controller"=>"files", 
> "upload_id"=>"1174642904"}
> 1174642904
> Completed in 0.00597 (167 reqs/sec) | Rendering: 0.00574 (96%) | DB: 
> 0.00000 (0%) | 200 OK 
> [http://IP_SERVEUR/files/progress?upload_id=1174642904]
>
>
> Processing FilesController#progress (for my_IP at 2007-03-23 10:43:02) 
> [POST]
>   Parameters: {"action"=>"progress", "controller"=>"files", 
> "upload_id"=>"1174642904"}
> 1174642904
> Completed in 0.00892 (112 reqs/sec) | Rendering: 0.00858 (96%) | DB: 
> 0.00000 (0%) | 200 OK 
> [http://IP_SERVEUR/files/progress?upload_id=1174642904]
>
>
> Processing FilesController#progress (for my_IP at 2007-03-23 10:43:05) 
> [POST]
>   Parameters: {"action"=>"progress", "controller"=>"files", 
> "upload_id"=>"1174642904"}
> 1174642904
> Completed in 0.00581 (172 reqs/sec) | Rendering: 0.00558 (96%) | DB: 
> 0.00000 (0%) | 200 OK 
> [http://IP_SERVEUR/files/progress?upload_id=1174642904]
>
>
> Processing FilesController#progress (for my_IP at 2007-03-23 10:43:08) 
> [POST]
>   Parameters: {"action"=>"progress", "controller"=>"files", 
> "upload_id"=>"1174642904"}
> 1174642904
> Completed in 0.00578 (173 reqs/sec) | Rendering: 0.00556 (96%) | DB: 
> 0.00000 (0%) | 200 OK 
> [http://IP_SERVEUR/files/progress?upload_id=1174642904]
>
>
> Processing FilesController#upload (for my_IP at 2007-03-23 10:43:09) [POST]
>   Session ID: 85a4fa5dc5f0c442742c393746455108
>   Parameters: {"commit"=>"Upload", "action"=>"upload", 
> "controller"=>"files", "upload_id"=>"1174642904", 
> "data"=>#<File:/tmp/CGI.6545.0>}
> Completed in 0.00026 (3862 reqs/sec) | Rendering: 0.00006 (22%) | DB: 
> 0.00000 (0%) | 200 OK [http://IP_SERVEUR/files/upload?upload_id=1174642904]
>
>
>
> The @status is always nil.
>
> I don't know what ito do, is anyone have this problem before ?
>
> Thanks for your help.
>
> Seb.
>
> ps: sorry for my english ...
>
>
>
>
>
> 	
>
> 	
> 		
> ___________________________________________________________________________ 
> Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire.
> http://fr.mail.yahoo.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>   

	

	
		
___________________________________________________________________________ 
Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire.
http://fr.mail.yahoo.com

From sw-ng at scottwalter.com  Mon Mar 26 09:14:55 2007
From: sw-ng at scottwalter.com (Scott Walter)
Date: Mon, 26 Mar 2007 08:14:55 -0500
Subject: [Mongrel] Can't seem to get rewrite rules to work with Apache
In-Reply-To: <813716b60703260158v48cbd242kf383fbc9c9114802@mail.gmail.com>
References: <4589053F-0910-484C-B26D-00BB93F164AC@scottwalter.com>
	<813716b60703260158v48cbd242kf383fbc9c9114802@mail.gmail.com>
Message-ID: <52A03AEB-60E6-43A9-AA05-18A89BF98D44@scottwalter.com>

Yeah I know this question probably didn't belong here, but I figured  
some other "Mongrels" have had similar issues and I thought I'd give  
it a try.  Good thing too because your help worked like a champ!   
Thanks.

scott.
On Mar 26, 2007, at 3:58 AM, Vincent Bray wrote:

> On 25/03/07, Scott Walter <sw-ng at scottwalter.com> wrote:
>> Here is my  Apache configuration:
>>
>> <VirtualHost 216.154.219.19:80>
> [snip]
>> RewriteEngine On
>> RewriteRule ^a\.html$ b.html
> [snip]
>> </VirtualHost>
>
> Because your rule is in vhost context (and not in your Directory
> block) you must include the leading slash. You may also want to bypass
> the ProxyPass, or switch to using [P] instead.
>
> ProxyPass /a.html !
> ProxyPass /b.html !
> ProxyPass / http://127.0.0.1:3002/
> ProxyPassReverse / http://127.0.0.1:3002/
> ProxyPreserveHost On
> RewriteEngine On
> RewriteRule ^/a.html /b.html
>
> .. or ..
>
> RewriteEngine On
> RewriteCond %{REQUEST_URI} !^(a|b)\.html
> RewriteRule . http://127.0.0.1:3002%{REQUEST_URI} [P]
> ProxyPassReverse / http://127.0.0.1:3002/
> ProxyPreserveHost On
>
> I suspect this question really belongs on an apache support list.
>
> -- 
> noodl
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From zedshaw at zedshaw.com  Mon Mar 26 10:31:26 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 26 Mar 2007 10:31:26 -0400
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <55c107bf0703200821j681c0b9cl65065d0f82726174@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
	<20070320104415.98b33127.zedshaw@zedshaw.com>
	<55c107bf0703200821j681c0b9cl65065d0f82726174@mail.gmail.com>
Message-ID: <20070326103126.0dde04d0.zedshaw@zedshaw.com>

On Tue, 20 Mar 2007 16:21:44 +0100
"Dimitri Aivaliotis" <aglarond at gmail.com> wrote:

> On 3/20/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> > On Tue, 20 Mar 2007 14:53:39 +0100
> > "Dimitri Aivaliotis" <aglarond at gmail.com> wrote:

> > Make sure you give a full path for all your files you configure.  If
> > not, let me know and I'll check it out.
> 
> I am using full paths: :pid_file => "/tmp/test.pid"
> 
> What other info can I give you to help debug this?

Did you get this resolved Dimitri?  I lost your reply in my queue.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From zedshaw at zedshaw.com  Mon Mar 26 10:57:10 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 26 Mar 2007 10:57:10 -0400
Subject: [Mongrel] Mongrel_Cluster PID File Creation Error.
In-Reply-To: <45DBBA46.9080109@darthik.com>
References: <45DBBA46.9080109@darthik.com>
Message-ID: <20070326105710.9d104f1c.zedshaw@zedshaw.com>

On Tue, 20 Feb 2007 22:19:34 -0500
"donnie at darthik.com" <donnie at darthik.com> wrote:

> Hello,
> 
> Thank you for your development of Mongrel, great job.  :)
> 
> I am using mongrel_cluster, but I have a problem where my rails
> application name includes a "." such as mydomain.com, which causes an
> error when generating the PID file for mongrel.

Hey Donnie, did you try the latest mongrel_cluster to see if this was
fixed?  I believe Bradley fixed it but please double check.

thx

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From luislavena at gmail.com  Mon Mar 26 11:03:52 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 26 Mar 2007 12:03:52 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
Message-ID: <71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>

On 3/26/07, blindance at gmail.com <blindance at gmail.com> wrote:
> Konnichiwa Mongrel users,
>
>
> mongrel_service cannot run as a windows service under my environment,
> with the windows message :
> "error 1053 : The service did not respond to the start or control
> request in a timely fashion."
>
>
>
> >From a part of "ServiceFB.log" at c:/ruby/bin,
> mongrel_service failed to get the process name of "service.exe".
>
> >ServiceController.RunMode()
> >CurrentPID: 540
> >ParentPID: 716
> >Parent Name: <unknown>
> >ServiceController.RunMode() done
>

Ok, it seems WinAPI behaves different on x64 environment compared to
normal 32bits.

Please note that ruby, mongrel and mongrel_service are 32bits
compilation, that will require some compatibility layer to run over
x64 Windows.

services run under windows (32bits) with "services.exe" as parent
process. Could you use ProcessExplorer [1] to check other services
working and who its process parent?

[1] http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx

>
> and a part of "gem list" is ;
> >mongrel (1.0.1)
> >mongrel_service (0.3.1)
> >rails (1.2.3, 1.2.2)
> >win32-service (0.5.2)
>
>
>
> I guess that the reason is my environment a bit complex and weird,
> * Windows XP Professional x64 Version2003 SP1
> * over VMWare Server 1.0.1
> *   over Windows Server 2003 R2 Standard x64
>
> In fact,
> I've confirmed that the mongrel_service and my webapp run well as a
> windows service under Windows XP 32bit edition,
> and both of
> > mongrel_rails start
> > mongrel_service console single -c [path/to/mywebapp] -p 3000 -e development
> run correctry even on such win64 stacks.
>
>
> Can anyone shed any light?

forcing mongrel_service to start in console mode will work always,
since the "magic trick" used to get parent process isn't used at all.

on Win32, services run as child process (spawned) by "services.exe" =>
"Services and Controller app"

I guess that's the problem under x64.

I attached a 7z file with proc_info.exe, which will test if the WinAPI
used works. Please run it front the command line, the expected output
will be:

this process (PID, name): 3484, proc_info.exe
parent process (PID, name): 3924, cmd.exe

If that works, that means the Services and Controller application
(services.exe) is named differently under x64, or due 32bits
compatibility run as child process of _another_ process :-P

With that information I could patch mongrel_service current version :-)

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_info.7z
Type: application/octet-stream
Size: 8458 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070326/69e7c7e5/attachment-0001.obj 

From carl.lerche at gmail.com  Mon Mar 26 16:02:57 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Mon, 26 Mar 2007 13:02:57 -0700
Subject: [Mongrel] Monit + Mongrel woes
Message-ID: <ab90312e0703261302k4f448194l79dff7162592a8b6@mail.gmail.com>

Hello all,

So, I've been using monit with mongrel for a while now, since the
0.3.x days (I think it was). It used to work fine, but now I seem to
be having some trouble. I'm currently using mongrel 1.0.1 and I am
using the same monit configuration I've always been using, yet
everytime monit should restart mongrel, I get "Execution failed".

For the start command, I originally used the following:
------------
start program = "/usr/bin/su admin -c '/usr/local/bin/mongrel_rails
start -d -e production -p 8001 -a 127.0.0.1 -c
/home/admin/webapps/gohuman/current -P log/mongrel.8001.pid'"
------------
But then monit started giving me execution failed errors and when I
tried to run it manually I got a "PID already exists" error. So, I
tried the following:
------------
start program = "/bin/rm -f
/home/admin/webapps/gohuman/shared/log/mongrel.8001.pid && /usr/bin/su
admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
-a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
log/mongrel.8001.pid'"
------------
Which just adds the rm at the start. Yet, monit still can't manage to
restart mongrel. I have no idea why. This is my full monit file

------------
##### mongrel 8000 - GoHuman #####
check process mongrel-8000 with pidfile
/home/admin/webapps/gohuman/shared/log/mongrel.8000.pid
    start program = "/bin/rm -f
/home/admin/webapps/gohuman/shared/log/mongrel.8000.pid && /usr/bin/su
admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8000
-a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
log/mongrel.8000.pid'"
    stop program  = "/usr/bin/su admin -c
'/usr/local/bin/mongrel_rails stop -c
/home/admin/webapps/gohuman/current -P log/mongrel.8000.pid'"

    if totalmem is greater than 80.0 MB for 5 cycles then alert
 # eating up memory?
    if cpu is greater than 50% for 2 cycles then alert
 # send an email to admin
    if cpu is greater than 80% for 3 cycles then restart
 # hung process?
    if loadavg(5min) greater than 10 for 8 cycles then restart
 # bad, bad, bad
    if 3 restarts within 5 cycles then timeout
 # something is wrong, call the sys-admin

    group gohuman

##### mongrel 8001 - GoHuman #####
check process mongrel-8001 with pidfile
/home/admin/webapps/gohuman/shared/log/mongrel.8001.pid
    start program = "/bin/rm -f
/home/admin/webapps/gohuman/shared/log/mongrel.8001.pid && /usr/bin/su
admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
-a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
log/mongrel.8001.pid'"
    stop program  = "/usr/bin/su admin -c
'/usr/local/bin/mongrel_rails stop -c
/home/admin/webapps/gohuman/current -P log/mongrel.8001.pid'"

    if totalmem is greater than 80.0 MB for 5 cycles then alert
 # eating up memory?
    if cpu is greater than 50% for 2 cycles then alert
 # send an email to admin
    if cpu is greater than 80% for 3 cycles then restart
 # hung process?
    if loadavg(5min) greater than 10 for 8 cycles then restart
 # bad, bad, bad
    if 3 restarts within 5 cycles then timeout
 # something is wrong, call the sys-admin

    group gohuman

##### mongrel 8002 - GoHuman #####
check process mongrel-8002 with pidfile
/home/admin/webapps/gohuman/shared/log/mongrel.8002.pid
    start program = "/bin/rm -f
/home/admin/webapps/gohuman/shared/log/mongrel.8002.pid && /usr/bin/su
admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8002
-a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
log/mongrel.8002.pid'"
    stop program  = "/usr/bin/su admin -c
'/usr/local/bin/mongrel_rails stop -c
/home/admin/webapps/gohuman/current -P log/mongrel.8002.pid'"

    if totalmem is greater than 80.0 MB for 5 cycles then alert
 # eating up memory?
    if cpu is greater than 50% for 2 cycles then alert
 # send an email to admin
    if cpu is greater than 80% for 3 cycles then restart
 # hung process?
    if loadavg(5min) greater than 10 for 8 cycles then restart
 # bad, bad, bad
    if 3 restarts within 5 cycles then timeout
 # something is wrong, call the sys-admin

    group gohuman
------------

Thanks,
-carl
-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From jgeiger at gmail.com  Mon Mar 26 17:05:51 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Mon, 26 Mar 2007 16:05:51 -0500
Subject: [Mongrel] Monit + Mongrel woes
In-Reply-To: <ab90312e0703261302k4f448194l79dff7162592a8b6@mail.gmail.com>
References: <ab90312e0703261302k4f448194l79dff7162592a8b6@mail.gmail.com>
Message-ID: <466af3440703261405k1c6c2ef9oc40bdb11f9407037@mail.gmail.com>

If you're not using mongrel_cluster, you might want to look into using it.

If you are, I would suggest rewriting your monit scripts to deal with
the new pid file location, and such.

The new mongrel_cluster can handle the leftover pid files, and will
clean them up before attempting to restart.

On 3/26/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> Hello all,
>
> So, I've been using monit with mongrel for a while now, since the
> 0.3.x days (I think it was). It used to work fine, but now I seem to
> be having some trouble. I'm currently using mongrel 1.0.1 and I am
> using the same monit configuration I've always been using, yet
> everytime monit should restart mongrel, I get "Execution failed".
>
> For the start command, I originally used the following:
> ------------
> start program = "/usr/bin/su admin -c '/usr/local/bin/mongrel_rails
> start -d -e production -p 8001 -a 127.0.0.1 -c
> /home/admin/webapps/gohuman/current -P log/mongrel.8001.pid'"
> ------------
> But then monit started giving me execution failed errors and when I
> tried to run it manually I got a "PID already exists" error. So, I
> tried the following:
> ------------
> start program = "/bin/rm -f
> /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid && /usr/bin/su
> admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
> -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> log/mongrel.8001.pid'"
> ------------
> Which just adds the rm at the start. Yet, monit still can't manage to
> restart mongrel. I have no idea why. This is my full monit file
>
> ------------
> ##### mongrel 8000 - GoHuman #####
> check process mongrel-8000 with pidfile
> /home/admin/webapps/gohuman/shared/log/mongrel.8000.pid
>     start program = "/bin/rm -f
> /home/admin/webapps/gohuman/shared/log/mongrel.8000.pid && /usr/bin/su
> admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8000
> -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> log/mongrel.8000.pid'"
>     stop program  = "/usr/bin/su admin -c
> '/usr/local/bin/mongrel_rails stop -c
> /home/admin/webapps/gohuman/current -P log/mongrel.8000.pid'"
>
>     if totalmem is greater than 80.0 MB for 5 cycles then alert
>  # eating up memory?
>     if cpu is greater than 50% for 2 cycles then alert
>  # send an email to admin
>     if cpu is greater than 80% for 3 cycles then restart
>  # hung process?
>     if loadavg(5min) greater than 10 for 8 cycles then restart
>  # bad, bad, bad
>     if 3 restarts within 5 cycles then timeout
>  # something is wrong, call the sys-admin
>
>     group gohuman
>
> ##### mongrel 8001 - GoHuman #####
> check process mongrel-8001 with pidfile
> /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid
>     start program = "/bin/rm -f
> /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid && /usr/bin/su
> admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
> -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> log/mongrel.8001.pid'"
>     stop program  = "/usr/bin/su admin -c
> '/usr/local/bin/mongrel_rails stop -c
> /home/admin/webapps/gohuman/current -P log/mongrel.8001.pid'"
>
>     if totalmem is greater than 80.0 MB for 5 cycles then alert
>  # eating up memory?
>     if cpu is greater than 50% for 2 cycles then alert
>  # send an email to admin
>     if cpu is greater than 80% for 3 cycles then restart
>  # hung process?
>     if loadavg(5min) greater than 10 for 8 cycles then restart
>  # bad, bad, bad
>     if 3 restarts within 5 cycles then timeout
>  # something is wrong, call the sys-admin
>
>     group gohuman
>
> ##### mongrel 8002 - GoHuman #####
> check process mongrel-8002 with pidfile
> /home/admin/webapps/gohuman/shared/log/mongrel.8002.pid
>     start program = "/bin/rm -f
> /home/admin/webapps/gohuman/shared/log/mongrel.8002.pid && /usr/bin/su
> admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8002
> -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> log/mongrel.8002.pid'"
>     stop program  = "/usr/bin/su admin -c
> '/usr/local/bin/mongrel_rails stop -c
> /home/admin/webapps/gohuman/current -P log/mongrel.8002.pid'"
>
>     if totalmem is greater than 80.0 MB for 5 cycles then alert
>  # eating up memory?
>     if cpu is greater than 50% for 2 cycles then alert
>  # send an email to admin
>     if cpu is greater than 80% for 3 cycles then restart
>  # hung process?
>     if loadavg(5min) greater than 10 for 8 cycles then restart
>  # bad, bad, bad
>     if 3 restarts within 5 cycles then timeout
>  # something is wrong, call the sys-admin
>
>     group gohuman
> ------------
>
> Thanks,
> -carl
> --
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From carl.lerche at gmail.com  Mon Mar 26 17:52:04 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Mon, 26 Mar 2007 14:52:04 -0700
Subject: [Mongrel] Monit + Mongrel woes
In-Reply-To: <466af3440703261405k1c6c2ef9oc40bdb11f9407037@mail.gmail.com>
References: <ab90312e0703261302k4f448194l79dff7162592a8b6@mail.gmail.com>
	<466af3440703261405k1c6c2ef9oc40bdb11f9407037@mail.gmail.com>
Message-ID: <ab90312e0703261452k10b64bdcj22c3456d50be1302@mail.gmail.com>

Hello,

How would I tell mongrel_cluster to restart a single mongrel instance
(if only one of them failed? Do you have an example of a monitrc file
that uses mongrel_cluster?

Thanks,
-carl

On 3/26/07, Joey Geiger <jgeiger at gmail.com> wrote:
> If you're not using mongrel_cluster, you might want to look into using it.
>
> If you are, I would suggest rewriting your monit scripts to deal with
> the new pid file location, and such.
>
> The new mongrel_cluster can handle the leftover pid files, and will
> clean them up before attempting to restart.
>
> On 3/26/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> > Hello all,
> >
> > So, I've been using monit with mongrel for a while now, since the
> > 0.3.x days (I think it was). It used to work fine, but now I seem to
> > be having some trouble. I'm currently using mongrel 1.0.1 and I am
> > using the same monit configuration I've always been using, yet
> > everytime monit should restart mongrel, I get "Execution failed".
> >
> > For the start command, I originally used the following:
> > ------------
> > start program = "/usr/bin/su admin -c '/usr/local/bin/mongrel_rails
> > start -d -e production -p 8001 -a 127.0.0.1 -c
> > /home/admin/webapps/gohuman/current -P log/mongrel.8001.pid'"
> > ------------
> > But then monit started giving me execution failed errors and when I
> > tried to run it manually I got a "PID already exists" error. So, I
> > tried the following:
> > ------------
> > start program = "/bin/rm -f
> > /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid && /usr/bin/su
> > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
> > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> > log/mongrel.8001.pid'"
> > ------------
> > Which just adds the rm at the start. Yet, monit still can't manage to
> > restart mongrel. I have no idea why. This is my full monit file
> >
> > ------------
> > ##### mongrel 8000 - GoHuman #####
> > check process mongrel-8000 with pidfile
> > /home/admin/webapps/gohuman/shared/log/mongrel.8000.pid
> >     start program = "/bin/rm -f
> > /home/admin/webapps/gohuman/shared/log/mongrel.8000.pid && /usr/bin/su
> > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8000
> > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> > log/mongrel.8000.pid'"
> >     stop program  = "/usr/bin/su admin -c
> > '/usr/local/bin/mongrel_rails stop -c
> > /home/admin/webapps/gohuman/current -P log/mongrel.8000.pid'"
> >
> >     if totalmem is greater than 80.0 MB for 5 cycles then alert
> >  # eating up memory?
> >     if cpu is greater than 50% for 2 cycles then alert
> >  # send an email to admin
> >     if cpu is greater than 80% for 3 cycles then restart
> >  # hung process?
> >     if loadavg(5min) greater than 10 for 8 cycles then restart
> >  # bad, bad, bad
> >     if 3 restarts within 5 cycles then timeout
> >  # something is wrong, call the sys-admin
> >
> >     group gohuman
> >
> > ##### mongrel 8001 - GoHuman #####
> > check process mongrel-8001 with pidfile
> > /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid
> >     start program = "/bin/rm -f
> > /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid && /usr/bin/su
> > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
> > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> > log/mongrel.8001.pid'"
> >     stop program  = "/usr/bin/su admin -c
> > '/usr/local/bin/mongrel_rails stop -c
> > /home/admin/webapps/gohuman/current -P log/mongrel.8001.pid'"
> >
> >     if totalmem is greater than 80.0 MB for 5 cycles then alert
> >  # eating up memory?
> >     if cpu is greater than 50% for 2 cycles then alert
> >  # send an email to admin
> >     if cpu is greater than 80% for 3 cycles then restart
> >  # hung process?
> >     if loadavg(5min) greater than 10 for 8 cycles then restart
> >  # bad, bad, bad
> >     if 3 restarts within 5 cycles then timeout
> >  # something is wrong, call the sys-admin
> >
> >     group gohuman
> >
> > ##### mongrel 8002 - GoHuman #####
> > check process mongrel-8002 with pidfile
> > /home/admin/webapps/gohuman/shared/log/mongrel.8002.pid
> >     start program = "/bin/rm -f
> > /home/admin/webapps/gohuman/shared/log/mongrel.8002.pid && /usr/bin/su
> > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8002
> > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> > log/mongrel.8002.pid'"
> >     stop program  = "/usr/bin/su admin -c
> > '/usr/local/bin/mongrel_rails stop -c
> > /home/admin/webapps/gohuman/current -P log/mongrel.8002.pid'"
> >
> >     if totalmem is greater than 80.0 MB for 5 cycles then alert
> >  # eating up memory?
> >     if cpu is greater than 50% for 2 cycles then alert
> >  # send an email to admin
> >     if cpu is greater than 80% for 3 cycles then restart
> >  # hung process?
> >     if loadavg(5min) greater than 10 for 8 cycles then restart
> >  # bad, bad, bad
> >     if 3 restarts within 5 cycles then timeout
> >  # something is wrong, call the sys-admin
> >
> >     group gohuman
> > ------------
> >
> > Thanks,
> > -carl
> > --
> > EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> > _______________________________________________
> > 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
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From blindance at gmail.com  Tue Mar 27 07:17:45 2007
From: blindance at gmail.com (blindance at gmail.com)
Date: Tue, 27 Mar 2007 20:17:45 +0900
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
Message-ID: <474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>

Thank you very much for your cooperation and sooner response,


>services run under windows (32bits) with "services.exe" as parent
>process. Could you use ProcessExplorer [1] to check other services
>working and who its process parent?


Yes, as same as Win32,
"services.exe" is the parent process of "svchost.exe", "snmp.exe" ,
"mysqld-nt.exe", "VMwareService.exe", etc.
and only "services.exe" and "svchost.exe" is 64-bit image.

I'm sorry that "service.exe" in the subject is a TYPO.



>I attached a 7z file with proc_info.exe, which will test if the WinAPI
>used works. Please run it front the command line, the expected output
>will be:

The result is :
 this process (PID, name): 2192, proc_info.exe
 parent process (PID, name): 3024, <unknown>


"<unknown>" is the error or the warning word returned by
"_process_name" function of ServiceFB.
and "_process_name" function uses Win32API "HANDLE" typedef via FreeBasic libs,
and the size of HANDLE of Win32API differs from the other one of Win64API.

so, if "proc_info.exe" is getting its process name without its PID,
I guess that the root of this compatibility problem will exist around here.
#if so, Perhaps I should not be bothering you with this...



> If that works, that means the Services and Controller application
> (services.exe) is named differently under x64, or due 32bits
> compatibility run as child process of _another_ process :-P
> With that information I could patch mongrel_service current version :-)

mmm, How about these results?


Sincerely,

From luislavena at gmail.com  Tue Mar 27 07:44:46 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 27 Mar 2007 08:44:46 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
Message-ID: <71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>

On 3/27/07, blindance at gmail.com <blindance at gmail.com> wrote:
> Thank you very much for your cooperation and sooner response,
>
>
> >services run under windows (32bits) with "services.exe" as parent
> >process. Could you use ProcessExplorer [1] to check other services
> >working and who its process parent?
>
>
> Yes, as same as Win32,
> "services.exe" is the parent process of "svchost.exe", "snmp.exe" ,
> "mysqld-nt.exe", "VMwareService.exe", etc.
> and only "services.exe" and "svchost.exe" is 64-bit image.
>
> I'm sorry that "service.exe" in the subject is a TYPO.
>

The typo wasn't a problem ;-)

>
>
> >I attached a 7z file with proc_info.exe, which will test if the WinAPI
> >used works. Please run it front the command line, the expected output
> >will be:
>
> The result is :
>  this process (PID, name): 2192, proc_info.exe
>  parent process (PID, name): 3024, <unknown>
>
>
> "<unknown>" is the error or the warning word returned by
> "_process_name" function of ServiceFB.
> and "_process_name" function uses Win32API "HANDLE" typedef via FreeBasic libs,
> and the size of HANDLE of Win32API differs from the other one of Win64API.
>

Actually, by default _process_name uses "<unknown>" as default string,
since some cases getting process name seems to fail... like in *this*
case.

_process_name is used for both calls, one getting
_process_name(GetCurrentProcessId()) and the second getting
_process_name from _parent_process(GetCurrentProcessId())

> so, if "proc_info.exe" is getting its process name without its PID,
> I guess that the root of this compatibility problem will exist around here.
> #if so, Perhaps I should not be bothering you with this...
>

If Parent PID number (3024) matched cmd.exe in this case, it seems the
problem isn't related to _process_name.

>
>
> > If that works, that means the Services and Controller application
> > (services.exe) is named differently under x64, or due 32bits
> > compatibility run as child process of _another_ process :-P
> > With that information I could patch mongrel_service current version :-)
>
> mmm, How about these results?
>
>

These shows me almost every function is working, but maybe enumerating
running process (using PSAPI) is failing.

I'll try to GDB tonight and compare 32bits with x64 API callings.

Thanks for your reply :-)

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From ry at tinyclouds.org  Tue Mar 27 10:15:54 2007
From: ry at tinyclouds.org (Ry Dahl)
Date: Tue, 27 Mar 2007 16:15:54 +0200
Subject: [Mongrel] Streaming content
In-Reply-To: <21ee31950703251757u686093afi69e72088b4b734da@mail.gmail.com>
References: <21ee31950703251757u686093afi69e72088b4b734da@mail.gmail.com>
Message-ID: <21ee31950703270715h33212a66hcccd2df9bf2d104c@mail.gmail.com>

If attempting to circumvent a web server's writing procedures, be sure
to send the HTTP headers yourself!

(i'm an idiot)

thanks for listening,
ry


On 3/26/07, Ry Dahl <ry at tinyclouds.org> wrote:
> Hello
>
> I'm attempting to write a mongrel plug-in which would stream a response.
>
> At first I was doing this
>
>   def process(request, response)
>     response.start do |head,out|
>       head['Content-Type'] = 'text/html'
>       %w{o m g}.each { |c|  out.puts c; sleep 5; }
>     end
>     response.done = true
>   end
>
> But then I looked at HttpResponse and decided that this probably isn't
> sending anything to the socket while I'm in the OMG loop:
>
>     def start(status=200, finalize=false)
>       @status = status.to_i
>       yield @header, @body
>       finished if finalize
>     end
>
> So I thought using HttpResponse#write might work -
>
>   def process(request, response)
>     %w{o m g}.each { |c| response.write(c); sleep 5; }
>     response.done = true
>   end
>
> but that also didn't work. How can I stream content?
>
> THANKS!
>


-- 
+1.760.536.4191

From bradley at railsmachine.com  Tue Mar 27 11:06:46 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Tue, 27 Mar 2007 11:06:46 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>
References: <45FFF558.2090908@railsmachine.com>
	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>
Message-ID: <46093306.1000307@railsmachine.com>

Hi Michele:

Thanks for the freebsd report. I think there is a way for you to mount 
/proc to support linux process environment emulation.

I'll also gladly accept a patch from anyone for 'ps' syntax that cause 
this warning.

I think we'll release it as is today and due a quick patch if someone 
provides a fix.

Regards,
Bradley Taylor
http://railsmachine.com

Michele wrote:
> Bradley,
> 
> It seems to work on FreeBSD (I had to delete all gems before it  
> actually worked), even though I still get this:
> 
> Checking all mongrel_clusters...
> mongrel_rails cluster::status -C config.yml
> ps: Process environment requires procfs(5)
> ps: Process environment requires procfs(5)
> ps: Process environment requires procfs(5)
> ps: Process environment requires procfs(5)
> ps: Process environment requires procfs(5)
> 
> Best,
> - MF
> 
> --
> Michele Finotto
> http://finotto.org/
> http://16bugs.com/
> http://pagety.com/
> 
> 
> On Mar 20, 2007, at 15:53 , Bradley Taylor wrote:
> 
>> Hi all...
>>
>> Hopefully this is the last prelease. If people on non-linux systems
>> could post back any problems with cluster::status, I'd appreciate it.
>>
>> Install with:
>> gem install mongrel_cluster --source http://mongrel.rubyforge.org/ 
>> releases/
>>
>> Note: This is only an update to mongrel_cluster and not Mongrel or  
>> other
>> gems.
>>
>> Details about what's new (if you missed the first prerelease):
>> http://blog.railsmachine.com/2007/2/26/mongrel_cluster- 
>> prerelease-1-0-1-1
>>
>> Thanks,
>> Bradley Taylor
>> http://railsmachine.com
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From carl.lerche at gmail.com  Tue Mar 27 12:01:44 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Tue, 27 Mar 2007 09:01:44 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <46093306.1000307@railsmachine.com>
References: <45FFF558.2090908@railsmachine.com>
	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>
	<46093306.1000307@railsmachine.com>
Message-ID: <ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>

Hello,

I'm not sure if it's a slight bug with mongrel_cluster or me, but I'm
having some trouble running mongrel cluster with --clean in different
directories than the root of the rails app.

It doesn't look like mongrel_cluster changes the working directory
anywhere (based off of the config file, but just passes the working
directory on to mongrel_rails. This is fine, except when it tries to
check the pid files. Does this make sense?

thanks,
-carl

On 3/27/07, Bradley Taylor <bradley at railsmachine.com> wrote:
> Hi Michele:
>
> Thanks for the freebsd report. I think there is a way for you to mount
> /proc to support linux process environment emulation.
>
> I'll also gladly accept a patch from anyone for 'ps' syntax that cause
> this warning.
>
> I think we'll release it as is today and due a quick patch if someone
> provides a fix.
>
> Regards,
> Bradley Taylor
> http://railsmachine.com
>
> Michele wrote:
> > Bradley,
> >
> > It seems to work on FreeBSD (I had to delete all gems before it
> > actually worked), even though I still get this:
> >
> > Checking all mongrel_clusters...
> > mongrel_rails cluster::status -C config.yml
> > ps: Process environment requires procfs(5)
> > ps: Process environment requires procfs(5)
> > ps: Process environment requires procfs(5)
> > ps: Process environment requires procfs(5)
> > ps: Process environment requires procfs(5)
> >
> > Best,
> > - MF
> >
> > --
> > Michele Finotto
> > http://finotto.org/
> > http://16bugs.com/
> > http://pagety.com/
> >
> >
> > On Mar 20, 2007, at 15:53 , Bradley Taylor wrote:
> >
> >> Hi all...
> >>
> >> Hopefully this is the last prelease. If people on non-linux systems
> >> could post back any problems with cluster::status, I'd appreciate it.
> >>
> >> Install with:
> >> gem install mongrel_cluster --source http://mongrel.rubyforge.org/
> >> releases/
> >>
> >> Note: This is only an update to mongrel_cluster and not Mongrel or
> >> other
> >> gems.
> >>
> >> Details about what's new (if you missed the first prerelease):
> >> http://blog.railsmachine.com/2007/2/26/mongrel_cluster-
> >> prerelease-1-0-1-1
> >>
> >> Thanks,
> >> Bradley Taylor
> >> http://railsmachine.com
> >
> > _______________________________________________
> > 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
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From atmos at atmos.org  Tue Mar 27 12:16:41 2007
From: atmos at atmos.org (Corey Donohoe)
Date: Tue, 27 Mar 2007 11:16:41 -0500
Subject: [Mongrel] Monit + Mongrel woes
In-Reply-To: <ab90312e0703261452k10b64bdcj22c3456d50be1302@mail.gmail.com>
References: <ab90312e0703261302k4f448194l79dff7162592a8b6@mail.gmail.com>
	<466af3440703261405k1c6c2ef9oc40bdb11f9407037@mail.gmail.com>
	<ab90312e0703261452k10b64bdcj22c3456d50be1302@mail.gmail.com>
Message-ID: <c75e5f320703270916r13e2ea65hee04c10e146938d5@mail.gmail.com>

Upload your mongrel_cluster.yml here
http://monitr.atmos.org/generators/mongrel_cluster

sudo gem install mongrel_cluster --source
http://mongrel.rubyforge.org/releases/ && gem cleanup

That should get you going in the right direction.

On 3/26/07, Carl Lerche <carl.lerche at gmail.com> wrote:
>
> Hello,
>
> How would I tell mongrel_cluster to restart a single mongrel instance
> (if only one of them failed? Do you have an example of a monitrc file
> that uses mongrel_cluster?
>
> Thanks,
> -carl
>
> On 3/26/07, Joey Geiger <jgeiger at gmail.com> wrote:
> > If you're not using mongrel_cluster, you might want to look into using
> it.
> >
> > If you are, I would suggest rewriting your monit scripts to deal with
> > the new pid file location, and such.
> >
> > The new mongrel_cluster can handle the leftover pid files, and will
> > clean them up before attempting to restart.
> >
> > On 3/26/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> > > Hello all,
> > >
> > > So, I've been using monit with mongrel for a while now, since the
> > > 0.3.x days (I think it was). It used to work fine, but now I seem to
> > > be having some trouble. I'm currently using mongrel 1.0.1 and I am
> > > using the same monit configuration I've always been using, yet
> > > everytime monit should restart mongrel, I get "Execution failed".
> > >
> > > For the start command, I originally used the following:
> > > ------------
> > > start program = "/usr/bin/su admin -c '/usr/local/bin/mongrel_rails
> > > start -d -e production -p 8001 -a 127.0.0.1 -c
> > > /home/admin/webapps/gohuman/current -P log/mongrel.8001.pid'"
> > > ------------
> > > But then monit started giving me execution failed errors and when I
> > > tried to run it manually I got a "PID already exists" error. So, I
> > > tried the following:
> > > ------------
> > > start program = "/bin/rm -f
> > > /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid && /usr/bin/su
> > > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
> > > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> > > log/mongrel.8001.pid'"
> > > ------------
> > > Which just adds the rm at the start. Yet, monit still can't manage to
> > > restart mongrel. I have no idea why. This is my full monit file
> > >
> > > ------------
> > > ##### mongrel 8000 - GoHuman #####
> > > check process mongrel-8000 with pidfile
> > > /home/admin/webapps/gohuman/shared/log/mongrel.8000.pid
> > >     start program = "/bin/rm -f
> > > /home/admin/webapps/gohuman/shared/log/mongrel.8000.pid && /usr/bin/su
> > > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8000
> > > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> > > log/mongrel.8000.pid'"
> > >     stop program  = "/usr/bin/su admin -c
> > > '/usr/local/bin/mongrel_rails stop -c
> > > /home/admin/webapps/gohuman/current -P log/mongrel.8000.pid'"
> > >
> > >     if totalmem is greater than 80.0 MB for 5 cycles then alert
> > >  # eating up memory?
> > >     if cpu is greater than 50% for 2 cycles then alert
> > >  # send an email to admin
> > >     if cpu is greater than 80% for 3 cycles then restart
> > >  # hung process?
> > >     if loadavg(5min) greater than 10 for 8 cycles then restart
> > >  # bad, bad, bad
> > >     if 3 restarts within 5 cycles then timeout
> > >  # something is wrong, call the sys-admin
> > >
> > >     group gohuman
> > >
> > > ##### mongrel 8001 - GoHuman #####
> > > check process mongrel-8001 with pidfile
> > > /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid
> > >     start program = "/bin/rm -f
> > > /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid && /usr/bin/su
> > > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
> > > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> > > log/mongrel.8001.pid'"
> > >     stop program  = "/usr/bin/su admin -c
> > > '/usr/local/bin/mongrel_rails stop -c
> > > /home/admin/webapps/gohuman/current -P log/mongrel.8001.pid'"
> > >
> > >     if totalmem is greater than 80.0 MB for 5 cycles then alert
> > >  # eating up memory?
> > >     if cpu is greater than 50% for 2 cycles then alert
> > >  # send an email to admin
> > >     if cpu is greater than 80% for 3 cycles then restart
> > >  # hung process?
> > >     if loadavg(5min) greater than 10 for 8 cycles then restart
> > >  # bad, bad, bad
> > >     if 3 restarts within 5 cycles then timeout
> > >  # something is wrong, call the sys-admin
> > >
> > >     group gohuman
> > >
> > > ##### mongrel 8002 - GoHuman #####
> > > check process mongrel-8002 with pidfile
> > > /home/admin/webapps/gohuman/shared/log/mongrel.8002.pid
> > >     start program = "/bin/rm -f
> > > /home/admin/webapps/gohuman/shared/log/mongrel.8002.pid && /usr/bin/su
> > > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8002
> > > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current -P
> > > log/mongrel.8002.pid'"
> > >     stop program  = "/usr/bin/su admin -c
> > > '/usr/local/bin/mongrel_rails stop -c
> > > /home/admin/webapps/gohuman/current -P log/mongrel.8002.pid'"
> > >
> > >     if totalmem is greater than 80.0 MB for 5 cycles then alert
> > >  # eating up memory?
> > >     if cpu is greater than 50% for 2 cycles then alert
> > >  # send an email to admin
> > >     if cpu is greater than 80% for 3 cycles then restart
> > >  # hung process?
> > >     if loadavg(5min) greater than 10 for 8 cycles then restart
> > >  # bad, bad, bad
> > >     if 3 restarts within 5 cycles then timeout
> > >  # something is wrong, call the sys-admin
> > >
> > >     group gohuman
> > > ------------
> > >
> > > Thanks,
> > > -carl
> > > --
> > > EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> > > _______________________________________________
> > > 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
> >
>
>
> --
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Corey Donohoe
http://www.atmos.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070327/76866f74/attachment.html 

From alexey.verkhovsky at gmail.com  Tue Mar 27 12:56:37 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 27 Mar 2007 10:56:37 -0600
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
References: <45FFF558.2090908@railsmachine.com>
	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>
	<46093306.1000307@railsmachine.com>
	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
Message-ID: <3945c4270703270956h18dc36b0ub4857329c8ba7707@mail.gmail.com>

On 3/27/07, Carl Lerche <carl.lerche at gmail.com> wrote:
>
> It doesn't look like mongrel_cluster changes the working directory
> anywhere (based off of the config file, but just passes the working
> directory on to mongrel_rails. This is fine, except when it tries to
> check the pid files.


 is that pid files or pid files directory? In the latter case, there is a
bug in Mongrel where this check is done before changing into the current
working directory specified in the command-line options.

I actually sent Zed a patch that would fix this a coupe of days ago.

See
http://rubyforge.org/tracker/?func=detail&aid=9326&group_id=1306&atid=5145

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070327/e8dfe922/attachment.html 

From carl.lerche at gmail.com  Tue Mar 27 12:59:44 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Tue, 27 Mar 2007 09:59:44 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
References: <45FFF558.2090908@railsmachine.com>
	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>
	<46093306.1000307@railsmachine.com>
	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
Message-ID: <ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>

For me, I fixed this problem by adding the following on line 79 of init.rb:

Dir.chdir(@options["cwd"]) if @options["cwd"]

-carl

On 3/27/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> Hello,
>
> I'm not sure if it's a slight bug with mongrel_cluster or me, but I'm
> having some trouble running mongrel cluster with --clean in different
> directories than the root of the rails app.
>
> It doesn't look like mongrel_cluster changes the working directory
> anywhere (based off of the config file, but just passes the working
> directory on to mongrel_rails. This is fine, except when it tries to
> check the pid files. Does this make sense?
>
> thanks,
> -carl
>
> On 3/27/07, Bradley Taylor <bradley at railsmachine.com> wrote:
> > Hi Michele:
> >
> > Thanks for the freebsd report. I think there is a way for you to mount
> > /proc to support linux process environment emulation.
> >
> > I'll also gladly accept a patch from anyone for 'ps' syntax that cause
> > this warning.
> >
> > I think we'll release it as is today and due a quick patch if someone
> > provides a fix.
> >
> > Regards,
> > Bradley Taylor
> > http://railsmachine.com
> >
> > Michele wrote:
> > > Bradley,
> > >
> > > It seems to work on FreeBSD (I had to delete all gems before it
> > > actually worked), even though I still get this:
> > >
> > > Checking all mongrel_clusters...
> > > mongrel_rails cluster::status -C config.yml
> > > ps: Process environment requires procfs(5)
> > > ps: Process environment requires procfs(5)
> > > ps: Process environment requires procfs(5)
> > > ps: Process environment requires procfs(5)
> > > ps: Process environment requires procfs(5)
> > >
> > > Best,
> > > - MF
> > >
> > > --
> > > Michele Finotto
> > > http://finotto.org/
> > > http://16bugs.com/
> > > http://pagety.com/
> > >
> > >
> > > On Mar 20, 2007, at 15:53 , Bradley Taylor wrote:
> > >
> > >> Hi all...
> > >>
> > >> Hopefully this is the last prelease. If people on non-linux systems
> > >> could post back any problems with cluster::status, I'd appreciate it.
> > >>
> > >> Install with:
> > >> gem install mongrel_cluster --source http://mongrel.rubyforge.org/
> > >> releases/
> > >>
> > >> Note: This is only an update to mongrel_cluster and not Mongrel or
> > >> other
> > >> gems.
> > >>
> > >> Details about what's new (if you missed the first prerelease):
> > >> http://blog.railsmachine.com/2007/2/26/mongrel_cluster-
> > >> prerelease-1-0-1-1
> > >>
> > >> Thanks,
> > >> Bradley Taylor
> > >> http://railsmachine.com
> > >
> > > _______________________________________________
> > > 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
> >
>
>
> --
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From carl.lerche at gmail.com  Tue Mar 27 13:02:44 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Tue, 27 Mar 2007 10:02:44 -0700
Subject: [Mongrel] Monit + Mongrel woes
In-Reply-To: <c75e5f320703270916r13e2ea65hee04c10e146938d5@mail.gmail.com>
References: <ab90312e0703261302k4f448194l79dff7162592a8b6@mail.gmail.com>
	<466af3440703261405k1c6c2ef9oc40bdb11f9407037@mail.gmail.com>
	<ab90312e0703261452k10b64bdcj22c3456d50be1302@mail.gmail.com>
	<c75e5f320703270916r13e2ea65hee04c10e146938d5@mail.gmail.com>
Message-ID: <ab90312e0703271002y204757ay28107a5c6bf2bb6c@mail.gmail.com>

Thanks for the suggestion. I have tried this, however it still didn't work.

I have finally figured out why it wasn't working for me. There were 2 reasons.

1) Mongrel_cluster was not dealing with directories correctly. It
would try to find the pid file in log/<pid_file> relative to where the
command was called, not the directory specified in the configuration
file.

2) My mongrel_rails command is located in /usr/local/bin and monit
specifies a "spartan" path (/bin:/usr/bin:/sbin:/usr/sbin). I hacked
this by linking /usr/bin/mongrel_rails to /usr/local/bin/mongrel_rails

-carl

On 3/27/07, Corey Donohoe <atmos at atmos.org> wrote:
> Upload your mongrel_cluster.yml here
> http://monitr.atmos.org/generators/mongrel_cluster
>
> sudo gem install mongrel_cluster --source
> http://mongrel.rubyforge.org/releases/ && gem cleanup
>
> That should get you going in the right direction.
>
>
> On 3/26/07, Carl Lerche < carl.lerche at gmail.com> wrote:
> > Hello,
> >
> > How would I tell mongrel_cluster to restart a single mongrel instance
> > (if only one of them failed? Do you have an example of a monitrc file
> > that uses mongrel_cluster?
> >
> > Thanks,
> > -carl
> >
> > On 3/26/07, Joey Geiger < jgeiger at gmail.com> wrote:
> > > If you're not using mongrel_cluster, you might want to look into using
> it.
> > >
> > > If you are, I would suggest rewriting your monit scripts to deal with
> > > the new pid file location, and such.
> > >
> > > The new mongrel_cluster can handle the leftover pid files, and will
> > > clean them up before attempting to restart.
> > >
> > > On 3/26/07, Carl Lerche < carl.lerche at gmail.com> wrote:
> > > > Hello all,
> > > >
> > > > So, I've been using monit with mongrel for a while now, since the
> > > > 0.3.x days (I think it was). It used to work fine, but now I seem to
> > > > be having some trouble. I'm currently using mongrel 1.0.1 and I am
> > > > using the same monit configuration I've always been using, yet
> > > > everytime monit should restart mongrel, I get "Execution failed".
> > > >
> > > > For the start command, I originally used the following:
> > > > ------------
> > > > start program = "/usr/bin/su admin -c '/usr/local/bin/mongrel_rails
> > > > start -d -e production -p 8001 -a 127.0.0.1 -c
> > > > /home/admin/webapps/gohuman/current -P
> log/mongrel.8001.pid'"
> > > > ------------
> > > > But then monit started giving me execution failed errors and when I
> > > > tried to run it manually I got a "PID already exists" error. So, I
> > > > tried the following:
> > > > ------------
> > > > start program = "/bin/rm -f
> > > >
> /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid &&
> /usr/bin/su
> > > > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
> > > > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current
> -P
> > > > log/mongrel.8001.pid'"
> > > > ------------
> > > > Which just adds the rm at the start. Yet, monit still can't manage to
> > > > restart mongrel. I have no idea why. This is my full monit file
> > > >
> > > > ------------
> > > > ##### mongrel 8000 - GoHuman #####
> > > > check process mongrel-8000 with pidfile
> > > >
> /home/admin/webapps/gohuman/shared/log/mongrel.8000.pid
> > > >     start program = "/bin/rm -f
> > > >
> /home/admin/webapps/gohuman/shared/log/mongrel.8000.pid &&
> /usr/bin/su
> > > > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8000
> > > > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current
> -P
> > > > log/mongrel.8000.pid'"
> > > >     stop program  = "/usr/bin/su admin -c
> > > > '/usr/local/bin/mongrel_rails stop -c
> > > > /home/admin/webapps/gohuman/current -P
> log/mongrel.8000.pid'"
> > > >
> > > >     if totalmem is greater than 80.0 MB for 5 cycles then alert
> > > >  # eating up memory?
> > > >     if cpu is greater than 50% for 2 cycles then alert
> > > >  # send an email to admin
> > > >     if cpu is greater than 80% for 3 cycles then restart
> > > >  # hung process?
> > > >     if loadavg(5min) greater than 10 for 8 cycles then restart
> > > >  # bad, bad, bad
> > > >     if 3 restarts within 5 cycles then timeout
> > > >  # something is wrong, call the sys-admin
> > > >
> > > >     group gohuman
> > > >
> > > > ##### mongrel 8001 - GoHuman #####
> > > > check process mongrel-8001 with pidfile
> > > >
> /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid
> > > >     start program = "/bin/rm -f
> > > >
> /home/admin/webapps/gohuman/shared/log/mongrel.8001.pid &&
> /usr/bin/su
> > > > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8001
> > > > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current
> -P
> > > > log/mongrel.8001.pid'"
> > > >     stop program  = "/usr/bin/su admin -c
> > > > '/usr/local/bin/mongrel_rails stop -c
> > > > /home/admin/webapps/gohuman/current -P
> log/mongrel.8001.pid'"
> > > >
> > > >     if totalmem is greater than 80.0 MB for 5 cycles then alert
> > > >  # eating up memory?
> > > >     if cpu is greater than 50% for 2 cycles then alert
> > > >  # send an email to admin
> > > >     if cpu is greater than 80% for 3 cycles then restart
> > > >  # hung process?
> > > >     if loadavg(5min) greater than 10 for 8 cycles then restart
> > > >  # bad, bad, bad
> > > >     if 3 restarts within 5 cycles then timeout
> > > >  # something is wrong, call the sys-admin
> > > >
> > > >     group gohuman
> > > >
> > > > ##### mongrel 8002 - GoHuman #####
> > > > check process mongrel-8002 with pidfile
> > > >
> /home/admin/webapps/gohuman/shared/log/mongrel.8002.pid
> > > >     start program = "/bin/rm -f
> > > >
> /home/admin/webapps/gohuman/shared/log/mongrel.8002.pid &&
> /usr/bin/su
> > > > admin -c '/usr/local/bin/mongrel_rails start -d -e production -p 8002
> > > > -a 127.0.0.1 -c /home/admin/webapps/gohuman/current
> -P
> > > > log/mongrel.8002.pid'"
> > > >     stop program  = "/usr/bin/su admin -c
> > > > '/usr/local/bin/mongrel_rails stop -c
> > > > /home/admin/webapps/gohuman/current -P
> log/mongrel.8002.pid'"
> > > >
> > > >     if totalmem is greater than 80.0 MB for 5 cycles then alert
> > > >  # eating up memory?
> > > >     if cpu is greater than 50% for 2 cycles then alert
> > > >  # send an email to admin
> > > >     if cpu is greater than 80% for 3 cycles then restart
> > > >  # hung process?
> > > >     if loadavg(5min) greater than 10 for 8 cycles then restart
> > > >  # bad, bad, bad
> > > >     if 3 restarts within 5 cycles then timeout
> > > >  # something is wrong, call the sys-admin
> > > >
> > > >     group gohuman
> > > > ------------
> > > >
> > > > Thanks,
> > > > -carl
> > > > --
> > > > EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> > > > _______________________________________________
> > > > 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
> > >
> >
> >
> > --
> > EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
>
>
> --
> Corey Donohoe
>  http://www.atmos.org/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From kaushik.ghose at gmail.com  Tue Mar 27 23:03:29 2007
From: kaushik.ghose at gmail.com (kaushik.ghose)
Date: Tue, 27 Mar 2007 23:03:29 -0400
Subject: [Mongrel] Mongrel on Vista as a service
Message-ID: <4609DB01.9020700@gmail.com>

Hi Everyone,

I was hoping some one could help me out with an issue I'm having with 
mongrel on Vista.

I have a ruby on rails application that runs fine with mongrel when I 
double click on it. Command window opens, server starts and works just fine.

For the same application, after I install the service using 
mongrel_service, and I try to start it, it fails. Vista says that the 
service shutdown right after it started up.

I didn't have such problems on XP.

Thanks
-Kaushik

From luislavena at gmail.com  Tue Mar 27 23:24:57 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 28 Mar 2007 00:24:57 -0300
Subject: [Mongrel] Mongrel on Vista as a service
In-Reply-To: <4609DB01.9020700@gmail.com>
References: <4609DB01.9020700@gmail.com>
Message-ID: <71166b3b0703272024v26892d63t372e0625f95d47e2@mail.gmail.com>

On 3/28/07, kaushik.ghose <kaushik.ghose at gmail.com> wrote:
> Hi Everyone,
>
> I was hoping some one could help me out with an issue I'm having with
> mongrel on Vista.
>
> I have a ruby on rails application that runs fine with mongrel when I
> double click on it. Command window opens, server starts and works just fine.
>
> For the same application, after I install the service using
> mongrel_service, and I try to start it, it fails. Vista says that the
> service shutdown right after it started up.
>

Will be very helpful if you provide the logs (servicefb.log and
mongrel_service.log) both located into ruby\bin directory.

> I didn't have such problems on XP.
>

Its often an permission issue, often called as "LUA Bug"
(Low-privileged User Account Bug)
Local Service account must have access & permissions to the files and
folders of that project.

Also you could try simulating the service functionality using console command:

if you start mongrel_rails with these parameters:

mongrel_rails start -c "C:\Path\To\My\Application" -p 3000 -e production

You can start console like this:

mongrel_service console single -c "C:\Path\To\My\Application" -p 3000
-e production

And check if the application start properly.

Also perform the same task running a console with low-privileges
(posted a few weeks back on how to get it running with psexec, search
the list).

> Thanks
> -Kaushik
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From aglarond at gmail.com  Wed Mar 28 04:13:33 2007
From: aglarond at gmail.com (Dimitri Aivaliotis)
Date: Wed, 28 Mar 2007 10:13:33 +0200
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <20070326103126.0dde04d0.zedshaw@zedshaw.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
	<20070320104415.98b33127.zedshaw@zedshaw.com>
	<55c107bf0703200821j681c0b9cl65065d0f82726174@mail.gmail.com>
	<20070326103126.0dde04d0.zedshaw@zedshaw.com>
Message-ID: <55c107bf0703280113s122f1646t9880abd7ee7809fe@mail.gmail.com>

On 3/26/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> On Tue, 20 Mar 2007 16:21:44 +0100
> "Dimitri Aivaliotis" <aglarond at gmail.com> wrote:
>
> > On 3/20/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> > > On Tue, 20 Mar 2007 14:53:39 +0100
> > > "Dimitri Aivaliotis" <aglarond at gmail.com> wrote:
>
> > > Make sure you give a full path for all your files you configure.  If
> > > not, let me know and I'll check it out.
> >
> > I am using full paths: :pid_file => "/tmp/test.pid"
> >
> > What other info can I give you to help debug this?
>
> Did you get this resolved Dimitri?  I lost your reply in my queue.
>

No, not yet.  The pid file is still not created.  I also don't see it
when running the 'builder.rb' example.

If you don't have the time, I understand.  It's not such a big deal to
me at the moment, but in the future, I would like to be able to send
signals to the daemonized processes via the pid file.

- Dimitri

From zedshaw at zedshaw.com  Wed Mar 28 11:14:03 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 28 Mar 2007 11:14:03 -0400
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <55c107bf0703280113s122f1646t9880abd7ee7809fe@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
	<20070320104415.98b33127.zedshaw@zedshaw.com>
	<55c107bf0703200821j681c0b9cl65065d0f82726174@mail.gmail.com>
	<20070326103126.0dde04d0.zedshaw@zedshaw.com>
	<55c107bf0703280113s122f1646t9880abd7ee7809fe@mail.gmail.com>
Message-ID: <20070328111403.89dc6bcc.zedshaw@zedshaw.com>

On Wed, 28 Mar 2007 10:13:33 +0200
"Dimitri Aivaliotis" <aglarond at gmail.com> wrote:

> On 3/26/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> > On Tue, 20 Mar 2007 16:21:44 +0100
> > "Dimitri Aivaliotis" <aglarond at gmail.com> wrote:
> >
> > Did you get this resolved Dimitri?  I lost your reply in my queue.
> >
> 
> No, not yet.  The pid file is still not created.  I also don't see it
> when running the 'builder.rb' example.
> 
> If you don't have the time, I understand.  It's not such a big deal to
> me at the moment, but in the future, I would like to be able to send
> signals to the daemonized processes via the pid file.

Well, everyone else seems to be getting PID files no problem, so you
have to investigate what is different about your system that could
cause it.  Try running it as different users, from different locations,
in different directories, etc. until you find out what causes it.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From angelo0000 at gmail.com  Wed Mar 28 11:33:50 2007
From: angelo0000 at gmail.com (Jake Dempsey)
Date: Wed, 28 Mar 2007 10:33:50 -0500
Subject: [Mongrel] service::start problem on win32
Message-ID: <5479b1ff0703280833p83fd168t2fa8a80dfc4ea512@mail.gmail.com>

Posted this on rubyforge, thought I would put it here at as well.

I just started playing around with mongrel. I am currently using apache +
fastcgi. I am running a windows box and I followed the directions at
http://mongrel.rubyforge.org/docs/win32.html. I am able to install the
service fine and also start the service from the windows service control
panel. However, when I try to start the service with the command:
mongrel_rails service::start -N myapp, I get an error

ERROR RUNNING 'service::start': Plugin /service::start does not exist in
categor
y /commands

Has this functionality been removed from mongrel_service?


-- 
Jake Dempsey
www.watij.com
www.explainpmt.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070328/53518e1d/attachment.html 

From luislavena at gmail.com  Wed Mar 28 11:50:32 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 28 Mar 2007 12:50:32 -0300
Subject: [Mongrel] service::start problem on win32
In-Reply-To: <5479b1ff0703280833p83fd168t2fa8a80dfc4ea512@mail.gmail.com>
References: <5479b1ff0703280833p83fd168t2fa8a80dfc4ea512@mail.gmail.com>
Message-ID: <71166b3b0703280850q46a8e279t80bdabc8c8f4f447@mail.gmail.com>

On 3/28/07, Jake Dempsey <angelo0000 at gmail.com> wrote:
> Posted this on rubyforge, thought I would put it here at as well.
>
> I just started playing around with mongrel. I am currently using apache +
> fastcgi. I am running a windows box and I followed the directions at
> http://mongrel.rubyforge.org/docs/win32.html. I am able to
> install the service fine and also start the service from the windows service
> control panel. However, when I try to start the service with the command:
> mongrel_rails service::start -N myapp, I get an error
>
> ERROR RUNNING 'service::start': Plugin /service::start does not exist in
> categor
> y /commands
>
> Has this functionality been removed from mongrel_service?
>

Yes, as commented before [1], it has no true advantage over using "net
start" or "net stop"

[1] http://rubyforge.org/pipermail/mongrel-users/2007-February/002962.html

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From dennis at sutch.com  Wed Mar 28 16:06:56 2007
From: dennis at sutch.com (Dennis Sutch)
Date: Wed, 28 Mar 2007 16:06:56 -0400
Subject: [Mongrel] returning images from Mongrel
Message-ID: <f819be840703281306o91b6267g37b657d3316c3721@mail.gmail.com>

I've been able to use Mongrel's native API to serve up files using:

response.start do |head, out|
  head['Content-Type'] = resource.content_type
  out.write( resource.content )
end

This has worked well, until I attempted to serve up images.
resource.content seems to be the problem.  Usually it returns the text of
the page.  When resource.content returns an image, I've noticed that Mongrel
doesn't set the Content-Length header to the correct length for the image.
All other headers seem to be valid.

I tried passing the filename of the image using out.send_file, but it seems
as though send_file is no longer available.

What method should be used for returning binary content such as images?

-- 
Dennis Sutch
dennis at sutch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070328/dafdfacd/attachment-0001.html 

From baswilbers at gmail.com  Wed Mar 28 17:54:57 2007
From: baswilbers at gmail.com (Bas Wilbers)
Date: Wed, 28 Mar 2007 17:54:57 -0400 (EDT)
Subject: [Mongrel] Bas has Tagged you! :)
Message-ID: <20070328215457.F26005240B78@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070328/3e30a990/attachment.html 

From angelo0000 at gmail.com  Wed Mar 28 22:28:43 2007
From: angelo0000 at gmail.com (Jake Dempsey)
Date: Wed, 28 Mar 2007 21:28:43 -0500
Subject: [Mongrel] Apache Load Balancer Manager With Mongrel
Message-ID: <5479b1ff0703281928r50fef11bw8ecf189cdadce423@mail.gmail.com>

Thanks for the answer on server::start...that makes sense, just wanted to
make sure I was not doing anything incorrectly.  I am now running 3 mongrel
servers as windows services (mongrel_cluster is not supported for windows).
I have apache configured with with mod_proxy_balancer from the instructions
at http://mongrel.rubyforge.org/docs/apache.html.  I am able to access my
app without a port number so I am guessing it is load balancing to the
mongrel servers.

My questions are:

1.  I have added the balance-manager piece (had to remove the Deny All to
not get a 403), but I only get a page that says: "Load Balance Manager for
localhost" and thats it....Can anyone help me with this?

2. How can I view the current load on the mongrel servers?  Would this be
done via the Load Balance Manager that I can not seem to get running?

BTW...So far, I am loving mongrel over my current fcgi setup.

-- 
Jake Dempsey
www.watij.com
www.explainpmt.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070328/947ffccb/attachment.html 

From angelo0000 at gmail.com  Thu Mar 29 00:59:16 2007
From: angelo0000 at gmail.com (Jake Dempsey)
Date: Wed, 28 Mar 2007 23:59:16 -0500
Subject: [Mongrel] Resolved problem with Apache Load Balancer Manager
Message-ID: <5479b1ff0703282159n46a8c869v345dd2d8a57e0a59@mail.gmail.com>

Had to make a couple of changes to the config from the mongrel site to get
the load balancer manager working:

changed

  # Redirect all non-static requests to cluster
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

to

  # Redirect all non-static requests to cluster
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_URI} !/balancer
  RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]


I also added:
 <Location /balancer-manager>
   SetHandler balancer-manager
   Allow from localhost
 </Location>

To my virtualhost for my rails app.

Full Config:


<VirtualHost *:80>
  DocumentRoot PATH_TO_MY_APP/public

  <Directory "PATH_TO_MY_APP/public">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
  </Directory>

  RewriteEngine On

  # Uncomment for rewrite debugging
  #RewriteLog logs/myapp_rewrite_log
  #RewriteLogLevel 9

  # Check for maintenance file and redirect all requests
  #  ( this is for use with Capistrano's disable_web task )
  RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
  RewriteCond %{SCRIPT_FILENAME} !maintenance.html
  RewriteRule ^.*$ /system/maintenance.html [L]

  # Rewrite index to check for static
  RewriteRule ^/$ /index.html [QSA]

  # Rewrite to check for Rails cached page
  RewriteRule ^([^.]+)$ $1.html [QSA]

  # Redirect all non-static requests to cluster
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_URI} !/balancer
  RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

  # Deflate
  AddOutputFilterByType DEFLATE text/html text/plain text/css
  # ... text/xml application/xml application/xhtml+xml text/javascript
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

  # Uncomment for deflate debugging
  #DeflateFilterNote Input input_info
  #DeflateFilterNote Output output_info
  #DeflateFilterNote Ratio ratio_info
  #LogFormat '"%r" %{output_info}n/%{input_info}n (%{ratio_info}n%%)'
deflate
  #CustomLog logs/myapp_deflate_log deflate

    ErrorLog logs/myapp_errors_log.log
    CustomLog logs/myapp_log.log combined

 <Proxy balancer://mongrel_cluster>
    BalancerMember http://127.0.0.1:3000
    BalancerMember http://127.0.0.1:3001
    BalancerMember http://127.0.0.1:3002
  </Proxy>

 <Location /balancer-manager>
   SetHandler balancer-manager
   Allow from localhost
 </Location>
 </virtualHost>

-- 
Jake Dempsey
www.watij.com
www.explainpmt.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070328/ba71765d/attachment.html 

From baswilbers at gmail.com  Thu Mar 29 04:39:16 2007
From: baswilbers at gmail.com (basaah)
Date: Thu, 29 Mar 2007 10:39:16 +0200
Subject: [Mongrel] Bas has Tagged you! :)
In-Reply-To: <20070328215457.F26005240B78@rubyforge.org>
References: <20070328215457.F26005240B78@rubyforge.org>
Message-ID: <6d0e137b0703290139h4109110s5019416589004692@mail.gmail.com>

sorry this was my mistake, I made a little mistake and mailed this by
accident to all the pesons I ever mailed,
including this mailign list.
sorry...

On 3/28/07, Bas Wilbers <baswilbers at gmail.com> wrote:
>
>
> <http://www.taggedmail.com/welcome.html?conn=1x0qyunfa&ect=4k85xsj&tId=130065&fid=446341c56a360167>
>
>
> Bas W, 16
> Netherlands
>  Bas W has added you as a friend
> Is Bas W your friend?
>  <http://www.taggedmail.com/welcome.html?conn=1x0qyunfa&ect=4k85xsj&tId=130065&fid=446341c56a360167> Please
> respond or Bas may think you said no :(
>
>     Click here<http://www.taggedmail.com/no_more.html?unsem=mongrel-users%40rubyforge.org&tId=130065&fid=446341c56a360167>to unsubscribe from Tagged,
> P.O. Box 193152 San Francisco, CA 94119-3152
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
<<{{}}[]greetings bas[]{{}}>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070329/6b461007/attachment.html 

From hpoydar at gmail.com  Thu Mar 29 10:50:53 2007
From: hpoydar at gmail.com (Henry)
Date: Thu, 29 Mar 2007 10:50:53 -0400
Subject: [Mongrel] Machine reboot - monit fails to start mongrels
Message-ID: <F607107B-25E8-428D-B50A-A70ACBF1AB1B@gmail.com>

Greetings -

I dug around a bit and I couldn't find a definitive answer to this  
question, apologies if it's been covered before.   A box running a  
apache 2.2 -> mongrel cluster for a rails app got power cycled at my  
ISP.  Unfortunately monit couldn't start the mongrel processes  
because the pid files were still there. Here is my monit config (for  
each mongrel process):

check process myapp_mongrel_8000 with pidfile /data/wwwroot/myapp.com/ 
log/mongrel.8000.pid
         start program = "/usr/bin/mongrel_rails start -d -e  
production -p 8000 -a 127.0.0.1 -P log/mongrel.8000.pid -c /data/ 
wwwroot/myapp.com --user mongrel --group mongrel"
         stop program = "/usr/bin/mongrel_rails stop -P log/mongrel. 
8000.pid -c /data/wwwroot/myapp.com"
         if failed host 127.0.0.1 port 8000 protocol http
                 and request "/" then alert
         if cpu is greater than 60% for 2 cycles then alert
         if cpu > 80% for 5 cycles then restart
         if loadavg(5min) greater than 10 for 8 cycles then restart
         if 3 restarts within 5 cycles then timeout

Is there some other command line switch I can add to avoid this  
problem?  Should I config monit to clear the .pid files first?

Thanks,
Henry




From jgeiger at gmail.com  Thu Mar 29 11:05:47 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Thu, 29 Mar 2007 10:05:47 -0500
Subject: [Mongrel] Machine reboot - monit fails to start mongrels
In-Reply-To: <F607107B-25E8-428D-B50A-A70ACBF1AB1B@gmail.com>
References: <F607107B-25E8-428D-B50A-A70ACBF1AB1B@gmail.com>
Message-ID: <466af3440703290805h625f5955ye1858fe7a6f76fec@mail.gmail.com>

You can use the new mongrel_cluster gem to startup your mongrels one
at a time, and it will also clear any stale pid files.

Here's an example of part of my monitrc that uses the cluster start.

###
# monitor mongrel four
###
check process mongrel-8003
  with pidfile /var/run/mongrel_cluster/mongrel.8003.pid
  group mongrel
  alert monit at website.com only on { connection, resource }

  start program = "/usr/bin/ruby /usr/bin/mongrel_rails cluster::start --only 80
03 --clean  -C /etc/mongrel_cluster/website_mongrel_cluster.yml"

  stop program = "/usr/bin/ruby /usr/bin/mongrel_rails cluster::stop --only 8003
 -C /etc/mongrel_cluster/website_mongrel_cluster.yml"

  if totalmem > 50.0 MB for 5 cycles then restart
  if cpu is greater than 60% for 2 cycles then alert
  if cpu > 80% for 5 cycles then restart

  if failed url
    http://localhost:8003/monit/index
    and content == 'success'
    with timeout 15 seconds then restart




On 3/29/07, Henry <hpoydar at gmail.com> wrote:
> Greetings -
>
> I dug around a bit and I couldn't find a definitive answer to this
> question, apologies if it's been covered before.   A box running a
> apache 2.2 -> mongrel cluster for a rails app got power cycled at my
> ISP.  Unfortunately monit couldn't start the mongrel processes
> because the pid files were still there. Here is my monit config (for
> each mongrel process):
>
> check process myapp_mongrel_8000 with pidfile /data/wwwroot/myapp.com/
> log/mongrel.8000.pid
>          start program = "/usr/bin/mongrel_rails start -d -e
> production -p 8000 -a 127.0.0.1 -P log/mongrel.8000.pid -c /data/
> wwwroot/myapp.com --user mongrel --group mongrel"
>          stop program = "/usr/bin/mongrel_rails stop -P log/mongrel.
> 8000.pid -c /data/wwwroot/myapp.com"
>          if failed host 127.0.0.1 port 8000 protocol http
>                  and request "/" then alert
>          if cpu is greater than 60% for 2 cycles then alert
>          if cpu > 80% for 5 cycles then restart
>          if loadavg(5min) greater than 10 for 8 cycles then restart
>          if 3 restarts within 5 cycles then timeout
>
> Is there some other command line switch I can add to avoid this
> problem?  Should I config monit to clear the .pid files first?
>
> Thanks,
> Henry
>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From matt.mcknight at gmail.com  Thu Mar 29 11:21:48 2007
From: matt.mcknight at gmail.com (Matthew McKnight)
Date: Thu, 29 Mar 2007 11:21:48 -0400
Subject: [Mongrel] Mongrel Service won't start on windows
Message-ID: <e2cb9aee0703290821h26b5b4f5qa3cb3a2b5b98901@mail.gmail.com>

64bit Intel 8 CPU server
Windows 2003 Server
Service set to run as LocalSystem, doesn't work as user account either

The error we see is:
"Service failed to start in a timely..."
Which I have seen in the past email trails as working

The app works from mongrel_rails start and from  mongrel_service console -N
servicename -p 3000 -c c:\rails_apps\appname -e production

We upgraded to Mongrel 1.0.1, Mongrel Service 0.3.1

It looks like updates to win32-process and win32-service came with the gem
updates for those. Which versions are good to go with mongrel_service-
0.3.1-mswin32?

This is working on our test and development servers, which are both VMWare
sessions.

I currently have a pack of mongrels running in command line windows under
our sysadmin's user account- any ideas what to do?

-- 
-Matt McKnight-
www.lmnsolutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070329/b2d47ea7/attachment.html 

From hpoydar at gmail.com  Thu Mar 29 12:04:14 2007
From: hpoydar at gmail.com (Henry)
Date: Thu, 29 Mar 2007 12:04:14 -0400
Subject: [Mongrel] Machine reboot - monit fails to start mongrels
In-Reply-To: <466af3440703290805h625f5955ye1858fe7a6f76fec@mail.gmail.com>
References: <F607107B-25E8-428D-B50A-A70ACBF1AB1B@gmail.com>
	<466af3440703290805h625f5955ye1858fe7a6f76fec@mail.gmail.com>
Message-ID: <CBCCD581-BD36-4CBA-A0B6-EB326EDB9446@gmail.com>

Thanks, Joey.  Do you mean the newest gem mongrel_cluster-0.2.1 or do  
you mean the 'prerelease' I've seen mentioned in this list?


On Mar 29, 2007, at 11:05 AM, Joey Geiger wrote:

> You can use the new mongrel_cluster gem to startup your mongrels one
> at a time, and it will also clear any stale pid files.
>
> Here's an example of part of my monitrc that uses the cluster start.
>
> ###
> # monitor mongrel four
> ###
> check process mongrel-8003
>   with pidfile /var/run/mongrel_cluster/mongrel.8003.pid
>   group mongrel
>   alert monit at website.com only on { connection, resource }
>
>   start program = "/usr/bin/ruby /usr/bin/mongrel_rails  
> cluster::start --only 80
> 03 --clean  -C /etc/mongrel_cluster/website_mongrel_cluster.yml"
>
>   stop program = "/usr/bin/ruby /usr/bin/mongrel_rails  
> cluster::stop --only 8003
>  -C /etc/mongrel_cluster/website_mongrel_cluster.yml"
>
>   if totalmem > 50.0 MB for 5 cycles then restart
>   if cpu is greater than 60% for 2 cycles then alert
>   if cpu > 80% for 5 cycles then restart
>
>   if failed url
>     http://localhost:8003/monit/index
>     and content == 'success'
>     with timeout 15 seconds then restart
>
>
>
>
> On 3/29/07, Henry <hpoydar at gmail.com> wrote:
>> Greetings -
>>
>> I dug around a bit and I couldn't find a definitive answer to this
>> question, apologies if it's been covered before.   A box running a
>> apache 2.2 -> mongrel cluster for a rails app got power cycled at my
>> ISP.  Unfortunately monit couldn't start the mongrel processes
>> because the pid files were still there. Here is my monit config (for
>> each mongrel process):
>>
>> check process myapp_mongrel_8000 with pidfile /data/wwwroot/ 
>> myapp.com/
>> log/mongrel.8000.pid
>>          start program = "/usr/bin/mongrel_rails start -d -e
>> production -p 8000 -a 127.0.0.1 -P log/mongrel.8000.pid -c /data/
>> wwwroot/myapp.com --user mongrel --group mongrel"
>>          stop program = "/usr/bin/mongrel_rails stop -P log/mongrel.
>> 8000.pid -c /data/wwwroot/myapp.com"
>>          if failed host 127.0.0.1 port 8000 protocol http
>>                  and request "/" then alert
>>          if cpu is greater than 60% for 2 cycles then alert
>>          if cpu > 80% for 5 cycles then restart
>>          if loadavg(5min) greater than 10 for 8 cycles then restart
>>          if 3 restarts within 5 cycles then timeout
>>
>> Is there some other command line switch I can add to avoid this
>> problem?  Should I config monit to clear the .pid files first?
>>
>> Thanks,
>> Henry
>>
>>
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From kaushik.ghose at gmail.com  Thu Mar 29 12:05:38 2007
From: kaushik.ghose at gmail.com (kaushik.ghose)
Date: Thu, 29 Mar 2007 12:05:38 -0400
Subject: [Mongrel] mongrel and vista
Message-ID: <460BE3D2.5000101@gmail.com>

Thanks for your reply Luis

> Will be very helpful if you provide the logs (servicefb.log and
> mongrel_service.log) both located into ruby\bin directory.


---------------------------------------------------------------------------------
# Logfile created on 28/03/2007 17:54:32

native/process.bas:44, fb.process.spawn:
   Spawn() init

native/process.bas:50, fb.process.spawn:
   Success in AllocConsole()

native/process.bas:105, fb.process.spawn:
   Creating child process with cmdline: ruby.exe C:\Program
Files\ruby\bin\mongrel_rails start -c d:\research\rriki -p 3000 -e
production

native/process.bas:121, fb.process.spawn:
   Closing handles.

native/process.bas:136, fb.process.spawn:
   wait_code: 0

native/process.bas:147, fb.process.spawn:
   failed, the process terminate earlier.

native/process.bas:156, fb.process.spawn:
   Spawn() done

native/mongrel_service.bas:88, mongrel_service.single_oninit:
   single_onInit() done

native/mongrel_service.bas:93, mongrel_service.single_onstart:
   single_onStart()

native/mongrel_service.bas:101, mongrel_service.single_onstart:
   child process terminated!, re-spawning a new one

--------------------------------- Continues in this vein, for a few more
tries ------------------


> mongrel_rails start -c "C:\Path\To\My\Application" -p 3000 -e production
That works

> mongrel_service console single -c "C:\Path\To\My\Application" -p 3000
-e production

No errors, but the application isn't available. i.e. webbrowser doesnot
return a page.

I'm running a console with regular (local user) privileges


Thanks!
-Kaushik


From matt.mcknight at gmail.com  Thu Mar 29 12:31:32 2007
From: matt.mcknight at gmail.com (Matthew McKnight)
Date: Thu, 29 Mar 2007 12:31:32 -0400
Subject: [Mongrel] Mongrel Service won't start on windows
Message-ID: <e2cb9aee0703290931y506fd42ci92cf470a3c4a012c@mail.gmail.com>

Forgot to mention it was working swell before upgrade to install of
1.8.5-21 which cleaned out my gems and then gem install of latest
Mongrel/Mongrel Service.

Are these pulling the right win32-service gem?

Would love for there to be a good way to get back....

---------------------------------------------

64bit Intel 8 CPU server
Windows 2003 Server
Service set to run as LocalSystem, doesn't work as user account either

The error we see is:
"Service failed to start in a timely..."
Which I have seen in the past email trails as working

The app works from mongrel_rails start and from  mongrel_service console -N
servicename -p 3000 -c c:\rails_apps\appname -e production

We upgraded to Mongrel 1.0.1, Mongrel Service 0.3.1

It looks like updates to win32-process and win32-service came with the gem
updates for those. Which versions are good to go with mongrel_service-
0.3.1-mswin32?

This is working on our test and development servers, which are both VMWare
sessions.

I currently have a pack of mongrels running in command line windows under
our sysadmin's user account- any ideas what to do?

-- 
-Matt McKnight-
www.lmnsolutions.com

From jgeiger at gmail.com  Thu Mar 29 14:00:34 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Thu, 29 Mar 2007 13:00:34 -0500
Subject: [Mongrel] Machine reboot - monit fails to start mongrels
In-Reply-To: <CBCCD581-BD36-4CBA-A0B6-EB326EDB9446@gmail.com>
References: <F607107B-25E8-428D-B50A-A70ACBF1AB1B@gmail.com>
	<466af3440703290805h625f5955ye1858fe7a6f76fec@mail.gmail.com>
	<CBCCD581-BD36-4CBA-A0B6-EB326EDB9446@gmail.com>
Message-ID: <466af3440703291100t544be6abj11b7d2e74e014886@mail.gmail.com>

1.0.x something. It would be the pre-release as of right now I guess.

On 3/29/07, Henry <hpoydar at gmail.com> wrote:
> Thanks, Joey.  Do you mean the newest gem mongrel_cluster-0.2.1 or do
> you mean the 'prerelease' I've seen mentioned in this list?
>
>
> On Mar 29, 2007, at 11:05 AM, Joey Geiger wrote:
>
> > You can use the new mongrel_cluster gem to startup your mongrels one
> > at a time, and it will also clear any stale pid files.
> >
> > Here's an example of part of my monitrc that uses the cluster start.
> >
> > ###
> > # monitor mongrel four
> > ###
> > check process mongrel-8003
> >   with pidfile /var/run/mongrel_cluster/mongrel.8003.pid
> >   group mongrel
> >   alert monit at website.com only on { connection, resource }
> >
> >   start program = "/usr/bin/ruby /usr/bin/mongrel_rails
> > cluster::start --only 80
> > 03 --clean  -C /etc/mongrel_cluster/website_mongrel_cluster.yml"
> >
> >   stop program = "/usr/bin/ruby /usr/bin/mongrel_rails
> > cluster::stop --only 8003
> >  -C /etc/mongrel_cluster/website_mongrel_cluster.yml"
> >
> >   if totalmem > 50.0 MB for 5 cycles then restart
> >   if cpu is greater than 60% for 2 cycles then alert
> >   if cpu > 80% for 5 cycles then restart
> >
> >   if failed url
> >     http://localhost:8003/monit/index
> >     and content == 'success'
> >     with timeout 15 seconds then restart
> >
> >
> >
> >
> > On 3/29/07, Henry <hpoydar at gmail.com> wrote:
> >> Greetings -
> >>
> >> I dug around a bit and I couldn't find a definitive answer to this
> >> question, apologies if it's been covered before.   A box running a
> >> apache 2.2 -> mongrel cluster for a rails app got power cycled at my
> >> ISP.  Unfortunately monit couldn't start the mongrel processes
> >> because the pid files were still there. Here is my monit config (for
> >> each mongrel process):
> >>
> >> check process myapp_mongrel_8000 with pidfile /data/wwwroot/
> >> myapp.com/
> >> log/mongrel.8000.pid
> >>          start program = "/usr/bin/mongrel_rails start -d -e
> >> production -p 8000 -a 127.0.0.1 -P log/mongrel.8000.pid -c /data/
> >> wwwroot/myapp.com --user mongrel --group mongrel"
> >>          stop program = "/usr/bin/mongrel_rails stop -P log/mongrel.
> >> 8000.pid -c /data/wwwroot/myapp.com"
> >>          if failed host 127.0.0.1 port 8000 protocol http
> >>                  and request "/" then alert
> >>          if cpu is greater than 60% for 2 cycles then alert
> >>          if cpu > 80% for 5 cycles then restart
> >>          if loadavg(5min) greater than 10 for 8 cycles then restart
> >>          if 3 restarts within 5 cycles then timeout
> >>
> >> Is there some other command line switch I can add to avoid this
> >> problem?  Should I config monit to clear the .pid files first?
> >>
> >> Thanks,
> >> Henry
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From luislavena at gmail.com  Thu Mar 29 16:07:27 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 29 Mar 2007 17:07:27 -0300
Subject: [Mongrel] Mongrel Service won't start on windows
In-Reply-To: <e2cb9aee0703290821h26b5b4f5qa3cb3a2b5b98901@mail.gmail.com>
References: <e2cb9aee0703290821h26b5b4f5qa3cb3a2b5b98901@mail.gmail.com>
Message-ID: <71166b3b0703291307g3bba1f17pb82213fa4a23f158@mail.gmail.com>

On 3/29/07, Matthew McKnight <matt.mcknight at gmail.com> wrote:
> 64bit Intel 8 CPU server
> Windows 2003 Server
> Service set to run as LocalSystem, doesn't work as user account either
>
> The error we see is:
> "Service failed to start in a timely..."
> Which I have seen in the past email trails as working
>

In the past? under which configuration? Ruby version, same os, which gems?


> The app works from mongrel_rails start and from  mongrel_service console -N
> servicename -p 3000 -c c:\rails_apps\appname -e production
>

the actual command line should be:

mongrel_service console -c C:\rails_apps\appname -e production -p 3000

No service name parameters is needed.

> We upgraded to Mongrel 1.0.1, Mongrel Service 0.3.1
>
> It looks like updates to win32-process and win32-service came with the gem
> updates for those. Which versions are good to go with
> mongrel_service-0.3.1-mswin32?
>

Only needed by mongrel_service is win32-service (latest guess is 0.5.2).

> This is working on our test and development servers, which are both VMWare
> sessions.
>
> I currently have a pack of mongrels running in command line windows under
> our sysadmin's user account- any ideas what to do?
>

First, start a debug session with psexec [1] with lowered privileges
as current user:

psexec -l cmd.exe

In this new console, chdir to c:\rails_app\appname and start mongrel with:

mongrel_rails start -e production -p 3000

Check the info it dumps to the screen. If it worked, then is not a LUA
bug but something else.

Also will be useful the servicefb.log and mongrel_service.log files
located in your ruby\bin folder.

[1] http://www.microsoft.com/technet/sysinternals/utilities/psexec.mspx
-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From luislavena at gmail.com  Thu Mar 29 16:11:05 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 29 Mar 2007 17:11:05 -0300
Subject: [Mongrel] Mongrel Service won't start on windows
In-Reply-To: <e2cb9aee0703290931y506fd42ci92cf470a3c4a012c@mail.gmail.com>
References: <e2cb9aee0703290931y506fd42ci92cf470a3c4a012c@mail.gmail.com>
Message-ID: <71166b3b0703291311i1d94b6d5q7a19ec70a424f5a8@mail.gmail.com>

On 3/29/07, Matthew McKnight <matt.mcknight at gmail.com> wrote:
> Forgot to mention it was working swell before upgrade to install of
> 1.8.5-21 which cleaned out my gems and then gem install of latest
> Mongrel/Mongrel Service.

Which version of rails was you using?

>
> Are these pulling the right win32-service gem?
>

win32-service gem is only used for installing - removing the service.

Will be safer if you remove previous version of mongrel_service since
mongrel_service.exe could clash with mongrel_service script, both
located in ruby\bin folder.

> Would love for there to be a good way to get back....
>

I know how you feel. Will also be good to know if you're running a
32bits or x64 bits version of Windows, since WinAPI shown some issues
between platforms.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From luislavena at gmail.com  Thu Mar 29 16:17:32 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 29 Mar 2007 17:17:32 -0300
Subject: [Mongrel] mongrel and vista
In-Reply-To: <460BE3D2.5000101@gmail.com>
References: <460BE3D2.5000101@gmail.com>
Message-ID: <71166b3b0703291317m54b679ek4937caeaf2b9e997@mail.gmail.com>

On 3/29/07, kaushik.ghose <kaushik.ghose at gmail.com> wrote:
> Thanks for your reply Luis
>
> > Will be very helpful if you provide the logs (servicefb.log and
> > mongrel_service.log) both located into ruby\bin directory.
>
>
> ---------------------------------------------------------------------------------
> # Logfile created on 28/03/2007 17:54:32
>
> native/process.bas:44, fb.process.spawn:
>    Spawn() init
>
> native/process.bas:50, fb.process.spawn:
>    Success in AllocConsole()
>
> native/process.bas:105, fb.process.spawn:
>    Creating child process with cmdline: ruby.exe C:\Program
> Files\ruby\bin\mongrel_rails start -c d:\research\rriki -p 3000 -e
> production
>

I noticed that you have ruby installed in a folder with spaces.

That often arraise some issues. (couldn't figure out every issue with
spaced names, bear on me).

I will check what could be patched in the current code for next release.

For the time being, try relocating your ruby installation to something
more freindly, like C:\Ruby.

(Like Python or Perl do).

> [...]
> --------------------------------- Continues in this vein, for a few more
> tries ------------------

Yep, it tries several times to get the ruby process running.

>
>
> > mongrel_rails start -c "C:\Path\To\My\Application" -p 3000 -e production
> That works
>
> > mongrel_service console single -c "C:\Path\To\My\Application" -p 3000
> -e production
>
> No errors, but the application isn't available. i.e. webbrowser doesnot
> return a page.
>

mongrel_rails will work, but mongrel_service wouldn't since spaced
names (non-quoted actualy) are in the way.

> I'm running a console with regular (local user) privileges
>
>
> Thanks!
> -Kaushik
>

No problem :-)

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From matt.mcknight at gmail.com  Thu Mar 29 16:30:02 2007
From: matt.mcknight at gmail.com (Matthew McKnight)
Date: Thu, 29 Mar 2007 16:30:02 -0400
Subject: [Mongrel] Mongrel Service won't start on windows
In-Reply-To: <71166b3b0703291307g3bba1f17pb82213fa4a23f158@mail.gmail.com>
References: <e2cb9aee0703290821h26b5b4f5qa3cb3a2b5b98901@mail.gmail.com>
	<71166b3b0703291307g3bba1f17pb82213fa4a23f158@mail.gmail.com>
Message-ID: <e2cb9aee0703291330y6af6d8f9wadfe9486309c2372@mail.gmail.com>

On 3/29/07, Luis Lavena <luislavena at gmail.com> wrote:

> On 3/29/07, Matthew McKnight <matt.mcknight at gmail.com> wrote:
> > 64bit Intel 8 CPU server
> > Windows 2003 Server
> > Service set to run as LocalSystem, doesn't work as user account either
> >
> > The error we see is:
> > "Service failed to start in a timely..."
> > Which I have seen in the past email trails as working
> >
>
> In the past? under which configuration? Ruby version, same os, which gems?


Ruby is 1.8.5-21

gems
rails-1.2.3
gem_plugin-0.2.2
mongrel-1.0.1-mswin32
mongrel_service-0.3.1-mswin32
win32-process-0.5.1
win32-service-0.5.2-mswin32
windows-pr-0.5.3

Everything was working fine on ruby 1.8.4, rails 1.1.6 and the old versions
of mongrel and mongrel service. The upgrade process went okay in dev and
test.



> > We upgraded to Mongrel 1.0.1, Mongrel Service 0.3.1
> >
> > It looks like updates to win32-process and win32-service came with the
> gem
> > updates for those. Which versions are good to go with
> > mongrel_service-0.3.1-mswin32?
> >
>
> Only needed by mongrel_service is win32-service (latest guess is 0.5.2).

Okay, I was persuing the archives and there seemed to be a lot of back and
forth about various versions of that gem. Is there a best version to use? Is
the mswin32 version good?



> First, start a debug session with psexec [1] with lowered privileges
> as current user:
>
> psexec -l cmd.exe
>
> In this new console, chdir to c:\rails_app\appname and start mongrel with:
>
> mongrel_rails start -e production -p 3000
>
> Check the info it dumps to the screen. If it worked, then is not a LUA
> bug but something else.
>
> Also will be useful the servicefb.log and mongrel_service.log files
> located in your ruby\bin folder.

I am not getting the mongrel_service.log- maybe it's not getting that far.
It dies extremely quickly.
I'll dump servicegb.log when my sysadmin gets me back on the server.

Thanks so much for the assistance, going to try the advanced debug stuff,
now, will report back.

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070329/33153531/attachment-0001.html 

From matt.mcknight at gmail.com  Thu Mar 29 16:33:43 2007
From: matt.mcknight at gmail.com (Matthew McKnight)
Date: Thu, 29 Mar 2007 16:33:43 -0400
Subject: [Mongrel] Mongrel Service won't start on windows
In-Reply-To: <71166b3b0703291311i1d94b6d5q7a19ec70a424f5a8@mail.gmail.com>
References: <e2cb9aee0703290931y506fd42ci92cf470a3c4a012c@mail.gmail.com>
	<71166b3b0703291311i1d94b6d5q7a19ec70a424f5a8@mail.gmail.com>
Message-ID: <e2cb9aee0703291333o56eb64a8g8e7119c118f04ec8@mail.gmail.com>

On 3/29/07, Luis Lavena <luislavena at gmail.com> wrote:
>
> On 3/29/07, Matthew McKnight <matt.mcknight at gmail.com> wrote:
> > Forgot to mention it was working swell before upgrade to install of
> > 1.8.5-21 which cleaned out my gems and then gem install of latest
> > Mongrel/Mongrel Service.
>
> Which version of rails was you using?

were on 1.1.6, now on 1.2.3


>
> > Are these pulling the right win32-service gem?
> >
>
> win32-service gem is only used for installing - removing the service.
>
> Will be safer if you remove previous version of mongrel_service since
> mongrel_service.exe could clash with mongrel_service script, both
> located in ruby\bin folder.

We did a fresh install of 1.85-21, so the old stuff is archived in our
backups.


>  Will also be good to know if you're running a
> 32bits or x64 bits version of Windows, since WinAPI shown some issues
> between platforms.

This is the 64bit OS, we've been running on it fine for about 6 months with
the older versions of stuff.
 Thanks again for the help...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070329/b7f1003c/attachment.html 

From aglarond at gmail.com  Thu Mar 29 17:36:53 2007
From: aglarond at gmail.com (Dimitri Aivaliotis)
Date: Thu, 29 Mar 2007 23:36:53 +0200
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <20070328111403.89dc6bcc.zedshaw@zedshaw.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
	<20070320104415.98b33127.zedshaw@zedshaw.com>
	<55c107bf0703200821j681c0b9cl65065d0f82726174@mail.gmail.com>
	<20070326103126.0dde04d0.zedshaw@zedshaw.com>
	<55c107bf0703280113s122f1646t9880abd7ee7809fe@mail.gmail.com>
	<20070328111403.89dc6bcc.zedshaw@zedshaw.com>
Message-ID: <55c107bf0703291436i71def437pcc0881d3e1b60c84@mail.gmail.com>

On 3/28/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:

> Well, everyone else seems to be getting PID files no problem

This was my clue here.  It seems that everyone else is using
mongrel_rails - I'm not.  I'm trying to setup Mongrel::Configurator to
run just mongrel.  The builder example threw me off because it will
not generate a pid file, no matter what system I run it on.  I've
attached a patch that fixes this.  Could you consider applying it?

The solution is to pass :pid_file to Mongrel::Configurator.new and not
daemonize, as indicated in the example.  You also need to explicitly
call write_pid_file because it's not actually called anywhere within
Mongrel::Configurator itself (looking at mongrel_rails helped here).

Thanks,
- Dimitri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: builder.rb.diff
Type: application/octet-stream
Size: 700 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070329/4afd7993/attachment.obj 

From kaushik.ghose at gmail.com  Thu Mar 29 20:48:41 2007
From: kaushik.ghose at gmail.com (kaushik.ghose)
Date: Thu, 29 Mar 2007 20:48:41 -0400
Subject: [Mongrel] [Fwd: mongrel and spaces in path name : was mongrel on
	vista]
Message-ID: <460C5E69.20007@gmail.com>

Well Luis,

> I noticed that you have ruby installed in a folder with spaces.
>
> That often raises some issues. (couldn't figure out every issue with 
spaces in names, bear with me).
>
> I will check what could be patched in the current code for next release.
>
> For the time being, try relocating your ruby installation to 
something more friendly, like C:\Ruby.

That did the trick!
Thanks for your prompt replies!
-Kaushik


From carl.lerche at gmail.com  Thu Mar 29 22:26:24 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Thu, 29 Mar 2007 19:26:24 -0700
Subject: [Mongrel] Machine reboot - monit fails to start mongrels
In-Reply-To: <466af3440703290805h625f5955ye1858fe7a6f76fec@mail.gmail.com>
References: <F607107B-25E8-428D-B50A-A70ACBF1AB1B@gmail.com>
	<466af3440703290805h625f5955ye1858fe7a6f76fec@mail.gmail.com>
Message-ID: <ab90312e0703291926r26dd1644r9fa28f7f92d2365a@mail.gmail.com>

I just would like to say that I did this on FreeBSD 6.2 and it fails.
The problem is that there seems to be a slight bug in mongrel_cluster
which prevents it to find the pid files (and clean them if necessary).
If you still have trouble, it might be this. Let me know.

I posted about this in another thread.

-carl

On 3/29/07, Joey Geiger <jgeiger at gmail.com> wrote:
> You can use the new mongrel_cluster gem to startup your mongrels one
> at a time, and it will also clear any stale pid files.
>
> Here's an example of part of my monitrc that uses the cluster start.
>
> ###
> # monitor mongrel four
> ###
> check process mongrel-8003
>   with pidfile /var/run/mongrel_cluster/mongrel.8003.pid
>   group mongrel
>   alert monit at website.com only on { connection, resource }
>
>   start program = "/usr/bin/ruby /usr/bin/mongrel_rails cluster::start --only 80
> 03 --clean  -C /etc/mongrel_cluster/website_mongrel_cluster.yml"
>
>   stop program = "/usr/bin/ruby /usr/bin/mongrel_rails cluster::stop --only 8003
>  -C /etc/mongrel_cluster/website_mongrel_cluster.yml"
>
>   if totalmem > 50.0 MB for 5 cycles then restart
>   if cpu is greater than 60% for 2 cycles then alert
>   if cpu > 80% for 5 cycles then restart
>
>   if failed url
>     http://localhost:8003/monit/index
>     and content == 'success'
>     with timeout 15 seconds then restart
>
>
>
>
> On 3/29/07, Henry <hpoydar at gmail.com> wrote:
> > Greetings -
> >
> > I dug around a bit and I couldn't find a definitive answer to this
> > question, apologies if it's been covered before.   A box running a
> > apache 2.2 -> mongrel cluster for a rails app got power cycled at my
> > ISP.  Unfortunately monit couldn't start the mongrel processes
> > because the pid files were still there. Here is my monit config (for
> > each mongrel process):
> >
> > check process myapp_mongrel_8000 with pidfile /data/wwwroot/myapp.com/
> > log/mongrel.8000.pid
> >          start program = "/usr/bin/mongrel_rails start -d -e
> > production -p 8000 -a 127.0.0.1 -P log/mongrel.8000.pid -c /data/
> > wwwroot/myapp.com --user mongrel --group mongrel"
> >          stop program = "/usr/bin/mongrel_rails stop -P log/mongrel.
> > 8000.pid -c /data/wwwroot/myapp.com"
> >          if failed host 127.0.0.1 port 8000 protocol http
> >                  and request "/" then alert
> >          if cpu is greater than 60% for 2 cycles then alert
> >          if cpu > 80% for 5 cycles then restart
> >          if loadavg(5min) greater than 10 for 8 cycles then restart
> >          if 3 restarts within 5 cycles then timeout
> >
> > Is there some other command line switch I can add to avoid this
> > problem?  Should I config monit to clear the .pid files first?
> >
> > Thanks,
> > Henry
> >
> >
> >
> > _______________________________________________
> > 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
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From matt.mcknight at gmail.com  Thu Mar 29 23:02:29 2007
From: matt.mcknight at gmail.com (Matthew McKnight)
Date: Thu, 29 Mar 2007 23:02:29 -0400
Subject: [Mongrel] Mongrel Service won't start on windows
In-Reply-To: <e2cb9aee0703291333o56eb64a8g8e7119c118f04ec8@mail.gmail.com>
References: <e2cb9aee0703290931y506fd42ci92cf470a3c4a012c@mail.gmail.com>
	<71166b3b0703291311i1d94b6d5q7a19ec70a424f5a8@mail.gmail.com>
	<e2cb9aee0703291333o56eb64a8g8e7119c118f04ec8@mail.gmail.com>
Message-ID: <e2cb9aee0703292002t187e2903l689f0199580033dd@mail.gmail.com>

Has anyone had much luck with using the srvany.exe approach with
mongrel? I see some scattered references to it in the archives...
We've used it for Java processes, but they generally don't stop
gracefully with srvany.

From luislavena at gmail.com  Thu Mar 29 23:59:29 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 30 Mar 2007 00:59:29 -0300
Subject: [Mongrel] Mongrel Service won't start on windows
In-Reply-To: <e2cb9aee0703292002t187e2903l689f0199580033dd@mail.gmail.com>
References: <e2cb9aee0703290931y506fd42ci92cf470a3c4a012c@mail.gmail.com>
	<71166b3b0703291311i1d94b6d5q7a19ec70a424f5a8@mail.gmail.com>
	<e2cb9aee0703291333o56eb64a8g8e7119c118f04ec8@mail.gmail.com>
	<e2cb9aee0703292002t187e2903l689f0199580033dd@mail.gmail.com>
Message-ID: <71166b3b0703292059i794a912ava33a690fab4fab17@mail.gmail.com>

On 3/30/07, Matthew McKnight <matt.mcknight at gmail.com> wrote:
> Has anyone had much luck with using the srvany.exe approach with
> mongrel? I see some scattered references to it in the archives...
> We've used it for Java processes, but they generally don't stop
> gracefully with srvany.

Matthew.

One question I have, also raised in previous mails in this list, where
is your ruby.exe located?

Please see the bug post here [1] and my previous mail with Kaushik [2]

srvany is the oposite mongrel_service tries to do: stop gracefully the service.

That way is the same like send kill -9 to your process in linux, they
will stop, but nasty things could happen.

I'll apply the patch provided by David Esposito and pack a release in
the next days with proper handling of logging capabilities.

[1] http://rubyforge.org/tracker/index.php?func=detail&aid=8372&group_id=1306&atid=5147
[2] http://rubyforge.org/pipermail/mongrel-users/2007-March/003370.html

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From zedshaw at zedshaw.com  Fri Mar 30 09:38:58 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 30 Mar 2007 09:38:58 -0400
Subject: [Mongrel] Daemonizing a camping server
In-Reply-To: <55c107bf0703291436i71def437pcc0881d3e1b60c84@mail.gmail.com>
References: <45F6D212.3040002@urbacon.net> <45F8137D.2090707@urbacon.net>
	<20070315055912.36c9d1b9.zedshaw@zedshaw.com>
	<55c107bf0703200617n63471be3p92c8ea4bd035adae@mail.gmail.com>
	<55c107bf0703200653w1437116uc2d71487d7e20e35@mail.gmail.com>
	<20070320104415.98b33127.zedshaw@zedshaw.com>
	<55c107bf0703200821j681c0b9cl65065d0f82726174@mail.gmail.com>
	<20070326103126.0dde04d0.zedshaw@zedshaw.com>
	<55c107bf0703280113s122f1646t9880abd7ee7809fe@mail.gmail.com>
	<20070328111403.89dc6bcc.zedshaw@zedshaw.com>
	<55c107bf0703291436i71def437pcc0881d3e1b60c84@mail.gmail.com>
Message-ID: <20070330093858.125801d0.zedshaw@zedshaw.com>

On Thu, 29 Mar 2007 23:36:53 +0200
"Dimitri Aivaliotis" <aglarond at gmail.com> wrote:

> On 3/28/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> 
> > Well, everyone else seems to be getting PID files no problem
> 
> This was my clue here.  It seems that everyone else is using
> mongrel_rails - I'm not.  I'm trying to setup Mongrel::Configurator to
> run just mongrel.  The builder example threw me off because it will
> not generate a pid file, no matter what system I run it on.  I've
> attached a patch that fixes this.  Could you consider applying it?

Ohhhhhh, you didn't say that, from what I read it seemed like you were
running mongrel_rails.  Yes, the builder is out of sync so thanks for
he patch.
 
> The solution is to pass :pid_file to Mongrel::Configurator.new and not
> daemonize, as indicated in the example.  You also need to explicitly
> call write_pid_file because it's not actually called anywhere within
> Mongrel::Configurator itself (looking at mongrel_rails helped here).

I'll put this on in the next release.  Thanks again.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From matt.mcknight at gmail.com  Fri Mar 30 11:13:43 2007
From: matt.mcknight at gmail.com (Matthew McKnight)
Date: Fri, 30 Mar 2007 11:13:43 -0400
Subject: [Mongrel] Mongrel Service won't start on windows
In-Reply-To: <71166b3b0703292059i794a912ava33a690fab4fab17@mail.gmail.com>
References: <e2cb9aee0703290931y506fd42ci92cf470a3c4a012c@mail.gmail.com>
	<71166b3b0703291311i1d94b6d5q7a19ec70a424f5a8@mail.gmail.com>
	<e2cb9aee0703291333o56eb64a8g8e7119c118f04ec8@mail.gmail.com>
	<e2cb9aee0703292002t187e2903l689f0199580033dd@mail.gmail.com>
	<71166b3b0703292059i794a912ava33a690fab4fab17@mail.gmail.com>
Message-ID: <e2cb9aee0703300813t39b17688h74a75229f313a68@mail.gmail.com>

Luis, here's what we're seeing in servicefb.log under c:\ruby\bin

_initialize() constructor
_initialize() constructor done
ServiceProcess(new_name)
ServiceProcess(new_name) done
ServiceHost()
ServiceHost() done
ServiceHost.Add()
_add_to_references()
_add_to_references() done
ServiceHost.Add() done
ServiceController.RunMode()
CurrentPID: 3400
ParentPID: 584
Parent Name: <unknown>
ServiceController.RunMode() done
ServiceHost() destructor
ServiceHost() destructor done
ServiceProcess() destructor
ServiceProcess() destructor done
_terminate() destructor
_terminate() destructor done


On 3/29/07, Luis Lavena <luislavena at gmail.com> wrote:
> On 3/30/07, Matthew McKnight <matt.mcknight at gmail.com> wrote:
> > Has anyone had much luck with using the srvany.exe approach with
> > mongrel? I see some scattered references to it in the archives...
> > We've used it for Java processes, but they generally don't stop
> > gracefully with srvany.
>
> Matthew.
>
> One question I have, also raised in previous mails in this list, where
> is your ruby.exe located?
>
> Please see the bug post here [1] and my previous mail with Kaushik [2]
>
> srvany is the oposite mongrel_service tries to do: stop gracefully the
> service.
>
> That way is the same like send kill -9 to your process in linux, they
> will stop, but nasty things could happen.
>
> I'll apply the patch provided by David Esposito and pack a release in
> the next days with proper handling of logging capabilities.
>
> [1]
> http://rubyforge.org/tracker/index.php?func=detail&aid=8372&group_id=1306&atid=5147
> [2] http://rubyforge.org/pipermail/mongrel-users/2007-March/003370.html
>
> --
> Luis Lavena
> Multimedia systems
> -
> Leaders are made, they are not born. They are made by hard effort,
> which is the price which all of us must pay to achieve any goal that
> is worthwhile.
> Vince Lombardi
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
-Matt McKnight-
www.lmnsolutions.com

From luislavena at gmail.com  Fri Mar 30 12:07:47 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 30 Mar 2007 13:07:47 -0300
Subject: [Mongrel] Mongrel Service won't start on windows
In-Reply-To: <e2cb9aee0703300813t39b17688h74a75229f313a68@mail.gmail.com>
References: <e2cb9aee0703290931y506fd42ci92cf470a3c4a012c@mail.gmail.com>
	<71166b3b0703291311i1d94b6d5q7a19ec70a424f5a8@mail.gmail.com>
	<e2cb9aee0703291333o56eb64a8g8e7119c118f04ec8@mail.gmail.com>
	<e2cb9aee0703292002t187e2903l689f0199580033dd@mail.gmail.com>
	<71166b3b0703292059i794a912ava33a690fab4fab17@mail.gmail.com>
	<e2cb9aee0703300813t39b17688h74a75229f313a68@mail.gmail.com>
Message-ID: <71166b3b0703300907n7cf745d9x1580836b14c6774c@mail.gmail.com>

On 3/30/07, Matthew McKnight <matt.mcknight at gmail.com> wrote:
> Luis, here's what we're seeing in servicefb.log under c:\ruby\bin
>
> _initialize() constructor
> _initialize() constructor done
> ServiceProcess(new_name)
> ServiceProcess(new_name) done
> ServiceHost()
> ServiceHost() done
> ServiceHost.Add()
> _add_to_references()
> _add_to_references() done
> ServiceHost.Add() done
> ServiceController.RunMode()
> CurrentPID: 3400
> ParentPID: 584
> Parent Name: <unknown>
> ServiceController.RunMode() done
> ServiceHost() destructor
> ServiceHost() destructor done
> ServiceProcess() destructor
> ServiceProcess() destructor done
> _terminate() destructor
> _terminate() destructor done
>
>

What about mongrel_service.log?

Also, is Ruby executable in your path?

It seems that somehow ServiceFB couldn't get parent process name,
which could be WinAPI differences between platforms, must confirm
this.

I'll be rolling a few fixes to mongrel_service in the following hours,
please be alert :-)

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From luislavena at gmail.com  Fri Mar 30 12:08:47 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 30 Mar 2007 13:08:47 -0300
Subject: [Mongrel] Mongrel Service won't start on windows
In-Reply-To: <71166b3b0703300907n7cf745d9x1580836b14c6774c@mail.gmail.com>
References: <e2cb9aee0703290931y506fd42ci92cf470a3c4a012c@mail.gmail.com>
	<71166b3b0703291311i1d94b6d5q7a19ec70a424f5a8@mail.gmail.com>
	<e2cb9aee0703291333o56eb64a8g8e7119c118f04ec8@mail.gmail.com>
	<e2cb9aee0703292002t187e2903l689f0199580033dd@mail.gmail.com>
	<71166b3b0703292059i794a912ava33a690fab4fab17@mail.gmail.com>
	<e2cb9aee0703300813t39b17688h74a75229f313a68@mail.gmail.com>
	<71166b3b0703300907n7cf745d9x1580836b14c6774c@mail.gmail.com>
Message-ID: <71166b3b0703300908x7061cfadr86571e3aec173221@mail.gmail.com>

On 3/30/07, Luis Lavena <luislavena at gmail.com> wrote:
>
> What about mongrel_service.log?
>

Sorry, asking again and you don't have it :-P

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From luislavena at gmail.com  Fri Mar 30 23:13:53 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 31 Mar 2007 00:13:53 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
Message-ID: <71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>

Ok, a follow up on this issue:


On 3/27/07, Luis Lavena <luislavena at gmail.com> wrote:
> [...]
> >
> > Yes, as same as Win32,
> > "services.exe" is the parent process of "svchost.exe", "snmp.exe" ,
> > "mysqld-nt.exe", "VMwareService.exe", etc.
> > and only "services.exe" and "svchost.exe" is 64-bit image.
> >
> > [...]
> >
> > The result is :
> >  this process (PID, name): 2192, proc_info.exe
> >  parent process (PID, name): 3024, <unknown>
> >
> >
> > "<unknown>" is the error or the warning word returned by
> > "_process_name" function of ServiceFB.
> > and "_process_name" function uses Win32API "HANDLE" typedef via FreeBasic libs,
> > and the size of HANDLE of Win32API differs from the other one of Win64API.
> >
>

Ok, guess I have found the problem, quoting msdn article [1]:


"If the specified process is a 64-bit process and the caller is a
32-bit process, this call will fail. Note that you can use the
QueryFullProcessImageName function to retrieve the full name of an
executable image for both 32- and 64-bit processes from a 32-bit
process."


[1] http://msdn2.microsoft.com/en-us/library/ms682489.aspx


BUT, there is always a "but"...

QueryFullProcessImageName is only available in Server 2003 or Vista...
which will be incompatible with XP... since xp psapi.dll don't
implement it.

I'll try to figure some workaround on this matter.

This is actually a "cross-platform" issue, between Win32 and WOW64 :-P

Could you test the attached file?

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_info.7z
Type: application/octet-stream
Size: 16182 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070331/1a313eb5/attachment.obj 

From matt.mcknight at gmail.com  Fri Mar 30 23:31:03 2007
From: matt.mcknight at gmail.com (Matthew McKnight)
Date: Fri, 30 Mar 2007 23:31:03 -0400
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
Message-ID: <e2cb9aee0703302031n571f0805n8ae91296ddfc1c8a@mail.gmail.com>

Sure, we'll give it a shot on Monday. Thanks for the follow-up.

On 3/30/07, Luis Lavena <luislavena at gmail.com> wrote:
> Ok, a follow up on this issue:
>
>
> On 3/27/07, Luis Lavena <luislavena at gmail.com> wrote:
> > [...]
> > >
> > > Yes, as same as Win32,
> > > "services.exe" is the parent process of "svchost.exe", "snmp.exe" ,
> > > "mysqld-nt.exe", "VMwareService.exe", etc.
> > > and only "services.exe" and "svchost.exe" is 64-bit image.
> > >
> > > [...]
> > >
> > > The result is :
> > >  this process (PID, name): 2192, proc_info.exe
> > >  parent process (PID, name): 3024, <unknown>
> > >
> > >
> > > "<unknown>" is the error or the warning word returned by
> > > "_process_name" function of ServiceFB.
> > > and "_process_name" function uses Win32API "HANDLE" typedef via FreeBasic libs,
> > > and the size of HANDLE of Win32API differs from the other one of Win64API.
> > >
> >
>
> Ok, guess I have found the problem, quoting msdn article [1]:
>
>
> "If the specified process is a 64-bit process and the caller is a
> 32-bit process, this call will fail. Note that you can use the
> QueryFullProcessImageName function to retrieve the full name of an
> executable image for both 32- and 64-bit processes from a 32-bit
> process."
>
>
> [1] http://msdn2.microsoft.com/en-us/library/ms682489.aspx
>
>
> BUT, there is always a "but"...
>
> QueryFullProcessImageName is only available in Server 2003 or Vista...
> which will be incompatible with XP... since xp psapi.dll don't
> implement it.
>
> I'll try to figure some workaround on this matter.
>
> This is actually a "cross-platform" issue, between Win32 and WOW64 :-P
>
> Could you test the attached file?
>
> --
> Luis Lavena
> Multimedia systems
> -
> Leaders are made, they are not born. They are made by hard effort,
> which is the price which all of us must pay to achieve any goal that
> is worthwhile.
> Vince Lombardi
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>


-- 
-Matt McKnight-
www.lmnsolutions.com

From pete at nextengine.com  Sat Mar 31 21:17:53 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Sat, 31 Mar 2007 18:17:53 -0700
Subject: [Mongrel] Error with Ruby 1.8.6
Message-ID: <0EC218F3-F237-46BC-A912-2AC849678EC3@nextengine.com>

Hi,

I just upgraded to Ruby 1.8.6 on my Mac development machine and  
here's what I'm seeing when I try to run mongrel (I have the latest  
version of mongrel + fastthread installed).  It seems to be an OS/X  
thing, because this same combo works fine on our Linux server.

Here's the error, have you guys seen anything like this?:

** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
uuid: Found an existing UUID state file: /nextweb/code/trunk/uuid.state
dyld: NSLinkModule() error
dyld: Symbol not found: _rl_filename_completion_function
   Referenced from: /usr/local/lib/ruby/1.8/i686-darwin8.9.1/ 
readline.bundle
   Expected in: flat namespace

script/mdev: line 1: 16097 Trace/BPT trap          mongrel_rails  
start -p 3000 -t 1

Thanks,
Pete

From pete at nextengine.com  Sat Mar 31 22:10:02 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Sat, 31 Mar 2007 19:10:02 -0700
Subject: [Mongrel] Error with Ruby 1.8.6
In-Reply-To: <0EC218F3-F237-46BC-A912-2AC849678EC3@nextengine.com>
References: <0EC218F3-F237-46BC-A912-2AC849678EC3@nextengine.com>
Message-ID: <5BAEDA36-1E71-48D5-8769-810A1EAD6451@nextengine.com>

I found a post that helped me solve this.  In case anyone else has  
this problem, here it is:

http://hivelogic.com/narrative/articles/ruby-rails-mongrel-mysql-osx

-Pete


On Mar 31, 2007, at 6:17 PM, Pete DeLaurentis wrote:

> Hi,
>
> I just upgraded to Ruby 1.8.6 on my Mac development machine and
> here's what I'm seeing when I try to run mongrel (I have the latest
> version of mongrel + fastthread installed).  It seems to be an OS/X
> thing, because this same combo works fine on our Linux server.
>
> Here's the error, have you guys seen anything like this?:
>
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Starting Rails with development environment...
> uuid: Found an existing UUID state file: /nextweb/code/trunk/ 
> uuid.state
> dyld: NSLinkModule() error
> dyld: Symbol not found: _rl_filename_completion_function
>    Referenced from: /usr/local/lib/ruby/1.8/i686-darwin8.9.1/
> readline.bundle
>    Expected in: flat namespace
>
> script/mdev: line 1: 16097 Trace/BPT trap          mongrel_rails
> start -p 3000 -t 1
>
> Thanks,
> Pete
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users