From cronald at gmail.com  Thu Feb  1 21:18:52 2007
From: cronald at gmail.com (Paul King)
Date: Fri, 2 Feb 2007 02:18:52 +0000
Subject: [Mongrel] Monit / mongel_cluster 0.2.2 / mongrel 1.0.1
Message-ID: <2939187c0702011818y28de5c2flcd80daaa06cd3509@mail.gmail.com>

Hi,

I've a few problems with my rails app at the minute, causing mongrels
in a cluster to die, while I debug I've setup monit to keep the site
running.

Problem is, whenever monit starts one of my mongrels via mongrel_rails
cluster::start --only 8000 --clean -C /url/to/yml/file I get the
following in my log/mongrel.log:

** Mongrel available at 127.0.0.1:8000
** Writing PID file to log/mongrel.8000.pid
Define INLINEDIR or HOME in your environment and try again

I also had to make changes to mongrel_cluster 0.2.2's init.rb to give
it the full path to mongrel_rails, otherwise it failed to find it.

If I run the same command line myself, the pup comes up fine.

Anyone got a working example with the new mongrel_cluster functionality?

monitrc:

check process mongrel-8000 with pidfile /path/to/mongrel.8000.pid
        start program = "/usr/local/bin/ruby
/usr/local/bin/mongrel_rails cluster::start --only 8000 --clean -C
/www/path/to/config/mongrel_cluster.yml"

Thanks in advance,
Paul

From joost at spacebabies.nl  Fri Feb  2 02:53:01 2007
From: joost at spacebabies.nl (joost baaij)
Date: Fri, 2 Feb 2007 08:53:01 +0100
Subject: [Mongrel] Mongrels 1.0.1 falling asleep w/ Rails 1.2
Message-ID: <468C8EF9-A6E5-42AC-9F09-0038E91F7590@spacebabies.nl>

I'm a bit surprised I can't find anything about this in the mailing  
list archives. Basically since Mongrel 1.0.1 I've had Mongrels fall  
asleep without any real cause. A deep sleep, actually more like a  
coma. The mongrel in question (I'm using a cluster of three) can not  
be revived. A cluster::stop, then cluster::start is nessesary.

A ::restart would not help, but no ruby processes were left running.  
The comatose Mongrel's pidfile would still be there though.

I can find no apparent reason in the logs, but this situation did  
occur VERY frequently, most often overnight. I run a very agile site  
with lots of restarts, so maybe it has to do with that (no restarts  
during the night, a memory leak somewhere?).

It started with Mongrel 1.0.1 but .... just a few days before I  
upgraded to Mongrel 1.0.1, I upgraded to Rails 1.2.

So I'm not sure who's the culprit. A few days ago I switched to the  
lsapi RailsRunner and the problem has disappeared, so Mongrel  
definitely is involved.


Just thought I'd give it a mention.

Ant btw Zed: the .nl welcomes you, the land of cheese and clogs.  
Actually it's nice here, you should visit us someday!

Joost.


From eden.li at gmail.com  Fri Feb  2 05:42:28 2007
From: eden.li at gmail.com (Eden Li)
Date: Fri, 2 Feb 2007 18:42:28 +0800
Subject: [Mongrel] Mongrels 1.0.1 falling asleep w/ Rails 1.2
In-Reply-To: <468C8EF9-A6E5-42AC-9F09-0038E91F7590@spacebabies.nl>
References: <468C8EF9-A6E5-42AC-9F09-0038E91F7590@spacebabies.nl>
Message-ID: <565dbdd40702020242h3b321ee6i56ac02399c8323f4@mail.gmail.com>

We'll probably need a bit more information here.  Are you running on Windows
or *nix?  Are you using acts_as_ferret?  Are you letting Rails/Ruby rotate
log files?  Does this occur with a single instance of Mongrel, or only
behind your load balancer?  Do you snore at night? etc ;-)

On 2/2/07, joost baaij <joost at spacebabies.nl> wrote:
>
> I'm a bit surprised I can't find anything about this in the mailing
> list archives. Basically since Mongrel 1.0.1 I've had Mongrels fall
> asleep without any real cause. A deep sleep, actually more like a
> coma. The mongrel in question (I'm using a cluster of three) can not
> be revived. A cluster::stop, then cluster::start is nessesary.
>
> A ::restart would not help, but no ruby processes were left running.
> The comatose Mongrel's pidfile would still be there though.
>
> I can find no apparent reason in the logs, but this situation did
> occur VERY frequently, most often overnight. I run a very agile site
> with lots of restarts, so maybe it has to do with that (no restarts
> during the night, a memory leak somewhere?).
>
> It started with Mongrel 1.0.1 but .... just a few days before I
> upgraded to Mongrel 1.0.1, I upgraded to Rails 1.2.
>
> So I'm not sure who's the culprit. A few days ago I switched to the
> lsapi RailsRunner and the problem has disappeared, so Mongrel
> definitely is involved.
>
>
> Just thought I'd give it a mention.
>
> Ant btw Zed: the .nl welcomes you, the land of cheese and clogs.
> Actually it's nice here, you should visit us someday!
>
> Joost.
>
> _______________________________________________
> 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/20070202/e01e874d/attachment.html 

From joost at spacebabies.nl  Fri Feb  2 06:10:03 2007
From: joost at spacebabies.nl (joost baaij)
Date: Fri, 2 Feb 2007 12:10:03 +0100
Subject: [Mongrel] Mongrels 1.0.1 falling asleep w/ Rails 1.2
In-Reply-To: <565dbdd40702020242h3b321ee6i56ac02399c8323f4@mail.gmail.com>
References: <468C8EF9-A6E5-42AC-9F09-0038E91F7590@spacebabies.nl>
	<565dbdd40702020242h3b321ee6i56ac02399c8323f4@mail.gmail.com>
Message-ID: <DCA12415-7F28-462F-B69A-988071A92231@spacebabies.nl>

*nix, Linux. No, not acts_as_ferret. I'm truncating log files  
manually every week or so, this has never been a problem anyway. Cpu,  
disk and network are all available in abundance.

I couldn't say it also happens with a single instance, but definitely  
behind the load balancer. And then only one mongrel out of three.  
Always the one with lowest port (9000). He/she isn't home trained  
anymore and will leave a .pid file behind. The other two are fine.

I don't snore ;) and you shouldn't invest much effort tracing this one.

It might be a quirk in my setup, or specific for LiteSpeed or any of  
my plugins, or Ruby (1.8.4). It's no big problem since my app runs  
just fine with lsapi too. I just wanted to share. As I seem to be the  
only one, must be my setup?


Thanks
J.

Op 2-feb-2007, om 11:42 heeft Eden Li het volgende geschreven:

> We'll probably need a bit more information here.  Are you running  
> on Windows or *nix?  Are you using acts_as_ferret?  Are you letting  
> Rails/Ruby rotate log files?  Does this occur with a single  
> instance of Mongrel, or only behind your load balancer?  Do you  
> snore at night? etc ;-)
>
> On 2/2/07, joost baaij <joost at spacebabies.nl> wrote: I'm a bit  
> surprised I can't find anything about this in the mailing
> list archives. Basically since Mongrel 1.0.1 I've had Mongrels fall
> asleep without any real cause. A deep sleep, actually more like a
> coma. The mongrel in question (I'm using a cluster of three) can not
> be revived. A cluster::stop, then cluster::start is nessesary.
>
> A ::restart would not help, but no ruby processes were left running.
> The comatose Mongrel's pidfile would still be there though.
>
> I can find no apparent reason in the logs, but this situation did
> occur VERY frequently, most often overnight. I run a very agile site
> with lots of restarts, so maybe it has to do with that (no restarts
> during the night, a memory leak somewhere?).
>
> It started with Mongrel 1.0.1 but .... just a few days before I
> upgraded to Mongrel 1.0.1, I upgraded to Rails 1.2.
>
> So I'm not sure who's the culprit. A few days ago I switched to the
> lsapi RailsRunner and the problem has disappeared, so Mongrel
> definitely is involved.
>
>
> Just thought I'd give it a mention.
>
> Ant btw Zed: the .nl welcomes you, the land of cheese and clogs.
> Actually it's nice here, you should visit us someday!
>
> Joost.
>
> _______________________________________________
> 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/20070202/2f578518/attachment.bin 

From luislavena at gmail.com  Fri Feb  2 08:36:58 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 2 Feb 2007 10:36:58 -0300
Subject: [Mongrel] Mongrels 1.0.1 falling asleep w/ Rails 1.2
In-Reply-To: <DCA12415-7F28-462F-B69A-988071A92231@spacebabies.nl>
References: <468C8EF9-A6E5-42AC-9F09-0038E91F7590@spacebabies.nl>
	<565dbdd40702020242h3b321ee6i56ac02399c8323f4@mail.gmail.com>
	<DCA12415-7F28-462F-B69A-988071A92231@spacebabies.nl>
Message-ID: <71166b3b0702020536j4aa05a4evf0d15ebfe11e71cd@mail.gmail.com>

On 2/2/07, joost baaij <joost at spacebabies.nl> wrote:
> *nix, Linux. No, not acts_as_ferret. I'm truncating log files
> manually every week or so, this has never been a problem anyway. Cpu,
> disk and network are all available in abundance.
>

Are you using fastthread? Is mandatory since ruby leaks memory in his
threading/mutex/syncing functions.

> I couldn't say it also happens with a single instance, but definitely
> behind the load balancer. And then only one mongrel out of three.
> Always the one with lowest port (9000). He/she isn't home trained
> anymore and will leave a .pid file behind. The other two are fine.
>

If just happen with one instance, could you switch it to debug mode?

> I don't snore ;) and you shouldn't invest much effort tracing this one.
>

Its weird that the nly one dying is the lowest port mongrel, also "all
the time".

Could you share your mongrel_cluster.yml?

Also, which load balancer? and its configuration file? (Often the load
balancer aren't set to balance anything, have seen this before).

> It might be a quirk in my setup, or specific for LiteSpeed or any of
> my plugins, or Ruby (1.8.4). It's no big problem since my app runs
> just fine with lsapi too. I just wanted to share. As I seem to be the
> only one, must be my setup?
>

Ok, which plugins are you using? memcached-client?

Turn debug logging (refer to Super Debugging mode in mongrel site:
http://mongrel.rubyforge.org/docs/howto.html)


>
> Thanks
> J.
>
> Op 2-feb-2007, om 11:42 heeft Eden Li het volgende geschreven:
>
> > We'll probably need a bit more information here.  Are you running
> > on Windows or *nix?  Are you using acts_as_ferret?  Are you letting
> > Rails/Ruby rotate log files?  Does this occur with a single
> > instance of Mongrel, or only behind your load balancer?  Do you
> > snore at night? etc ;-)
> >
> > On 2/2/07, joost baaij <joost at spacebabies.nl> wrote: I'm a bit
> > surprised I can't find anything about this in the mailing
> > list archives. Basically since Mongrel 1.0.1 I've had Mongrels fall
> > asleep without any real cause. A deep sleep, actually more like a
> > coma. The mongrel in question (I'm using a cluster of three) can not
> > be revived. A cluster::stop, then cluster::start is nessesary.
> >
> > A ::restart would not help, but no ruby processes were left running.
> > The comatose Mongrel's pidfile would still be there though.
> >
> > I can find no apparent reason in the logs, but this situation did
> > occur VERY frequently, most often overnight. I run a very agile site
> > with lots of restarts, so maybe it has to do with that (no restarts
> > during the night, a memory leak somewhere?).
> >
> > It started with Mongrel 1.0.1 but .... just a few days before I
> > upgraded to Mongrel 1.0.1, I upgraded to Rails 1.2.
> >
> > So I'm not sure who's the culprit. A few days ago I switched to the
> > lsapi RailsRunner and the problem has disappeared, so Mongrel
> > definitely is involved.
> >
> >
> > Just thought I'd give it a mention.
> >
> > Ant btw Zed: the .nl welcomes you, the land of cheese and clogs.
> > Actually it's nice here, you should visit us someday!
> >
> > Joost.
> >
> > _______________________________________________
> > 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
>
>
>
> _______________________________________________
> 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 tmacedo at student.dei.uc.pt  Fri Feb  2 09:43:29 2007
From: tmacedo at student.dei.uc.pt (Tiago Macedo)
Date: Fri, 02 Feb 2007 14:43:29 +0000
Subject: [Mongrel] Mongrel and MemcacheSessionStore
Message-ID: <45C34E11.9060608@student.dei.uc.pt>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,

I've been using Mongrel for quite some time now but I ran into an issue
that threw me back to lighttpd + fastcgi.

The application in question was running fine in the production
environment with SQLSessionStore and using a mongrel cluster behind a
load balancer. However, by switching to a MemcacheSessionStore (using
either memcache-client or Ruby-MemCache), users kept being logged out
due to the fact that the processes lost their connection to the memcache
server (they reconnected but the users were already "logged out").

The funny thing is that this behaviour didn't occur if only one mongrel
process was running.

This was using mongrel 0.3.13.4 without fastthread. Switching the
application back to fastcgi solved the problem.

I was wondering if this was a known issue or if anyone else had this
problem before. Maybe switching to Mongrel 1.0.1 with fastthread solves
this?


Thanks,
Tiago Macedo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFw04RxFuRTtCTMvIRAoXHAJ41fxL1G/TPyIGgCMrWrbx8WX2fqwCeI26Q
gdK8xLTsbflH4J4/BFn9Ut4=
=CsME
-----END PGP SIGNATURE-----


From zedshaw at zedshaw.com  Fri Feb  2 14:26:53 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 2 Feb 2007 11:26:53 -0800
Subject: [Mongrel] Mongrel and MemcacheSessionStore
In-Reply-To: <45C34E11.9060608@student.dei.uc.pt>
References: <45C34E11.9060608@student.dei.uc.pt>
Message-ID: <20070202112653.6eea0fd4.zedshaw@zedshaw.com>

On Fri, 02 Feb 2007 14:43:29 +0000
Tiago Macedo <tmacedo at student.dei.uc.pt> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hey,
> 
> I've been using Mongrel for quite some time now but I ran into an issue
> that threw me back to lighttpd + fastcgi.
> 
> The application in question was running fine in the production
> environment with SQLSessionStore and using a mongrel cluster behind a
> load balancer. However, by switching to a MemcacheSessionStore (using
> either memcache-client or Ruby-MemCache), users kept being logged out
> due to the fact that the processes lost their connection to the memcache
> server (they reconnected but the users were already "logged out").
> 
> The funny thing is that this behaviour didn't occur if only one mongrel
> process was running.
> 
> This was using mongrel 0.3.13.4 without fastthread. Switching the
> application back to fastcgi solved the problem.
> 
> I was wondering if this was a known issue or if anyone else had this
> problem before. Maybe switching to Mongrel 1.0.1 with fastthread solves
> this?

Do you have log files and exception traces to look at?  Without a stack trace showing memcache getting suddenly disconnected it's difficult to figure out what could be wrong.  Try with 1.0.1 and fastthread, and then if not file a bug.  The problem is there's not much of a reason why fastcgi vs. Mongrel would be the difference. The problem you describe sounds more like a problem of memcache storage levels.  Are you able to see how full the memcache is when this is happening?

As an aside, I haven't found a compelling reason to put sessions into a memcache.  The problem is that if you have large amounts of session data then memcache will frequently "lose sessions" because it rotates them out too frequently.  This means that sessions can't be reliably maintained for your set period and there's a good chance you'll piss off customers under heavy loads.

Typically people use memcache for their sessions thinking it'll solve a deeper problem:  Java Session Bloat Syndrome.  Rails works better when you store a minimal amount of information with just basic types into the session, and then use the database for the rest of your storage.  What recovering Java programmers do is assume that the session is faster than the database and so they store intermediate objects during process workflows in the session.

So, my recommendation is to go with sql sessions and also trim the size of your sessions down.  Then run some benchmarks of your pages with sql store and with memcache, but ALSO run a test where you have an insane number of users enter the site and try to maintain their session.  This second test will show you the failing of memcache.

But do see if you can reproduce the bug in a simplified form under 1.0.1 and fastthread.

-- 
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.

From zedshaw at zedshaw.com  Fri Feb  2 14:30:09 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 2 Feb 2007 11:30:09 -0800
Subject: [Mongrel] Mongrels 1.0.1 falling asleep w/ Rails 1.2
In-Reply-To: <DCA12415-7F28-462F-B69A-988071A92231@spacebabies.nl>
References: <468C8EF9-A6E5-42AC-9F09-0038E91F7590@spacebabies.nl>
	<565dbdd40702020242h3b321ee6i56ac02399c8323f4@mail.gmail.com>
	<DCA12415-7F28-462F-B69A-988071A92231@spacebabies.nl>
Message-ID: <20070202113009.28324268.zedshaw@zedshaw.com>

On Fri, 2 Feb 2007 12:10:03 +0100
joost baaij <joost at spacebabies.nl> wrote:

> *nix, Linux. No, not acts_as_ferret. I'm truncating log files  
> manually every week or so, this has never been a problem anyway. Cpu,  
> disk and network are all available in abundance.
> 
> I couldn't say it also happens with a single instance, but definitely  
> behind the load balancer. And then only one mongrel out of three.  
> Always the one with lowest port (9000). He/she isn't home trained  
> anymore and will leave a .pid file behind. The other two are fine.
> 
> I don't snore ;) and you shouldn't invest much effort tracing this one.
> 
> It might be a quirk in my setup, or specific for LiteSpeed or any of  
> my plugins, or Ruby (1.8.4). It's no big problem since my app runs  
> just fine with lsapi too. I just wanted to share. As I seem to be the  
> only one, must be my setup?

I'd be curious to find out what causes it.  Memcache is the culprit these days with it's dumbass requirement that keys have no spaces or \0 characters and people still trying to put those keys in.  When this happens the whole world stops.

If you don't have memcache, then what you can do is wait until a mongrel "sleeps", then run strace on the process to see what it's doing, if anything.  After that, I got some other stuff you could try out using gdb.

-- 
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.

From alan_maszt at yahoo.com  Fri Feb  2 11:51:42 2007
From: alan_maszt at yahoo.com (Alan Maszt)
Date: Fri, 2 Feb 2007 08:51:42 -0800 (PST)
Subject: [Mongrel] Win32 Service Commands Missing?
Message-ID: <366313.40880.qm@web57703.mail.re3.yahoo.com>

I've upgraded from version 0.3.13.3 to 1.0.1 (along with dependencies). I can see service::install and service::remove commands, but not service::start and service::stop. Moreover, after installing the service with service::install, the service shows up on the list in Control Panel/Administrative Tools/Services, but fails to start from there.



1. Unless the documentation on the website is obsolete. I'd expect service::start and service::stop to be available.


2. The whole thing seems to be caused by mongrel_service 0.3.1 mswin32. If I revert to the previous version (0.1 ruby) the missing options show up and the service starts even with mongrel 1.0.1.


Any hints appreciated,

alan





 
____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.

From zedshaw at zedshaw.com  Fri Feb  2 15:52:05 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 2 Feb 2007 12:52:05 -0800
Subject: [Mongrel] Win32 Service Commands Missing?
In-Reply-To: <366313.40880.qm@web57703.mail.re3.yahoo.com>
References: <366313.40880.qm@web57703.mail.re3.yahoo.com>
Message-ID: <20070202125205.7fe756ea.zedshaw@zedshaw.com>

On Fri, 2 Feb 2007 08:51:42 -0800 (PST)
Alan Maszt <alan_maszt at yahoo.com> wrote:

> I've upgraded from version 0.3.13.3 to 1.0.1 (along with dependencies). I can see service::install and service::remove commands, but not service::start and service::stop. Moreover, after installing the service with service::install, the service shows up on the list in Control Panel/Administrative Tools/Services, but fails to start from there.
> 
> 
> 
> 1. Unless the documentation on the website is obsolete. I'd expect service::start and service::stop to be available.
> 
> 
> 2. The whole thing seems to be caused by mongrel_service 0.3.1 mswin32. If I revert to the previous version (0.1 ruby) the missing options show up and the service starts even with mongrel 1.0.1.

Yeah that's a typo I gotta fix.  Try just play start/stop (without the service::).

-- 
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.

From mi-mongrel at moensolutions.com  Fri Feb  2 13:06:09 2007
From: mi-mongrel at moensolutions.com (Michael Moen)
Date: Fri, 2 Feb 2007 10:06:09 -0800
Subject: [Mongrel] Mongrel and MemcacheSessionStore
In-Reply-To: <20070202112653.6eea0fd4.zedshaw@zedshaw.com>
References: <45C34E11.9060608@student.dei.uc.pt>
	<20070202112653.6eea0fd4.zedshaw@zedshaw.com>
Message-ID: <9FEB81E3-D2AD-4014-96B9-EC05F065B2C3@moensolutions.com>


On Feb 2, 2007, at 11:26 AM, Zed A. Shaw wrote:

> On Fri, 02 Feb 2007 14:43:29 +0000
> Tiago Macedo <tmacedo at student.dei.uc.pt> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> I was wondering if this was a known issue or if anyone else had this
>> problem before. Maybe switching to Mongrel 1.0.1 with fastthread  
>> solves
>> this?
>
> Do you have log files and exception traces to look at?  Without a  
> stack trace showing memcache getting suddenly disconnected it's  
> difficult to figure out what could be wrong.  Try with 1.0.1 and  
> fastthread, and then if not file a bug.  The problem is there's not  
> much of a reason why fastcgi vs. Mongrel would be the difference.  
> The problem you describe sounds more like a problem of memcache  
> storage levels.  Are you able to see how full the memcache is when  
> this is happening?

I can vouch for the fact that Mongrel and memcache sessions play just  
fine together. JibJab has been using them for about 6 months without  
issue, though they do have a truck load of memcache storage. the  
amount of data stored in session is also very small, user_id and  
string or 2 when needed.

> As an aside, I haven't found a compelling reason to put sessions  
> into a memcache.

They are doing it because there is still enough legacy .NET code  
that's not using memcache to keep the DB pretty busy, but under  
normal conditions keeping sessions in the DB is a better choice as it  
will survive a memcache restart.

Michael-



From luislavena at gmail.com  Fri Feb  2 17:04:25 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 2 Feb 2007 19:04:25 -0300
Subject: [Mongrel] Win32 Service Commands Missing?
In-Reply-To: <366313.40880.qm@web57703.mail.re3.yahoo.com>
References: <366313.40880.qm@web57703.mail.re3.yahoo.com>
Message-ID: <71166b3b0702021404q162f8076h5d5e32c4e218f614@mail.gmail.com>

On 2/2/07, Alan Maszt <alan_maszt at yahoo.com> wrote:
> I've upgraded from version 0.3.13.3 to 1.0.1 (along with dependencies). I can see service::install and service::remove commands, but not service::start and service::stop. Moreover, after installing the service with service::install, the service shows up on the list in Control Panel/Administrative Tools/Services, but fails to start from there.
>

Could you Copy&Paste the command line used to install the service?

A mandatory parameter is -c (chdir) so mongrel_service will know where
to find your rails application

Also, if the service was installed with previous versions of service::
command, remove it and recreate, the syntax passed to the service
differ.

(And remember remove the prior version of mongrel_service also, could
show up conflicts).


You could try if your rails application start properly doing:

mongrel_service console single [your mongrel_rails params]

Ex:
mongrel_service console single -c "C:/My Rails App" -p 4000 -e production

>
>
> 1. Unless the documentation on the website is obsolete. I'd expect service::start and service::stop to be available.
>

I posted several weeks ago (plugin beta of mongrel_service) that
::start and ::stop were replaced by plain simple "net start
service_name" (less keystrokes):

"mongrel_rails service::start -N myservice".length
=> 41

"net start myservice".length
=> 19

:-)

>
> 2. The whole thing seems to be caused by mongrel_service 0.3.1 mswin32. If I revert to the previous version (0.1 ruby) the missing options show up and the service starts even with mongrel 1.0.1.
>

Beside the start/stop missing from service stuff, there are more
important things that differ between both versions:

1) The new service process is not Ruby based, but a 3rd party
executable that spawn your mongrel_rails (and your rails application).
This is the safest scenario, no win32-service native threading mixing
with ruby green threads (that often caused the services to fail on
stop).

2) Not injecting stuff into your mongrel+rails process benefits you,
reducing possible point of failure due faulty code committed by me in
a 48hs hacking session.

I'll update the docs when return to office, so next time zed publish
the site will be correct.

-- 
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 steven at lumos.us  Sat Feb  3 01:03:01 2007
From: steven at lumos.us (Steven Lumos)
Date: Fri, 02 Feb 2007 22:03:01 -0800
Subject: [Mongrel] Mongrels 1.0.1 falling asleep w/ Rails 1.2
References: <468C8EF9-A6E5-42AC-9F09-0038E91F7590@spacebabies.nl>
Message-ID: <868xffg4mi.fsf@bitty.lumos.us>

joost baaij <joost at spacebabies.nl> writes:
> I'm a bit surprised I can't find anything about this in the mailing  
> list archives.

So am I, because it's there.

> Basically since Mongrel 1.0.1 I've had Mongrels fall asleep without
> any real cause. A deep sleep, actually more like a coma. The mongrel
> in question (I'm using a cluster of three) can not be revived. A
> cluster::stop, then cluster::start is nessesary.
>
> A ::restart would not help, but no ruby processes were left running.  
> The comatose Mongrel's pidfile would still be there though.
>
> I can find no apparent reason in the logs, but this situation did  
> occur VERY frequently, most often overnight. I run a very agile site  
> with lots of restarts, so maybe it has to do with that (no restarts  
> during the night, a memory leak somewhere?).
>
> It started with Mongrel 1.0.1 but .... just a few days before I  
> upgraded to Mongrel 1.0.1, I upgraded to Rails 1.2.
>
> So I'm not sure who's the culprit. A few days ago I switched to the  
> lsapi RailsRunner and the problem has disappeared, so Mongrel  
> definitely is involved.
>
>
> Just thought I'd give it a mention.
>
> Ant btw Zed: the .nl welcomes you, the land of cheese and clogs.  
> Actually it's nice here, you should visit us someday!
>
> Joost.

The deadly combination for me seems to be the Oracle adapter and
running in development mode (which I only do when developing so it's
been a major annoyance but not a show stopper).

Then fastthread showed up and the problem vanished.  Poof.

Steve



From joost at spacebabies.nl  Sun Feb  4 11:19:34 2007
From: joost at spacebabies.nl (joost baaij)
Date: Sun, 4 Feb 2007 17:19:34 +0100
Subject: [Mongrel] Mongrels 1.0.1 falling asleep w/ Rails 1.2
In-Reply-To: <71166b3b0702020536j4aa05a4evf0d15ebfe11e71cd@mail.gmail.com>
References: <468C8EF9-A6E5-42AC-9F09-0038E91F7590@spacebabies.nl>
	<565dbdd40702020242h3b321ee6i56ac02399c8323f4@mail.gmail.com>
	<DCA12415-7F28-462F-B69A-988071A92231@spacebabies.nl>
	<71166b3b0702020536j4aa05a4evf0d15ebfe11e71cd@mail.gmail.com>
Message-ID: <5F814275-6508-4035-BDAA-600C6277F181@spacebabies.nl>


Op 2-feb-2007, om 14:36 heeft Luis Lavena het volgende geschreven:

> Are you using fastthread? Is mandatory since ruby leaks memory in his
> threading/mutex/syncing functions.

Yep, per the gem so should be fine.

> If just happen with one instance, could you switch it to debug mode?

I'll do that but won't be able to run Mongrel in production. I'll  
just throw apachebench or something at them to simulate a load.

> Could you share your mongrel_cluster.yml?

---
cwd: /home/websites/gomagazine
port: "9000"
environment: production
address: 127.0.0.1
pid_file: log/mongrel.pid
servers: 3

> Also, which load balancer? and its configuration file? (Often the load
> balancer aren't set to balance anything, have seen this before).

The software load balancer inside LiteSpeed. Funny you should say  
that as I had a feeling it wasn't functioning anyway. So that  
definitely could be an option.

> Ok, which plugins are you using? memcached-client?

No.

I'll enable debug logging but might be a while.

J.


From joost at spacebabies.nl  Sun Feb  4 11:21:21 2007
From: joost at spacebabies.nl (joost baaij)
Date: Sun, 4 Feb 2007 17:21:21 +0100
Subject: [Mongrel] Mongrels 1.0.1 falling asleep w/ Rails 1.2
In-Reply-To: <20070202113009.28324268.zedshaw@zedshaw.com>
References: <468C8EF9-A6E5-42AC-9F09-0038E91F7590@spacebabies.nl>
	<565dbdd40702020242h3b321ee6i56ac02399c8323f4@mail.gmail.com>
	<DCA12415-7F28-462F-B69A-988071A92231@spacebabies.nl>
	<20070202113009.28324268.zedshaw@zedshaw.com>
Message-ID: <B3C8ECDB-3F25-4500-A773-EF91A83D5F71@spacebabies.nl>


Op 2-feb-2007, om 20:30 heeft Zed A. Shaw het volgende geschreven:

> If you don't have memcache, then what you can do is wait until a  
> mongrel "sleeps", then run strace on the process to see what it's  
> doing, if anything.  After that, I got some other stuff you could  
> try out using gdb.


I'll start 'em up again, but won't use them in production. We'll see  
if the problem occurs and I'll get back to y'all. Much thanks for all  
the help though, it's appreciated.

J.

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




From cronald at gmail.com  Sun Feb  4 11:50:55 2007
From: cronald at gmail.com (Paul King)
Date: Sun, 4 Feb 2007 16:50:55 +0000
Subject: [Mongrel] Monit / mongel_cluster 0.2.2 / mongrel 1.0.1
In-Reply-To: <2939187c0702011818y28de5c2flcd80daaa06cd3509@mail.gmail.com>
References: <2939187c0702011818y28de5c2flcd80daaa06cd3509@mail.gmail.com>
Message-ID: <2939187c0702040850y64ccc113uf9a9bb96beb62472@mail.gmail.com>

Hi,

I've fixed the below (previous post) which was simply a case of
reading the monit manual (it nukes most of the environment settings
when it runs the script).

Now I'm in a position to debug my problem, which is (I think)
image_science crashing mongrel during processing of an uploaded file
with a message of: terminate called after throwing an instance of
'int'.

I'm finding it difficult to reproduce the crash reliably as uploading
the same file works sometimes and not others.  I've tried running
mongrel with -B, and using killall -USR1 but nothing out of the
ordinary is being reported.

I've also tried strace-ing the mongrel process and this snippet is the
closest I can get to something useful:

open("/tmp/rpupload6375.0", O_RDONLY)   = 12 <0.000113>
futex(0xb6179e2c, FUTEX_WAKE, 2147483647) = 0 <0.000088>
futex(0xb60a41a4, FUTEX_WAKE, 2147483647) = 0 <0.000081>
write(2, "terminate called after throwing an instance of \'", 48) = 48
<0.000137>
write(2, "int", 3)                      = 3 <0.000092>
write(2, "\'\n", 2)                     = 2 <0.000091>
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 <0.000146>
tgkill(6375, 6375, SIGABRT)             = 0 <0.000083>
--- SIGABRT (Aborted) @ 0 (0) ---

Is it perhaps some sort of file locking issue?   Any ideas on how I
could go about better tracking down the problem?

Thanks,
- Paul

----------------

> I've a few problems with my rails app at the minute, causing mongrels in a cluster to die, while I debug I've setup monit to keep the site running.

> Problem is, whenever monit starts one of my mongrels via mongrel_rails cluster::start --only 8000 --clean -C /url/to/yml/file I get the following in my log/mongrel.log:

> ** Mongrel available at 127.0.0.1:8000
> ** Writing PID file to log/mongrel.8000.pid
> Define INLINEDIR or HOME in your environment and try again

> I also had to make changes to mongrel_cluster 0.2.2's init.rb to give it the full path to mongrel_rails, otherwise it failed to find it.

[snip]

From snacktime at gmail.com  Sun Feb  4 20:24:31 2007
From: snacktime at gmail.com (snacktime)
Date: Sun, 4 Feb 2007 17:24:31 -0800
Subject: [Mongrel] Mongrel and MemcacheSessionStore
In-Reply-To: <45C34E11.9060608@student.dei.uc.pt>
References: <45C34E11.9060608@student.dei.uc.pt>
Message-ID: <1f060c4c0702041724i7ca0fb1n81683bc4af0551ff@mail.gmail.com>

> The application in question was running fine in the production
> environment with SQLSessionStore and using a mongrel cluster behind a
> load balancer. However, by switching to a MemcacheSessionStore (using
> either memcache-client or Ruby-MemCache), users kept being logged out
> due to the fact that the processes lost their connection to the memcache
> server (they reconnected but the users were already "logged out").

Personally, I wouldn't ever use memcache without a persistent backing
store for sessions.    It works best when writes always hit memcache
and the backing store, and reads check memcache first then fall back
to the persistent store.  Assuming a normal scenario where you aren't
writing to the session store that often, then your cache hit rate will
still be pretty good and your site won't stop working if memcache
fails.


Chris

From jgeiger at gmail.com  Sun Feb  4 22:18:38 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Sun, 4 Feb 2007 21:18:38 -0600
Subject: [Mongrel] Mongrel and MemcacheSessionStore
In-Reply-To: <1f060c4c0702041724i7ca0fb1n81683bc4af0551ff@mail.gmail.com>
References: <45C34E11.9060608@student.dei.uc.pt>
	<1f060c4c0702041724i7ca0fb1n81683bc4af0551ff@mail.gmail.com>
Message-ID: <466af3440702041918p6137d3beu29b1938a0068b21f@mail.gmail.com>

I like this idea, do you have an example or suggestions on how you
could implement it easily?


On 2/4/07, snacktime <snacktime at gmail.com> wrote:
> > The application in question was running fine in the production
> > environment with SQLSessionStore and using a mongrel cluster behind a
> > load balancer. However, by switching to a MemcacheSessionStore (using
> > either memcache-client or Ruby-MemCache), users kept being logged out
> > due to the fact that the processes lost their connection to the memcache
> > server (they reconnected but the users were already "logged out").
>
> Personally, I wouldn't ever use memcache without a persistent backing
> store for sessions.    It works best when writes always hit memcache
> and the backing store, and reads check memcache first then fall back
> to the persistent store.  Assuming a normal scenario where you aren't
> writing to the session store that often, then your cache hit rate will
> still be pretty good and your site won't stop working if memcache
> fails.
>
>
> Chris
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From franck.dagostini at gmail.com  Mon Feb  5 07:46:42 2007
From: franck.dagostini at gmail.com (Franck)
Date: Mon, 5 Feb 2007 13:46:42 +0100
Subject: [Mongrel] Mongrel and MemcacheSessionStore
In-Reply-To: <466af3440702041918p6137d3beu29b1938a0068b21f@mail.gmail.com>
References: <45C34E11.9060608@student.dei.uc.pt>
	<1f060c4c0702041724i7ca0fb1n81683bc4af0551ff@mail.gmail.com>
	<466af3440702041918p6137d3beu29b1938a0068b21f@mail.gmail.com>
Message-ID: <984de6020702050446l33ff319bk7a3aad3c17afda0@mail.gmail.com>

I experienced Tiago's problem.

I store in session a little string telling the application what's the
current language (e.g 'fr' for french).

Users kept being switched back to default language because the session ends
prematurely. Playing with memcache expiration time don't solve the issue. I
switch to SQLSessionStore and the problem is gone.

Like Tiago, I am in production environment with a bunch of mongrel  behind a
load balancer (apache2).

As my sysadmin skill isn't that good, I didn't investigate further and I
will stay with SQLSessionStore.

Franck

y sysadmin skilled

On 2/5/07, Joey Geiger <jgeiger at gmail.com> wrote:
>
> I like this idea, do you have an example or suggestions on how you
> could implement it easily?
>
>
> On 2/4/07, snacktime <snacktime at gmail.com> wrote:
> > > The application in question was running fine in the production
> > > environment with SQLSessionStore and using a mongrel cluster behind a
> > > load balancer. However, by switching to a MemcacheSessionStore (using
> > > either memcache-client or Ruby-MemCache), users kept being logged out
> > > due to the fact that the processes lost their connection to the
> memcache
> > > server (they reconnected but the users were already "logged out").
> >
> > Personally, I wouldn't ever use memcache without a persistent backing
> > store for sessions.    It works best when writes always hit memcache
> > and the backing store, and reads check memcache first then fall back
> > to the persistent store.  Assuming a normal scenario where you aren't
> > writing to the session store that often, then your cache hit rate will
> > still be pretty good and your site won't stop working if memcache
> > fails.
> >
> >
> > Chris
> > _______________________________________________
> > 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/20070205/7fc5b15b/attachment.html 

From erik.hetzner at ucop.edu  Mon Feb  5 17:16:44 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Mon, 05 Feb 2007 14:16:44 -0800
Subject: [Mongrel] recv vs. read in HTTPRequest#read_socket
Message-ID: <87bqk8l06r.wl%erik.hetzner@ucop.edu>

Hello all,

The following change to Mongrel::HttpRequest:

def read_socket(len)
  if !@socket.closed?
    data = @socket.recv(len) # <--- formerly @socket.read(len)
    if !data
      raise "Socket read return nil"
    elsif data.length != len
      raise "Socket read returned insufficient data: #{data.length}"
    else
      data
    end
  else
    raise "Socket already closed when reading."
  end
end

seems to work for me, and vastly improves the speed of the body
processing (quick tests reveal that using IO#read takes about 1 min 40
secs. and using Socket#recv takes about 9 secs on an 8.5 mb file). I
have been having trouble discovering the difference between read &
recv (I am not a socket developer by any means). Can anybody tell me
what sort of safety one loses by doing this with recv instead of read?
Thanks.

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

From ridoutspam at gmail.com  Tue Feb  6 00:22:04 2007
From: ridoutspam at gmail.com (Guy Ridout)
Date: Tue, 6 Feb 2007 00:22:04 -0500
Subject: [Mongrel] Mongrel service will not start on win32 w/ --prefix option
Message-ID: <eb888f5b0702052122r18b8db56taa5c947d4eae23f6@mail.gmail.com>

All, I am in need of some help. I've run into a problem that I am not able
to fix or even troubleshoot.  I am trying to run Mongrel as a service on
Win32.

Basically, my problem is that running Mongrel as a service works fine. Fine
until I change the configuration (using service::remove and
service::install) to use --prefix. I must have this as I am running multiple
webapps and app servers all behind apache.


So, here is the config that works. It does not use the --prefix option:
#1 (works)
  mongrel_rails service::install -N mongrel_app_service -c
c:\projects\rails-prod\myapp -p 4001 -e production

  (The service "path to executable" displayed under properties:)
  "c:/ruby/bin/mongrel_service.exe" single -e production -p 4001 -a
0.0.0.0-l "log/mongrel.log" -P "log/mongrel.pid" -c
"c:/projects/rails-prod/myapp"
-t 0 -r "public" -n 1024



Here is the config that is not working It *does* use the --prefix option.
That is the only difference:
#2 (does not work)
  mongrel_rails service::install -N mongrel_app_service -c
c:\projects\rails-prod\myapp -p 4001 -e production --prefix /myapproot

  (The service "path to executable" displayed under properties:)
  "c:/ruby/bin/mongrel_service.exe" single -e production -p 4001 -a
0.0.0.0-l "log/mongrel.log" -P "log/mongrel .pid" -c
"c:/projects/rails-prod/myapp"
-t 0 -r "public" -n 1024 --prefix "/myapproot"



The working version (#1) starts normally and serves requests as expected.
When I start the --prefix version of the service (#2), Windows displays a
dialog with the following:

  "The mongrel_app_service service on Local Computer started and then
stopped. Some services stop automatically if they have no work to do, for
example, the Performance Logs and Alerts service."

I have researched this error and found vague references (
http://rubyforge.org/pipermail/mongrel-users/2006-December/002513.html) that
running the service as another user, or clearing the "app logs" may resolve
this. I have not had any luck. I tried creating a dedicated user account,
but I get the same error. I am not sure what logs I would clear, but I tried
my rails/mongrel logs with no luck.

My biggest lead is the mongrel_service.log file which I think hints at the
root issue. I have captured the logging from a start of both the working
service config (#1) and the non-working config (#2). They are listed below
intact (all of #1, then all of #2), and then interleaved for easier
comparison (up until they diverge):


*** Good start (no prefix) ***native/mongrel_service.bas:120,
mongrel_service.single_onstop:
(#1)  # Logfile created on 05/02/2007 23:37:42
(#1)  native/mongrel_service.bas:148, mongrel_service.application:
(#1)    ServiceHost RunAsService
(#1)  native/mongrel_service.bas:54, mongrel_service.single_oninit:
(#1)    single_onInit()
(#1)  native/mongrel_service.bas:71, mongrel_service.single_oninit:
(#1)    starting child process with cmdline:
ruby.exec:\ruby\bin\mongrel_rails start -e production -p 4001 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c
c:/projects/rails-prod/wingate -t 0 -r public -n 1024
(#1)  # Logfile created on 05/02/2007 23:37:42
(#1)  native/process.bas:44, fb.process.spawn:
(#1)  Spawn() init
(#1)  native/process.bas:52, fb.process.spawn:
(#1)  AllocConsole failed, maybe already allocated, safely to discart.
(#1)  native/process.bas:105, fb.process.spawn:
(#1)  Creating child process with cmdline:
ruby.exec:\ruby\bin\mongrel_rails start -e production -p 4001 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c
c:/projects/rails-prod/wingate -t 0 -r public -n 1024
(#1)  native/process.bas:121, fb.process.spawn:
(#1)  Closing handles.
(#1)  native/process.bas:136, fb.process.spawn:
(#1)  wait_code: 258
(#1)  native/process.bas:141, fb.process.spawn:
(#1)  New children PID: 3984
(#1)  native/process.bas:156, fb.process.spawn:
(#1)  Spawn() done
(#1)  native/mongrel_service.bas:79, mongrel_service.single_oninit:
(#1)  child process pid: 3984
(#1)  native/mongrel_service.bas:88, mongrel_service.single_oninit:
(#1)  single_onInit() done
(#1)  native/mongrel_service.bas:93, mongrel_service.single_onstart:
(#1)  single_onStart()

*** Ok, now a bad start (w/ prefix) ***
(#2)  # Logfile created on 05/02/2007 23:38:28
(#2)  native/mongrel_service.bas:148, mongrel_service.application:
(#2)  ServiceHost RunAsService

(#2)  native/mongrel_service.bas:54, mongrel_service.single_oninit:

(#2)  single_onInit()
(#2)  native/mongrel_service.bas:71, mongrel_service.single_oninit:
(#2)  starting child process with cmdline:
ruby.exec:\ruby\bin\mongrel_rails start -e production -p 4001 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c
c:/projects/rails-prod/wingate -t 0 -r public -n 1024 --prefix /wingate
(#2)  # Logfile created on 05/02/2007 23:38:28
(#2)  native/process.bas:44, fb.process.spawn:
(#2)  Spawn() init
(#2)  native/process.bas:52, fb.process.spawn:
(#2)  AllocConsole failed, maybe already allocated, safely to discart.
(#2)  native/process.bas:105, fb.process.spawn:
(#2)  Creating child process with cmdline:
ruby.exec:\ruby\bin\mongrel_rails start -e production -p 4001 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c
c:/projects/rails-prod/wingate -t 0 -r public -n 1024 --prefix /wingate
(#2)  native/process.bas:121, fb.process.spawn:
(#2)  Closing handles.
(#2)  native/process.bas:136, fb.process.spawn:
(#2)  wait_code: 0
(#2)  native/process.bas:147, fb.process.spawn:
(#2)  failed, the process terminate earlier.
(#2)  native/process.bas:156, fb.process.spawn:
(#2)  Spawn() done
(#2)  native/mongrel_service.bas:88, mongrel_service.single_oninit:
(#2)  single_onInit() done


*** Interleaved together ***
(#1)  # Logfile created on 05/02/2007 23:37:42
(#2)  # Logfile created on 05/02/2007 23:38:28
(#1)  native/mongrel_service.bas:148, mongrel_service.application:
(#2)  native/mongrel_service.bas:148, mongrel_service.application:
(#1)  ServiceHost RunAsService
(#2)  ServiceHost RunAsService

(#1)  native/mongrel_service.bas:54, mongrel_service.single_oninit:
(#2)  native/mongrel_service.bas:54, mongrel_service.single_oninit:

(#1)  single_onInit()
(#2)  single_onInit()

(#1)  native/mongrel_service.bas:71, mongrel_service.single_oninit:
(#2)  native/mongrel_service.bas:71, mongrel_service.single_oninit:
(#1)  starting child process with cmdline:
ruby.exec:\ruby\bin\mongrel_rails start -e production -p 4001 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c
c:/projects/rails-prod/wingate -t 0 -r public -n 1024
(#2)  starting child process with cmdline:
ruby.exec:\ruby\bin\mongrel_rails start -e production -p 4001 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c
c:/projects/rails-prod/wingate -t 0 -r public -n 1024 --prefix /wingate
(#1)  # Logfile created on 05/02/2007 23:37:42
(#2)  # Logfile created on 05/02/2007 23:38:28
(#1)  native/process.bas:44, fb.process.spawn:
(#2)  native/process.bas:44, fb.process.spawn:
(#1)  Spawn() init
(#2)  Spawn() init
(#1)  native/process.bas:52, fb.process.spawn:
(#2)  native/process.bas:52, fb.process.spawn:
(#1)  AllocConsole failed, maybe already allocated, safely to discart.
(#2)  AllocConsole failed, maybe already allocated, safely to discart.
(#1)  native/process.bas:105, fb.process.spawn:
(#2)  native/process.bas:105, fb.process.spawn:
(#1)  Creating child process with cmdline:
ruby.exec:\ruby\bin\mongrel_rails start -e production -p 4001 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c
c:/projects/rails-prod/wingate -t 0 -r public -n 1024
(#2)  Creating child process with cmdline:
ruby.exec:\ruby\bin\mongrel_rails start -e production -p 4001 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c
c:/projects/rails-prod/wingate -t 0 -r public -n 1024 --prefix /wingate
(#1)  native/process.bas:121, fb.process.spawn:
(#2)  native/process.bas:121, fb.process.spawn:
(#1)  Closing handles.
(#2)  Closing handles.
(#1)  native/process.bas:136, fb.process.spawn:
(#2)  native/process.bas:136, fb.process.spawn:


## This is where they start to diverge!
(#1)  wait_code: 258
(#2)  wait_code: 0
(#2)  native/process.bas:147, fb.process.spawn:
(#2)  failed, the process terminate earlier.
(#2)  native/process.bas:156, fb.process.spawn:
(#2)  Spawn() done
(#2)  native/mongrel_service.bas:88, mongrel_service.single_oninit:
(#2)  single_onInit() done

(#1)  native/process.bas:141, fb.process.spawn:
(#1)  New children PID: 3984
(#1)  native/process.bas:156, fb.process.spawn:
(#1)  Spawn() done
(#1)  native/mongrel_service.bas:79, mongrel_service.single_oninit:
(#1)  child process pid: 3984
(#1)  native/mongrel_service.bas:88, mongrel_service.single_oninit:
(#1)  single_onInit() done
(#1)  native/mongrel_service.bas:93, mongrel_service.single_onstart:
(#1)  single_onStart()

Can anyone shed any light on the wait_code bit? Is it not waiting long
enough or is that jsut a return code? I've re-booted, cleared my logs,
created user accounts, treid passing --prefix as a start parm in the
properties view of the service. Nothing seems to work. I would really
appreciate some advice.

Thank you!
-Bridout
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070206/6e91f26e/attachment-0001.html 

From luislavena at gmail.com  Tue Feb  6 01:26:21 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 6 Feb 2007 03:26:21 -0300
Subject: [Mongrel] Mongrel service will not start on win32 w/ --prefix
	option
In-Reply-To: <eb888f5b0702052122r18b8db56taa5c947d4eae23f6@mail.gmail.com>
References: <eb888f5b0702052122r18b8db56taa5c947d4eae23f6@mail.gmail.com>
Message-ID: <71166b3b0702052226m1b1840eeg52958b3776924a34@mail.gmail.com>

Hello Guy,

I'll try to answer your questions:

On 2/6/07, Guy Ridout <ridoutspam at gmail.com> wrote:
> All, I am in need of some help. I've run into a problem that I am not able
> to fix or even troubleshoot.  I am trying to run Mongrel as a service on
> Win32.
>
> Basically, my problem is that running Mongrel as a service works fine. Fine
> until I change the configuration (using service::remove and
> service::install) to use --prefix. I must have this as I am running multiple
> webapps and app servers all behind apache.
>

I see that you're using latest mongrel_service, that's good. I'll snip
the content now, but so far, this is the best report of a problem
someone made under Win32! Congrats!

>
> So, here is the config that works. It does not use the --prefix option:
> #1 (works)
>   mongrel_rails service::install -N mongrel_app_service -c
> c:\projects\rails-prod\myapp -p 4001 -e production
>
>   (The service "path to executable" displayed under properties:)
>   "c:/ruby/bin/mongrel_service.exe" single -e production -p
> 4001 -a 0.0.0.0 -l "log/mongrel.log" -P "log/mongrel.pid" -c
> "c:/projects/rails-prod/myapp" -t 0 -r "public" -n 1024
>
>
>
> Here is the config that is not working It *does* use the --prefix option.
> That is the only difference:
> #2 (does not work)
>   mongrel_rails service::install -N mongrel_app_service -c
> c:\projects\rails-prod\myapp -p 4001 -e production --prefix /myapproot
>
>   (The service "path to executable" displayed under properties:)
>   "c:/ruby/bin/mongrel_service.exe" single -e production -p
> 4001 -a 0.0.0.0 -l "log/mongrel.log" -P "log/mongrel .pid" -c
> "c:/projects/rails-prod/myapp" -t 0 -r "public" -n 1024 --prefix
> "/myapproot"
>
>

As you can see, the only params that fails (based on
mongrel_service.log) is --prefix.

> ## This is where they start to diverge!
> (#1)  wait_code: 258
> (#2)  wait_code: 0
> (#2)  native/process.bas:147, fb.process.spawn:
> (#2)  failed, the process terminate earlier.
> (#2)  native/process.bas:156, fb.process.spawn:
> (#2)  Spawn() done
> (#2)  native/mongrel_service.bas:88, mongrel_service.single_oninit:
> (#2)  single_onInit() done
>
> Can anyone shed any light on the wait_code bit? Is it not waiting long
> enough or is that jsut a return code? I've re-booted, cleared my logs,
> created user accounts, treid passing --prefix as a start parm in the
> properties view of the service. Nothing seems to work. I would really
> appreciate some advice.
>

The wait code indicates that process is starting, and wait_code = 0
means something is wrong during process spawning.


My advice will be try running plain mongrel command and see what ruby
process dump to the screen, so the command you can run in a command
prompt window (cmd) will be:

ruby.exe c:\ruby\bin\mongrel_rails start -e production -p 4001 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c
c:/projects/rails-prod/wingate -t 0 -r public -n 1024 --prefix
/wingate

The bad thing is in the current implementation, mongrel_service isn't
logging the console output of the child process, so this is the only
way to pin-point the problem.

Please copy the output you get from this in your next reply. So far,
mongrel process is failing to start, guess is directly related to
prefix option, and if thats the case, a prefix test under win32 should
be added.

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 ufuk at pilli.com  Tue Feb  6 06:18:22 2007
From: ufuk at pilli.com (ufuk kocolu)
Date: Tue, 06 Feb 2007 13:18:22 +0200
Subject: [Mongrel] setting enviroment variable
Message-ID: <45C863FE.8030004@pilli.com>


I have a ror project which has been productized. There are several web 
sites in one ror project

I need to set an "enviroment variable" to run different sites, can I do 
that using mongrel? I tried to use mongrel's -S option and set the 
enviroment variable in that file but it seems mongrel runs that file
after it calls enviroment.rb

I also used apache's mod_proxy+mod_header to set requestheader but it 
didn't work either.

Is there a way to set an enviroment variable before mongrel initializes?

Thanks

Ufuk.



From luislavena at gmail.com  Tue Feb  6 06:54:13 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 6 Feb 2007 08:54:13 -0300
Subject: [Mongrel] setting enviroment variable
In-Reply-To: <45C863FE.8030004@pilli.com>
References: <45C863FE.8030004@pilli.com>
Message-ID: <71166b3b0702060354g77d65434pfe51b08583227d37@mail.gmail.com>

On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
>
> I have a ror project which has been productized. There are several web
> sites in one ror project
>

Question:

A) You are serving multiple sites from one rails application?

or

B) You have multiple instances of your rails application, each one
serving a specific web site.

> I need to set an "enviroment variable" to run different sites, can I do
> that using mongrel? I tried to use mongrel's -S option and set the
> enviroment variable in that file but it seems mongrel runs that file
> after it calls enviroment.rb

The answers will be:

A) Use something like subdomain accounts:
  http://wiki.rubyonrails.org/rails/pages/HowToUseSubdomainsAsAccountKeys
  http://www.bigbold.com/snippets/posts/show/1322


B) process your ENV information inside environment, and set your
environment variable prior calling mongrel_rails:

  $ MY_SITE=site1 mongrel_rails start ...

  or

  $ export MY_SITE=site1
  $ mongrel_rails start ...


-- 
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 inanc.gumus at networkistanbul.com  Tue Feb  6 07:18:52 2007
From: inanc.gumus at networkistanbul.com (=?UTF-8?Q?=C4=B0nan=C3=A7_G=C3=9CM=C3=9C=C5=9E?=)
Date: Tue, 6 Feb 2007 14:18:52 +0200
Subject: [Mongrel] setting enviroment variable
In-Reply-To: <45C863FE.8030004@pilli.com>
References: <45C863FE.8030004@pilli.com>
Message-ID: <dffdf4710702060418o5c9d8d4dnf57b1cd32baf12b6@mail.gmail.com>

What do you exactly mean by "setting environment variables" ? Are your sites
running according to them ?

On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
>
>
> I have a ror project which has been productized. There are several web
> sites in one ror project
>
> I need to set an "enviroment variable" to run different sites, can I do
> that using mongrel? I tried to use mongrel's -S option and set the
> enviroment variable in that file but it seems mongrel runs that file
> after it calls enviroment.rb
>
> I also used apache's mod_proxy+mod_header to set requestheader but it
> didn't work either.
>
> Is there a way to set an enviroment variable before mongrel initializes?
>
> Thanks
>
> Ufuk.
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 

?nan? G?m??
Yaz?l?m Dan??man? / Software Consultant
+90555 701 74 27

-- 
---
hidden job market lurking everywhere
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070206/f5a1722c/attachment.html 

From inanc.gumus at networkistanbul.com  Tue Feb  6 07:20:35 2007
From: inanc.gumus at networkistanbul.com (=?UTF-8?Q?=C4=B0nan=C3=A7_G=C3=9CM=C3=9C=C5=9E?=)
Date: Tue, 6 Feb 2007 14:20:35 +0200
Subject: [Mongrel] setting enviroment variable
In-Reply-To: <71166b3b0702060354g77d65434pfe51b08583227d37@mail.gmail.com>
References: <45C863FE.8030004@pilli.com>
	<71166b3b0702060354g77d65434pfe51b08583227d37@mail.gmail.com>
Message-ID: <dffdf4710702060420y4c1abfb8gc899d762afbc30ec@mail.gmail.com>

If it's "B", you may use a bash script to do them all at once in there.

On 2/6/07, Luis Lavena <luislavena at gmail.com> wrote:
>
> On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
> >
> > I have a ror project which has been productized. There are several web
> > sites in one ror project
> >
>
> Question:
>
> A) You are serving multiple sites from one rails application?
>
> or
>
> B) You have multiple instances of your rails application, each one
> serving a specific web site.
>
> > I need to set an "enviroment variable" to run different sites, can I do
> > that using mongrel? I tried to use mongrel's -S option and set the
> > enviroment variable in that file but it seems mongrel runs that file
> > after it calls enviroment.rb
>
> The answers will be:
>
> A) Use something like subdomain accounts:
>   http://wiki.rubyonrails.org/rails/pages/HowToUseSubdomainsAsAccountKeys
>   http://www.bigbold.com/snippets/posts/show/1322
>
>
> B) process your ENV information inside environment, and set your
> environment variable prior calling mongrel_rails:
>
>   $ MY_SITE=site1 mongrel_rails start ...
>
>   or
>
>   $ export MY_SITE=site1
>   $ mongrel_rails start ...
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070206/7e5ca282/attachment.html 

From ufuk at pilli.com  Tue Feb  6 07:41:22 2007
From: ufuk at pilli.com (ufuk kocolu)
Date: Tue, 06 Feb 2007 14:41:22 +0200
Subject: [Mongrel] setting enviroment variable
In-Reply-To: <71166b3b0702060354g77d65434pfe51b08583227d37@mail.gmail.com>
References: <45C863FE.8030004@pilli.com>
	<71166b3b0702060354g77d65434pfe51b08583227d37@mail.gmail.com>
Message-ID: <45C87772.1030409@pilli.com>

Luis Lavena wrote:
> On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
>   
>> I have a ror project which has been productized. There are several web
>> sites in one ror project
>>
>>     
>
> Question:
>
> A) You are serving multiple sites from one rails application?
>
> or
>
> B) You have multiple instances of your rails application, each one
> serving a specific web site.
>
>   
>> I need to set an "enviroment variable" to run different sites, can I do
>> that using mongrel? I tried to use mongrel's -S option and set the
>> enviroment variable in that file but it seems mongrel runs that file
>> after it calls enviroment.rb
>>     
>
> The answers will be:
>
> A) Use something like subdomain accounts:
>   http://wiki.rubyonrails.org/rails/pages/HowToUseSubdomainsAsAccountKeys
>   http://www.bigbold.com/snippets/posts/show/1322
>
>
> B) process your ENV information inside environment, and set your
> environment variable prior calling mongrel_rails:
>
>   $ MY_SITE=site1 mongrel_rails start ...
>
>   or
>
>   $ export MY_SITE=site1
>   $ mongrel_rails start ...
>
>
>   

I have one rails application which runs severals sites according to that 
enviroment variable.

http://article.gmane.org/gmane.comp.lang.ruby.rails/14513

The problem is, I can do what you suggest but I want to use mongrel as 
an NT service  (I can create multiple NT services for multiple sites) 
for that, I have to set this enviroment variable elsewhere.

If there is an option to run system commands before mongrel service 
initializes, that would work for me.

Thanks

Ufuk












From luislavena at gmail.com  Tue Feb  6 08:19:37 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 6 Feb 2007 10:19:37 -0300
Subject: [Mongrel] setting enviroment variable
In-Reply-To: <45C87772.1030409@pilli.com>
References: <45C863FE.8030004@pilli.com>
	<71166b3b0702060354g77d65434pfe51b08583227d37@mail.gmail.com>
	<45C87772.1030409@pilli.com>
Message-ID: <71166b3b0702060519g5fd3a03fqc6b702d04e6534ba@mail.gmail.com>

On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
<snip>
> I have one rails application which runs severals sites according to that
> enviroment variable.
>
> http://article.gmane.org/gmane.comp.lang.ruby.rails/14513
>
> The problem is, I can do what you suggest but I want to use mongrel as
> an NT service  (I can create multiple NT services for multiple sites)
> for that, I have to set this enviroment variable elsewhere.
>

OK, you forgot to include in your post THAT IMPORTANT part.

NT services cannot set environment variables *per-service*, unless you
ran your application for every instance in one specific user account

(ex. site1 using user1, site2 => user2, etc).

That will require set environment for each user account, also making
your application code vulnerable to _all_ these accounts (NT security
and permissions).

> If there is an option to run system commands before mongrel service
> initializes, that would work for me.
>

There isn't. Mongrel execute the config script after loading rails environment.

Could I question your decision base your application/system design in
a mail that dates 1 year, 29 weeks, 5 days, 12 hours and 26 minutes
old?

I got better functionality and less code duplication implementing
"instances" versions of my application:

All your instances share the same codebase of your application, which
is bundled inside a gem.

Each instance could be run like a normal rails application, having its
own database.yml, but without duplicated models and controllers
between instances.

That is Fossilize, the base on what Radiant based their gemification
distribution.

Maybe that approach will suite better your needs.

-- 
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 ridoutspam at gmail.com  Tue Feb  6 08:40:06 2007
From: ridoutspam at gmail.com (Guy Ridout)
Date: Tue, 6 Feb 2007 08:40:06 -0500
Subject: [Mongrel] Mongrel service will not start on win32 w/ --prefix option
Message-ID: <eb888f5b0702060540m5cd8f7eejbd08c68332be1395@mail.gmail.com>

Luis, I truly appreciate the quick reply and your eagerness to help. It's
refreshing to have software w/ service! Thank you.

I tried running the command you suggest:

C:\projects\rails-prod\wingate>ruby.exe c:\ruby\bin\mongrel_rails start -e
production -p 4001 -a 0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c c
:/projects/rails-prod/wingate -t 0 -r public -n 1024 --prefix /wingate
INVALID COMMAND: invalid option: --prefix

It fails saying there is no --prefix option. Thinking maybe I don't have the
latest version, I did the following:

C:\projects\rails-prod\wingate>gem update mongrel_service
Updating installed gems...
Need to update 23 gems from http://gems.rubyforge.org
.......................
complete
Attempting remote update of mongrel_service
Select which gem to install for your platform (i386-mswin32)
 1. mongrel_service 0.3.1 (mswin32)
 2. mongrel_service 0.1 (ruby)
 3. Cancel installation
> 1
Successfully installed mongrel_service-0.3.1-mswin32
Installing ri documentation for mongrel_service-0.3.1-mswin32...
Installing RDoc documentation for mongrel_service-0.3.1-mswin32...
Gems: [mongrel_service] updated

Following this update, the command fails with the same message. Any ideas?

Btw, I apologize if this post breaks the original thread. I'm a mailing list
newbie, and I didn't have my email settings correct, so there is nothing I
can reply to (assuming that is what I'm supposed to do!).

-BR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070206/5ae55ee1/attachment-0001.html 

From ufuk at pilli.com  Tue Feb  6 08:57:51 2007
From: ufuk at pilli.com (ufuk kocolu)
Date: Tue, 06 Feb 2007 15:57:51 +0200
Subject: [Mongrel] setting enviroment variable
In-Reply-To: <71166b3b0702060519g5fd3a03fqc6b702d04e6534ba@mail.gmail.com>
References: <45C863FE.8030004@pilli.com>	<71166b3b0702060354g77d65434pfe51b08583227d37@mail.gmail.com>	<45C87772.1030409@pilli.com>
	<71166b3b0702060519g5fd3a03fqc6b702d04e6534ba@mail.gmail.com>
Message-ID: <45C8895F.1090303@pilli.com>

Luis Lavena wrote:
> On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
> <snip>
>   
>> I have one rails application which runs severals sites according to that
>> enviroment variable.
>>
>> http://article.gmane.org/gmane.comp.lang.ruby.rails/14513
>>
>> The problem is, I can do what you suggest but I want to use mongrel as
>> an NT service  (I can create multiple NT services for multiple sites)
>> for that, I have to set this enviroment variable elsewhere.
>>
>>     
>
> OK, you forgot to include in your post THAT IMPORTANT part.
>
> NT services cannot set environment variables *per-service*, unless you
> ran your application for every instance in one specific user account
>
> (ex. site1 using user1, site2 => user2, etc).
>
> That will require set environment for each user account, also making
> your application code vulnerable to _all_ these accounts (NT security
> and permissions).
>
>   
>> If there is an option to run system commands before mongrel service
>> initializes, that would work for me.
>>
>>     
>
> There isn't. Mongrel execute the config script after loading rails environment.
>
> Could I question your decision base your application/system design in
> a mail that dates 1 year, 29 weeks, 5 days, 12 hours and 26 minutes
> old?
>
> I got better functionality and less code duplication implementing
> "instances" versions of my application:
>
> All your instances share the same codebase of your application, which
> is bundled inside a gem.
>
> Each instance could be run like a normal rails application, having its
> own database.yml, but without duplicated models and controllers
> between instances.
>
> That is Fossilize, the base on what Radiant based their gemification
> distribution.
>
> Maybe that approach will suite better your needs.
>
>   

Thank you for your answer. The fact is, my application is  a year old. 
So that solution was appropriatte back then. I'll check your suggestion 
but I won't be able to change a whole application to that method.

Then, I'm stuck here.  I doubt i will find a way out of this.

Thanks again.

Ufuk.








From luislavena at gmail.com  Tue Feb  6 09:46:40 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 6 Feb 2007 11:46:40 -0300
Subject: [Mongrel] setting enviroment variable
In-Reply-To: <45C8895F.1090303@pilli.com>
References: <45C863FE.8030004@pilli.com>
	<71166b3b0702060354g77d65434pfe51b08583227d37@mail.gmail.com>
	<45C87772.1030409@pilli.com>
	<71166b3b0702060519g5fd3a03fqc6b702d04e6534ba@mail.gmail.com>
	<45C8895F.1090303@pilli.com>
Message-ID: <71166b3b0702060646p1e1b70ebwb1983b06efff4d03@mail.gmail.com>

On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
> Luis Lavena wrote:
> > On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
> > <snip>
> >
> >> I have one rails application which runs severals sites according to that
> >> enviroment variable.
> >>
> >> http://article.gmane.org/gmane.comp.lang.ruby.rails/14513
> >>
> >> The problem is, I can do what you suggest but I want to use mongrel as
> >> an NT service  (I can create multiple NT services for multiple sites)
> >> for that, I have to set this enviroment variable elsewhere.
> >>
> >>
> >
> > OK, you forgot to include in your post THAT IMPORTANT part.
> >
> > NT services cannot set environment variables *per-service*, unless you
> > ran your application for every instance in one specific user account
> >
> > (ex. site1 using user1, site2 => user2, etc).
> >
> > That will require set environment for each user account, also making
> > your application code vulnerable to _all_ these accounts (NT security
> > and permissions).
> >
> >
> >> If there is an option to run system commands before mongrel service
> >> initializes, that would work for me.
> >>
> >>
> >
> > There isn't. Mongrel execute the config script after loading rails environment.
> >
> > Could I question your decision base your application/system design in
> > a mail that dates 1 year, 29 weeks, 5 days, 12 hours and 26 minutes
> > old?
> >
> > I got better functionality and less code duplication implementing
> > "instances" versions of my application:
> >
> > All your instances share the same codebase of your application, which
> > is bundled inside a gem.
> >
> > Each instance could be run like a normal rails application, having its
> > own database.yml, but without duplicated models and controllers
> > between instances.
> >
> > That is Fossilize, the base on what Radiant based their gemification
> > distribution.
> >
> > Maybe that approach will suite better your needs.
> >
> >
>
> Thank you for your answer. The fact is, my application is  a year old.
> So that solution was appropriatte back then. I'll check your suggestion
> but I won't be able to change a whole application to that method.
>

Fossilize is 1 year old ;-)

Original article in spanish:

http://rubyargentina.soveran.com/gemrailsapp

And the ANN in ruby-forum:

http://www.ruby-forum.com/topic/67435#84031


> Then, I'm stuck here.  I doubt i will find a way out of this.
>

The only workaround I see for you is hack in the top of your
environment file something that based on the port set to start the
application, set the constant SITE (used in erb inside database.yml).

Since you cannot start 2 instances in the same port, I guess this could work.

(You will require look into ARGV and get -p or --port option from it.)

The other, easier and less safer way will be use the multiple user
accounts option.

-- 
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  Tue Feb  6 09:57:12 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 6 Feb 2007 11:57:12 -0300
Subject: [Mongrel] Mongrel service will not start on win32 w/ --prefix
	option
In-Reply-To: <eb888f5b0702060540m5cd8f7eejbd08c68332be1395@mail.gmail.com>
References: <eb888f5b0702060540m5cd8f7eejbd08c68332be1395@mail.gmail.com>
Message-ID: <71166b3b0702060657w599e9f0q99d976b606a094db@mail.gmail.com>

On 2/6/07, Guy Ridout <ridoutspam at gmail.com> wrote:
> Luis, I truly appreciate the quick reply and your eagerness to help. It's
> refreshing to have software w/ service! Thank you.
>
> I tried running the command you suggest:
>
> C:\projects\rails-prod\wingate>ruby.exe c:\ruby\bin\mongrel_rails start -e
> production -p 4001 -a 0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c c
>  :/projects/rails-prod/wingate -t 0 -r public -n 1024 --prefix /wingate
>  INVALID COMMAND: invalid option: --prefix
>
> It fails saying there is no --prefix option. Thinking maybe I don't have the
> latest version, I did the following:
>
> C:\projects\rails-prod\wingate>gem update mongrel_service
> Updating installed gems...
> Need to update 23 gems from http://gems.rubyforge.org
> .......................
> complete
> Attempting remote update of mongrel_service
> Select which gem to install for your platform (i386-mswin32)
>  1. mongrel_service 0.3.1 (mswin32)
>  2. mongrel_service 0.1 (ruby)
>  3. Cancel installation
> > 1
> Successfully installed mongrel_service-0.3.1-mswin32
> Installing ri documentation for mongrel_service-0.3.1-mswin32.. .
> Installing RDoc documentation for mongrel_service-0.3.1-mswin32...
> Gems: [mongrel_service] updated
>
> Following this update, the command fails with the same message. Any ideas?
>

Mmm, did you update mongrel gem too?

$ gem install mongrel --include-dependencies

Mongrel version should be 1.0.1

You should notice the "Mounting Rails at ..." line in the output:

>mongrel_rails start --prefix /test
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
** Mounting Rails at /test...
D:0:Warning: require_gem is obsolete.  Use gem instead.
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  INT => stop (no restart).
** Mongrel available at 0.0.0.0:3000
** Use CTRL-C to stop.


I tried the same here and it worked, maybe you have an older mongrel version.

> Btw, I apologize if this post breaks the original thread. I'm a mailing list
> newbie, and I didn't have my email settings correct, so there is nothing I
> can reply to (assuming that is what I'm supposed to do!).
>

Its good that you bring this to mongrel list, we all started as newbies ;-)
try replying to the last mail you get in the same thread (ex, mine, no
mater it the Topic get modified with 're:' by your mail software).

-- 
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  Wed Feb  7 02:37:44 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 6 Feb 2007 23:37:44 -0800
Subject: [Mongrel] Mongrel woes fixed
In-Reply-To: <20061003211326.GB38257@apoc.jacobatzen.dk>
References: <20061001193811.GA5663@nezbo.dhcp.aub.dk>
	<20061001163907.56f82b90.zedshaw@zedshaw.com>
	<20061003211326.GB38257@apoc.jacobatzen.dk>
Message-ID: <20070206233744.a3aa9e2b.zedshaw@zedshaw.com>

Hey Jacob, did you get this resolved?  I flaked out on it so sorry it
was back in October. :-)

On Tue, 3 Oct 2006 23:13:26 +0200
Jacob Atzen <jacob at jacobatzen.dk> wrote:

> On Sun, Oct 01, 2006 at 04:39:07PM -0700, Zed A. Shaw wrote:
> > > The second problem stems from the fact that Mongrel uses the
> > > Thread#abort_on_exception. I'm not sure why this is even in there, as
> > > the documentation says:
> > > 
> > >         When set to true, causes all threads (including the main
> > >         program) to abort if an exception is raised in thr. The process
> > >         will effectively exit(0).
> > > 
> > > The patch simply removes the abort_on_exception from mongrel.rb. After
> > > applying this patch I have been unable to make Mongrel crash.
> > > 
> > 
> > The abort was put in there to catch exceptions that are "leaking"
> > through and not being caught.  I'm curious what exception was being
> > thrown that *none* of the damn begin/rescue blocks catches.  We
> > seriously need a begin/rescue-every-damn-thing-no-matter-what
> > construct that actually works.
> 
> Some further digging gives another pointer towards the problem. I am
> seeing some backtraces that look like this (beware, the line numbers
> might be a little off):
> 
> /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:646:in `run': Mongrel timed out this thread: max processors#<Thread:0x8f28d9c run> (Mongrel::TimeoutError)
>         from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:704:in `run'
>         from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:684:in `run'
>         from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:268:in `run'
>         from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/configurator.rb:266:in `run'
>         from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:127:in `run'
>         from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel/command.rb:211:in `run'
>         from /usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/bin/mongrel_rails:231
>         from /usr/local/bin/mongrel_rails:18
> 
> The mongrel.rb:646 is the w.raise() call and 704 is:
> 
>         thread = Thread.new(client) { |c|
> 
> What I make of this is that somehow the thread is put aside as soon as
> it's created, that is _before_ the process_client() call and when the
> thread is then killed off there's nothing to catch the exception.
> 
> Now I am seeing exceptions being cast at line 646 before this one, but
> they have different backtraces, typically involving sync.rb and seems to
> be handled more properly. As far as I can tell they are all handled by
> the "Error calling Dispatcher.dispatch" rescue block.
> 
> Another interesting note is that after an exception is cast at this
> exact point and with the above backtrace all processes go into the
> aborting state. And when they're all killed off Mongrel dies. It's
> actually quite clear as the following log exerpt will show:
> 
> 
> % grep -ni timeout log/mongrel.14.log
> 127011:Tue Oct 03 21:57:28 CEST 2006: Error calling Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed out this thread: max processors#<Thread:0x8fe760c run>> from #<Thread:0x8fe760c run>
> 203806:/usr/local/lib/ruby/gems/1.8/gems/mongrel-0.3.13.4/lib/mongrel.rb:646:in `run': Mongrel timed out this thread: max processors#<Thread:0x8f28d9c run> (Mongrel::TimeoutError)
> 
> % grep -n "aborting" log/mongrel.14.log | head -n 3
> 203815:[sync_synchronize] Unlocking #<Thread:0x8f3a72c aborting>
> 203816:[sync_unlock:1] Thread.critical = true #<Thread:0x8f3a72c aborting>
> 203817:[sync_unlock:4] Thread.critical = false #<Thread:0x8f3a72c aborting>
> 
> 
> I have tried adding a begin/rescue/end around the process_client() call
> like this:
> 
>     begin
>       process_client(thread_client);
>     rescue Object
>       STDERR.print "ERROR: RESCUING BEFORE CALL\n"
>     end
> 
> And it seems to be doing the job. At least I haven't been able to make
> Mongrel crash yet, with whatever little testing I've been doing. Yet I
> have seen the error message show up a couple of times.
> 
> What are your thoughts on this? Does it make sense?
> 
> > Now, I believe the problem you'll have is when this exception leaks
> > through that thread will become dead and eventually you'll fill up and
> > Mongrel will die anyway.  If you can, try to find out what exception
> > causes this so I can have the server kill off its threads properly by
> > handling this yet another annoying random exception.
> 
> Actually from what I've seen so far, the threads seems to be killed of
> properly, if somewhat slow. I'm printing the process list in every run
> of the sleeper thread, and from what I can see Mongrel will clean out
> the threads even when the exception leaks through. From my understanding
> when an exception gets to the top level of the thread, the thread is
> simply killed off. Feel free to correct me if I'm wrong.
> 
> It does seem that some threads keep lingering in Mongrel even after all
> requests have died. But this seems to be the case whether the abort flag
> is set or not. It looks as if some enter an eternal sleeping state. I
> don't think it's much of a problem stability wise though, as they'll
> just get killed of whenever the reaper gets to work.
> 
> > This might not be needed as the ruby-core guys finally started taking
> > a serious look at how array works and we can probably switch back to
> > Mutex in the near future.
> 
> I have no idea how Mutex handles locking, but sync seems to be doing a
> whole lot of work over and over again. It seems to me it's really meant
> for smaller locking queues.
> 
> > Thanks again Jacob, if you can answer the questions I had so I can
> > work on a fix that doesn't involve updating ruby.  Also an explanation
> > as to why you were having these problems will help people decide if
> > they should apply the patches too.
> 
> I'm still not sure why I'm the only one seeing these problems. Maybe
> others are seing them too and just not being aware of them. Maybe they
> only show up when the Mongrels gets severely loaded. Maybe I'm simply
> the only one butchering poor Mongrels for fun in my spare-time? ;-)
> 
> In regards to the sync issues the jury is still out on that one. I will
> need to get a deeper understanding of how sync works to get to the
> bottom of it, but I'll continue poking around.
> 
> -- 
> Cheers,
> - Jacob Atzen
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


-- 
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.

From ridoutspam at gmail.com  Wed Feb  7 00:46:18 2007
From: ridoutspam at gmail.com (Guy Ridout)
Date: Wed, 7 Feb 2007 00:46:18 -0500
Subject: [Mongrel] Mongrel service will not start on win32 w/ --prefix
	option
In-Reply-To: <71166b3b0702060657w599e9f0q99d976b606a094db@mail.gmail.com>
References: <eb888f5b0702060540m5cd8f7eejbd08c68332be1395@mail.gmail.com>
	<71166b3b0702060657w599e9f0q99d976b606a094db@mail.gmail.com>
Message-ID: <eb888f5b0702062146s4845c695lf6320ff86cb8827d@mail.gmail.com>

Updating the mongrel gem ($ gem update mongrel --include-dependencies) did
the trick. Thanks again for your help. I definitely owe you a drink!

-BR :)

On 2/6/07, Luis Lavena <luislavena at gmail.com> wrote:
>
> On 2/6/07, Guy Ridout <ridoutspam at gmail.com> wrote:
> > Luis, I truly appreciate the quick reply and your eagerness to help.
> It's
> > refreshing to have software w/ service! Thank you.
> >
> > I tried running the command you suggest:
> >
> > C:\projects\rails-prod\wingate>ruby.exe c:\ruby\bin\mongrel_rails start
> -e
> > production -p 4001 -a 0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c c
> >  :/projects/rails-prod/wingate -t 0 -r public -n 1024 --prefix /wingate
> >  INVALID COMMAND: invalid option: --prefix
> >
> > It fails saying there is no --prefix option. Thinking maybe I don't have
> the
> > latest version, I did the following:
> >
> > C:\projects\rails-prod\wingate>gem update mongrel_service
> > Updating installed gems...
> > Need to update 23 gems from http://gems.rubyforge.org
> > .......................
> > complete
> > Attempting remote update of mongrel_service
> > Select which gem to install for your platform (i386-mswin32)
> >  1. mongrel_service 0.3.1 (mswin32)
> >  2. mongrel_service 0.1 (ruby)
> >  3. Cancel installation
> > > 1
> > Successfully installed mongrel_service-0.3.1-mswin32
> > Installing ri documentation for mongrel_service-0.3.1-mswin32.. .
> > Installing RDoc documentation for mongrel_service-0.3.1-mswin32...
> > Gems: [mongrel_service] updated
> >
> > Following this update, the command fails with the same message. Any
> ideas?
> >
>
> Mmm, did you update mongrel gem too?
>
> $ gem install mongrel --include-dependencies
>
> Mongrel version should be 1.0.1
>
> You should notice the "Mounting Rails at ..." line in the output:
>
> >mongrel_rails start --prefix /test
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Starting Rails with development environment...
> ** Mounting Rails at /test...
> D:0:Warning: require_gem is obsolete.  Use gem instead.
> ** Rails loaded.
> ** Loading any Rails specific GemPlugins
> ** Signals ready.  INT => stop (no restart).
> ** Mongrel available at 0.0.0.0:3000
> ** Use CTRL-C to stop.
>
>
> I tried the same here and it worked, maybe you have an older mongrel
> version.
>
> > Btw, I apologize if this post breaks the original thread. I'm a mailing
> list
> > newbie, and I didn't have my email settings correct, so there is nothing
> I
> > can reply to (assuming that is what I'm supposed to do!).
> >
>
> Its good that you bring this to mongrel list, we all started as newbies
> ;-)
> try replying to the last mail you get in the same thread (ex, mine, no
> mater it the Topic get modified with 're:' by your mail software).
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070207/b8f482a5/attachment-0001.html 

From thewoolleyman at gmail.com  Wed Feb  7 02:00:29 2007
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 7 Feb 2007 00:00:29 -0700
Subject: [Mongrel] Auto-installing Gems via boot.rb causes errors under
	Mongrel
Message-ID: <e3af97510702062300v4c7b8a63v268cc1d4700ae936@mail.gmail.com>

Hi,

I'm trying to make my Rails app auto-install my required gems, by
invoking the gem installation in boot.rb.  I'll use the ActionMailer
gem as an example:

...
system "sudo gem install actionmailer --version=1.2.5 -y"
...

Problem is that this fails on the first invocation of Mongrel - it
can't find the gem.  However, if I kill and restart mongrel (with the
gem now installed), it works fine.

This problem does NOT occur with webrick, but webrick appears to parse
boot.rb twice when it is started.

Also, if I invoke the rubygems API programatically, not via system,
this problem doesn't occur - but I can't use sudo with this approach.

Any ideas why this happens, or how to work around it?

Below is the output of what happens, from mongrel and webrick.

Thanks,
Chad

------------

$ sudo gem uninstall actionmailer -i
Successfully uninstalled actionmailer version 1.2.5

$ mongrel_rails start
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
Successfully installed actionmailer-1.2.5
Installing ri documentation for actionmailer-1.2.5...
Installing RDoc documentation for actionmailer-1.2.5...
/usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:251:in
`report_activate_error': Could not find RubyGem actionmailer (= 1.2.5)
(Gem::LoadError)
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:188:in `activate'
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:214:in `activate'
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:213:in `each'
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:213:in `activate'
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:66:in
`active_gem_with_options'
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:59:in `require_gem'
        from /Users/woolley/workspace/geminstaller/spec/sample_rails_app/config/boot.rb:39
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require'
         ... 13 levels...
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in
`run'
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
        from /usr/local/bin/mongrel_rails:18:in `load'
        from /usr/local/bin/mongrel_rails:18

$ mongrel_rails start
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
Successfully installed actionmailer-1.2.5
Installing ri documentation for actionmailer-1.2.5...
Installing RDoc documentation for actionmailer-1.2.5...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It
might not work well.
** Mongrel available at 0.0.0.0:3000
** Use CTRL-C to stop.



$ sudo gem uninstall actionmailer -i
Successfully uninstalled actionmailer version 1.2.5

$ ruby script/server
Successfully installed actionmailer-1.2.5
Installing ri documentation for actionmailer-1.2.5...
Installing RDoc documentation for actionmailer-1.2.5...
=> Booting WEBrick...
Successfully installed actionmailer-1.2.5
Installing ri documentation for actionmailer-1.2.5...
Installing RDoc documentation for actionmailer-1.2.5...
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2007-02-06 23:53:27] INFO  WEBrick 1.3.1
[2007-02-06 23:53:27] INFO  ruby 1.8.5 (2006-08-25) [i686-darwin8.7.1]
[2007-02-06 23:53:27] INFO  WEBrick::HTTPServer#start: pid=1385 port=3000

From snacktime at gmail.com  Wed Feb  7 02:47:07 2007
From: snacktime at gmail.com (snacktime)
Date: Tue, 6 Feb 2007 23:47:07 -0800
Subject: [Mongrel] Mongrel and MemcacheSessionStore
In-Reply-To: <466af3440702041918p6137d3beu29b1938a0068b21f@mail.gmail.com>
References: <45C34E11.9060608@student.dei.uc.pt>
	<1f060c4c0702041724i7ca0fb1n81683bc4af0551ff@mail.gmail.com>
	<466af3440702041918p6137d3beu29b1938a0068b21f@mail.gmail.com>
Message-ID: <1f060c4c0702062347n44868889ra3d95f6e33ab606e@mail.gmail.com>

On 2/4/07, Joey Geiger <jgeiger at gmail.com> wrote:
> I like this idea, do you have an example or suggestions on how you
> could implement it easily?

I would use the active record store as a base and modify it.
active_record_store.rb has some sample code on how to do this.  Would
take a bit of time but doesn't look that difficult.

Chris

From ufuk at pilli.com  Wed Feb  7 04:44:23 2007
From: ufuk at pilli.com (ufuk kocolu)
Date: Wed, 07 Feb 2007 11:44:23 +0200
Subject: [Mongrel] setting enviroment variable
In-Reply-To: <71166b3b0702060646p1e1b70ebwb1983b06efff4d03@mail.gmail.com>
References: <45C863FE.8030004@pilli.com>	<71166b3b0702060354g77d65434pfe51b08583227d37@mail.gmail.com>	<45C87772.1030409@pilli.com>	<71166b3b0702060519g5fd3a03fqc6b702d04e6534ba@mail.gmail.com>	<45C8895F.1090303@pilli.com>
	<71166b3b0702060646p1e1b70ebwb1983b06efff4d03@mail.gmail.com>
Message-ID: <45C99F77.7070606@pilli.com>

Luis Lavena wrote:
> On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
>   
>> Luis Lavena wrote:
>>     
>>> On 2/6/07, ufuk kocolu <ufuk at pilli.com> wrote:
>>> <snip>
>>>
>>>       
>>>> I have one rails application which runs severals sites according to that
>>>> enviroment variable.
>>>>
>>>> http://article.gmane.org/gmane.comp.lang.ruby.rails/14513
>>>>
>>>> The problem is, I can do what you suggest but I want to use mongrel as
>>>> an NT service  (I can create multiple NT services for multiple sites)
>>>> for that, I have to set this enviroment variable elsewhere.
>>>>
>>>>
>>>>         
>>> OK, you forgot to include in your post THAT IMPORTANT part.
>>>
>>> NT services cannot set environment variables *per-service*, unless you
>>> ran your application for every instance in one specific user account
>>>
>>> (ex. site1 using user1, site2 => user2, etc).
>>>
>>> That will require set environment for each user account, also making
>>> your application code vulnerable to _all_ these accounts (NT security
>>> and permissions).
>>>
>>>
>>>       
>>>> If there is an option to run system commands before mongrel service
>>>> initializes, that would work for me.
>>>>
>>>>
>>>>         
>>> There isn't. Mongrel execute the config script after loading rails environment.
>>>
>>> Could I question your decision base your application/system design in
>>> a mail that dates 1 year, 29 weeks, 5 days, 12 hours and 26 minutes
>>> old?
>>>
>>> I got better functionality and less code duplication implementing
>>> "instances" versions of my application:
>>>
>>> All your instances share the same codebase of your application, which
>>> is bundled inside a gem.
>>>
>>> Each instance could be run like a normal rails application, having its
>>> own database.yml, but without duplicated models and controllers
>>> between instances.
>>>
>>> That is Fossilize, the base on what Radiant based their gemification
>>> distribution.
>>>
>>> Maybe that approach will suite better your needs.
>>>
>>>
>>>       
>> Thank you for your answer. The fact is, my application is  a year old.
>> So that solution was appropriatte back then. I'll check your suggestion
>> but I won't be able to change a whole application to that method.
>>
>>     
>
> Fossilize is 1 year old ;-)
>
> Original article in spanish:
>
> http://rubyargentina.soveran.com/gemrailsapp
>
> And the ANN in ruby-forum:
>
> http://www.ruby-forum.com/topic/67435#84031
>
>
>   
>> Then, I'm stuck here.  I doubt i will find a way out of this.
>>
>>     
>
> The only workaround I see for you is hack in the top of your
> environment file something that based on the port set to start the
> application, set the constant SITE (used in erb inside database.yml).
>
> Since you cannot start 2 instances in the same port, I guess this could work.
>
> (You will require look into ARGV and get -p or --port option from it.)
>
> The other, easier and less safer way will be use the multiple user
> accounts option.
>
>   
I can hack enviroment.rb but I don't think I can retrieve startup 
parameters using ARGV.

I checked and logged contents of ARGV and it's empty.

Can I retrieve it some other way (maybe using Rails::Configuration 
something like that) ?









From chris at oxdi.eu  Wed Feb  7 04:35:14 2007
From: chris at oxdi.eu (Chris Farmiloe)
Date: Wed, 7 Feb 2007 09:35:14 +0000
Subject: [Mongrel] mongrel_in_a_tunnel
Message-ID: <4596E0D4-888B-44D3-B721-EF10B555E01E@oxdi.eu>



Hi list:

I started to make a quick GemPlugin command [ssl::start] that sets up  
an stunnel before calling the normal [start] command.

so

$ mongrel_rails ssl:start

will do everything that start normally does and configure/setup an  
stunnel.


The question...

Obviously this plugin will require stunnel to be installed. What do  
you think is the best move:

1) nothing, just require that people install stunnel themselves.
2) make the gem attempt to compile stunnel for them.
3) lock myself in a box and make ruby-stunnel bindings/extension.




Thanks.


chrisfarms



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

From stan.baptista at gmail.com  Wed Feb  7 13:53:47 2007
From: stan.baptista at gmail.com (Stan Baptista)
Date: Wed, 7 Feb 2007 08:53:47 -1000
Subject: [Mongrel] Apache+Mongrel Redirection Problems
Message-ID: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>

Hi folks,

Newbie issues...I'm prototying an Apache/Mongrel configuration setup
as follows:

* Two Mongrel servers each serving a Rails application.
* Apache front-end.
* Linux system (CentOS)
* The plan is to create two virtual hosts.

/ETC/HOSTS LOOKS LIKE THIS:

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain   localhost       egovm04
10.4.1.84       rss
10.4.1.84       railstest

HTTPD.CONF LOOKS LIKE THIS:

[snip]

NameVirtualHost 10.4.1.84

<VirtualHost rss>
    ServerName rss
    ServerAlias rss

    RewriteEngine on
    RewriteRule ^/rss(.*) http://10.4.1.84:5432$1 <http://10.4.1.84:5432/>[P]

    ProxyPass / http://10.4.1.84:5432/
    ProxyPassReverse / http://10.4.1.84:5432/

</VirtualHost>

<VirtualHost railstest>

    ServerName railstest
    ServerAlias railstest

    RewriteEngine on
    RewriteRule ^/railstest(.*)
http://10.4.1.84:8021$1<http://10.4.1.84:8021/>[P]

    ProxyPass / http://10.4.1.84:8021/
    ProxyPassReverse / http://10.4.1.84:8021/

</VirtualHost>

ISSUES

1. App 1 (rss) URL rewrite problem.

Typing 'http://10.4.1.84/rss' <http://10.4.1.84/rss%27> in the browser
correctly accesses app #1
(rss), HOWEVER...

This: 'http://10.4.1.84/rss/about' <http://10.4.1.84/rss/about%27> finds the
right page, but the URL
is rewritten to this: 'http://10.4.1.84/about' <http://10.4.1.84/about%27>

2. App # 2 not found.

Typing this: 'http://10.4.1.84/railstest'
<http://10.4.1.84/railstest%27>yields this:

Routing Error
Recognition failed for "/railstest"

This is a Rails message reported by app # 1( rss). So the (Apache)
server is not redirecting to the second Virtual Host (railstest).

Sorry for the question, I'm quite sure this is a setup problem on my
part.

Thanks,
Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070207/ff145793/attachment-0001.html 

From michael.dauria at gmail.com  Wed Feb  7 15:28:11 2007
From: michael.dauria at gmail.com (Michael D'Auria)
Date: Wed, 7 Feb 2007 15:28:11 -0500
Subject: [Mongrel] Apache+Mongrel Redirection Problems
In-Reply-To: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>
References: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>
Message-ID: <1907e2ca0702071228k444fe0f2qdff431b99b768cfa@mail.gmail.com>

You have the server names as "rss" and "railstest", don't you have to access
them via those hosts?

http://rss/about

Otherwise Apache defaults to the first VirtualHost definition.


On 2/7/07, Stan Baptista <stan.baptista at gmail.com> wrote:
>
> Hi folks,
>
> Newbie issues...I'm prototying an Apache/Mongrel configuration setup
> as follows:
>
> * Two Mongrel servers each serving a Rails application.
> * Apache front-end.
> * Linux system (CentOS)
> * The plan is to create two virtual hosts.
>
> /ETC/HOSTS LOOKS LIKE THIS:
>
> # Do not remove the following line, or various programs
> # that require network functionality will fail.
> 127.0.0.1       localhost.localdomain   localhost       egovm04
> 10.4.1.84       rss
> 10.4.1.84       railstest
>
> HTTPD.CONF LOOKS LIKE THIS:
>
> [snip]
>
> NameVirtualHost 10.4.1.84
>
> <VirtualHost rss>
>     ServerName rss
>     ServerAlias rss
>
>     RewriteEngine on
>     RewriteRule ^/rss(.*) http://10.4.1.84:5432$1 <http://10.4.1.84:5432/>[P]
>
>     ProxyPass / http://10.4.1.84:5432/
>     ProxyPassReverse / http://10.4.1.84:5432/
>
> </VirtualHost>
>
> <VirtualHost railstest>
>
>     ServerName railstest
>     ServerAlias railstest
>
>     RewriteEngine on
>     RewriteRule ^/railstest(.*) http://10.4.1.84:8021$1<http://10.4.1.84:8021/>[P]
>
>     ProxyPass / http://10.4.1.84:8021/
>     ProxyPassReverse / http://10.4.1.84:8021/
>
> </VirtualHost>
>
> ISSUES
>
> 1. App 1 (rss) URL rewrite problem.
>
> Typing 'http://10.4.1.84/rss' <http://10.4.1.84/rss%27> in the browser
> correctly accesses app #1
> (rss), HOWEVER...
>
> This: ' http://10.4.1.84/rss/about' <http://10.4.1.84/rss/about%27> finds
> the right page, but the URL
> is rewritten to this: 'http://10.4.1.84/about' <http://10.4.1.84/about%27>
>
> 2. App # 2 not found.
>
> Typing this: 'http://10.4.1.84/railstest' <http://10.4.1.84/railstest%27>yields this:
>
> Routing Error
> Recognition failed for "/railstest"
>
> This is a Rails message reported by app # 1( rss). So the (Apache)
> server is not redirecting to the second Virtual Host (railstest).
>
> Sorry for the question, I'm quite sure this is a setup problem on my
> part.
>
> Thanks,
> Stan
>
> _______________________________________________
> 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/20070207/a138d469/attachment.html 

From msoulier at digitaltorque.ca  Wed Feb  7 16:32:44 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Wed, 7 Feb 2007 16:32:44 -0500
Subject: [Mongrel] log to stdout?
Message-ID: <20070207213244.GA8698@tigger.digitaltorque.ca>

Hello,

I have mongrel_rails supervised via runit, and it would be helpful if it could
log everything to stdout so it can be captured with svlogd.

Is it possible to tell mongrel to log everything to stdout? What about rails?

Thanks,
Mike
-- 
Michael P. Soulier <msoulier at digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070207/c7fd963f/attachment.bin 

From stan.baptista at gmail.com  Wed Feb  7 16:36:58 2007
From: stan.baptista at gmail.com (Stan Baptista)
Date: Wed, 7 Feb 2007 11:36:58 -1000
Subject: [Mongrel] Apache+Mongrel Redirection Problems
In-Reply-To: <1907e2ca0702071228k444fe0f2qdff431b99b768cfa@mail.gmail.com>
References: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>
	<1907e2ca0702071228k444fe0f2qdff431b99b768cfa@mail.gmail.com>
Message-ID: <2ba0f72b0702071336n6928953foff1661a498e91a33@mail.gmail.com>

Michael,

Thanks for your help.

> You have the server names as "rss" and "railstest", don't you have to
access them via those hosts?

If I put these entries in my local hosts file:

 10.4.1.84 rss
10.4.1.84 railstest

they are then accessible from my browser using these addresses:

http://rss
http://railstest

Adding them to my local computer's hosts file is OK for my own use but there
are a few other folks I'd like to show these to scattered throughout the
site where I work and I'd like to find a way to do this other than modifying
the hosts file on each system.

One of the webmasters here thought it was sufficient to add the lines
above to the _remote_ system's hosts file and adding RewriteRules to each
VirtualHost directive.

The goal is to be able to do this from anywhere:

http://10.4.1.84/rss
 http://10.4.1.84/railstest

(But no;-)

As you suggested, the remote system is taking the first VirtuaHost directive
and is actually trying to find "railstest" on the first Mongrel site (rss)
and, of course, not finding it.

-Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070207/c9777b17/attachment.html 

From kraemer at webit.de  Thu Feb  8 04:32:05 2007
From: kraemer at webit.de (Jens Kraemer)
Date: Thu, 8 Feb 2007 10:32:05 +0100
Subject: [Mongrel] Apache+Mongrel Redirection Problems
In-Reply-To: <2ba0f72b0702071336n6928953foff1661a498e91a33@mail.gmail.com>
References: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>
	<1907e2ca0702071228k444fe0f2qdff431b99b768cfa@mail.gmail.com>
	<2ba0f72b0702071336n6928953foff1661a498e91a33@mail.gmail.com>
Message-ID: <20070208093205.GF20182@cordoba.webit.de>

Hi!

On Wed, Feb 07, 2007 at 11:36:58AM -1000, Stan Baptista wrote:
> Michael,
> 
> Thanks for your help.
> 
> >You have the server names as "rss" and "railstest", don't you have to
> access them via those hosts?
> 
> If I put these entries in my local hosts file:
> 
> 10.4.1.84 rss
> 10.4.1.84 railstest
> 
> they are then accessible from my browser using these addresses:
> 
> http://rss
> http://railstest
> 
> Adding them to my local computer's hosts file is OK for my own use but there
> are a few other folks I'd like to show these to scattered throughout the
> site where I work and I'd like to find a way to do this other than modifying
> the hosts file on each system.
> 
> One of the webmasters here thought it was sufficient to add the lines
> above to the _remote_ system's hosts file and adding RewriteRules to each
> VirtualHost directive.

that can't work, because the client (the browser) needs to send a
correct Host header for Apache to know which virtual host definition to
use. Usually the value for that host header is taken from the location
the user entered into the location bar. If possible you should get some
admin to create dns records for these host names pointing to your IP, so
that everyone can use these host names to access your apps.

> 
> The goal is to be able to do this from anywhere:
> 
> http://10.4.1.84/rss
> http://10.4.1.84/railstest

You won't get to work this with apache virtual hosts. instead you need
to mount your apps under these paths, I didn't ever do this but afair it
has been discussed on the list several times.

Jens

-- 
webit! Gesellschaft f?r neue Medien mbH          www.webit.de
Dipl.-Wirtschaftsingenieur Jens Kr?mer       kraemer at webit.de
Schnorrstra?e 76                         Tel +49 351 46766  0
D-01069 Dresden                          Fax +49 351 46766 66

From piet.hadermann at seagha.com  Thu Feb  8 06:59:53 2007
From: piet.hadermann at seagha.com (Piet Hadermann)
Date: Thu, 8 Feb 2007 12:59:53 +0100
Subject: [Mongrel] mongrel limiting amount of connections ?
Message-ID: <67B95D61E544254F98FE975AA08F2FB2D86354@srv-mail.win.antwerp.seagha.com>

Hi!
 
I've been using Mongrel in a Rails setup with HAProxy as a loadbalancer.
 
I used to use Pound, but HAProxy is much more performant and has the
very nice option to limit the amount of requests sent to the backend
servers/processes. In practice, this means that a new incoming request
will not be sent to a Mongrel that's already busy processing a request.
 
There's an exception to this wonderful world though. If a request takes
a long time to finish, either HAProxy can timeout, or the user presses
the 'stop' button or does a reload. This means that there's no way the
result of whatever that Rails process is doing at that time will make it
back to the user. Also, in this case HAProxy thinks the backend server
is ready to accept a new connection, which will only get queued up a
Mongrel level, causing yet another user to wait for ages or do a
stop/reload, leading to a possibe escalation of long running processes
and users waiting for responses.
 
Wouldn't it be possible to have an option where you kill the current
running thread (Rails process) when a new one gets accepted ? I believe
that's what the -n option was meant to do, still, this doesn't seem to
work 100% the way I'd except it to (which means nothing). In my
experiments, the long running request just continues until it's
finished.
 
Alternatively if mongrel wouldn't accept new requests when it's still
busy processing one, and the loadbalancer (HAProxy) would detect it
can't connect and try the next server, this would be a smaller step in
the right direction (I think).
 
I know you should just avoid long-running processes and let backgroundrb
handle them, which I do in several cases, but on one installation
there's so much data in the (oracle) database which is continuously
growing that if it decides to take an alternative path to resolving a
query this can have a disastrous impact on performance.
 
These are just my ideas, if anyone has a better solution or suggestions,
I'd really like to hear about them.
 
Piet.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070208/ed036001/attachment.html 

From filipe at icewall.org  Thu Feb  8 08:15:06 2007
From: filipe at icewall.org (Filipe)
Date: Thu, 8 Feb 2007 11:15:06 -0200 (BRST)
Subject: [Mongrel] mongrel_rails man page
Message-ID: <Pine.LNX.4.64.0702081109340.3603@sophie.icewall.org>


Hello!

hey, I've been writing this man page for mongrel_rails for some time and
now I wanted the list to take a look at it and see if it's good.

After it's ok, and if zed want to integrate it in mongrel (or any other
distribution wants it), the debian note can be removed :D

Manual Page:


.TH MONGREL_RAILS 1 "2006-11-17" "Mongrel Rails"
.SH NAME
mongrel_rails \- Ruby Web Server
.
.SH SYNOPSIS
.B mongrel_rails 
.RI <command> 
[options]
.
.SH DESCRIPTION
Mongrel is a fast HTTP library and server for Ruby that is intended for hosting Ruby web applications of any kind using plain HTTP rather than FastCGI or SCGI. It is framework agnostic and already supports Ruby On Rails, Og+Nitro, Camping, and IOWA frameworks.
.PP
Mongrel turns out to be really nice for development since it serves files much faster than WEBrick. For example, to use it in development with Ruby on Rails is easy as this:
.PP
$ mongrel_rails start
.PP
Mongrel is a self-documenting program by giving you an extensive help listing for each command. If you think that this manual page is outdated, simply running 
.B mongrel_rails start -h
will print out each possible option and what it does.
.PP
These options are also used in the 
.B -C config_file
option to set them without using the command line. The name used in the config file is slightly different since it's a YAML file. .br
Mongrel has a -G (generate) feature that will take any command line options you give it, generate the YAML file to replicate those options, and then exit. For example, you could make a config file like this:
.PP
.B mongrel_rails start -G mongrel_8080.yml -e production -p 8080
.PP
And it'll write all the options possible to mongrel_8080.yml, but with your specific changed for environment (-e production) and port (-p 8080). When you run a configuration file with -C, don't pass other options. Rather than have complex rules about whether a configuration file or command line option wins, mongrel_rails just uses configuration file and defaults, or command line options and defaults. Basically don't mix, it won't work.
.
.SH COMMANDS
The following commands are supported by mongrel:
.PP
\fBstart\fP 				Starts the server.
.br
\fBstop\fP					Stops the server. Mongrel is very conservative when it shuts down, so it will wait up to 60 seconds for threads to exit before it finally exits gracefully.
.br
\fBstop --force [--wait n]\fP	Stops the server. This sends mongrel a kill -9 and then you must delete the .pid file. If the wait parameter is specified, mongrel will wait n seconds before it sends the kill sign.
.br
\fBrestart\fP				Restarts the server.
.
.SH OPTIONS
Mongrel is extensible configurable, and it has the following configuration options (the name to use in configuration file is in parenthesis after the option name):
.PP
\fB-e, --environment ENV\fP (:environment)	Configures your Rails environment to what you need.
.br
.I									* Default: development
.br
\fB-d, --daemonize\fP (:daemon)			If given (no options) then Mongrel will run in the background.
.br
.I									* Default: false
.br
\fB-p, --port PORT\fP (:port)				Port to bind to when listening for connections.
.br
.I									* Default: 3000
.br
\fB-a, --address ADDR\fP (:host)			Address to bind to when listening for connections.
.br
.I									* Default: 0.0.0.0 (every interface)
.br
\fB-l, --log PATH\fP (:log_file)			Where to dump log messages in daemon mode - use an absolute path.
.br
.I									* Default: $PWD/log/mongrel.log
.br
\fB-P, --pid PATH\fP (:pid_file)			Where to write the PID file so start and stop commands know the Process ID - use absolute paths.
.br
.I									* Default: $PWD/log/mongrel.pid
.br
\fB-n,--num-procs PROCS\fP (:num_processors)	Maximum number of concurrent processing threads before Mongrel starts denying connections and trying to kill old threads.
.br
.I									* Default: 1024
.br
\fB-t, --timeout SEC\fP (:timeout)			Time to pause between accepting clients. Used as a throttle mechanism.
.br
.I									* Default: 0
.br
\fB-m, --mime PATH\fP (:mime_map)			A YAML file that lists additional MIME types.
.br
.I									* Default: not set.
.br
\fB-c, --chdir PATH\fP (:cwd)				Directory to change to prior to starting Mongrel.
.br
.I									* Default: . (current directory)
.br
\fB-r, --root PATH\fP (:docroot)			Document root where Mongrel should serve files from. If you are putting Mongrel under a different base URI, and you want it to serve files out of a different directory then you need to set this.
.br
.I									* Default: public
.br
\fB-B, --debug\fP (:debug)				Turns on a debugging mode which traces objects, threads, files request parameters, and logs accesses writing them to log/mongrel_debug. This option makes Mongrel very slow.
.br
.I									* Default: false
.br
\fB-C, --config PATH\fP (NONE)				Specifies a configuration YAML file that sets options - use absolute paths.
.br
.I									* Default: no default
.br
\fB-S, --script PATH\fP (:config_script)		A special Ruby file that is run after Rails is configured to give you the ability to change the configuration with Ruby. This would be where you can load customer Mongrel handlers, extra libraries, or setup additional Ruby code. This option is fairly advanced so use with caution.
.br
.I									* Default: not set
.br
\fB-G, --generate PATH\fP (NONE)			Takes whatever options set for Mongrel, and the current defaults, and then writes them to a YAML file suitable for use with the -C option.
.br
.I									* Default: not set
.br 
\fB--prefix URI\fP						A URI to mount your Rails application at rather than the default /. This URI is stripped off all requests by Rails (not Mongrel) so it cannot end in /.
.br
.I									* Default: not set
.br
\fB--user USER\fP						Must have --group too. The user to change to right after creating the listening socket. Use this if you have to bind Mongrel to a low port like port 80, but don't want Mongrel to run as root.
.br
.I									* Default: not set
.br
\fB--group GROUP\fP						Must have --user too. The group to change to right after creating the listening socket.
.br
.I									* Default: not set
.br
\fB-h, --help\fP						Show help message
.br
\fB--version\fP							Show mongrel version
.
.SH SEE ALSO
.BR pen (1), mongrel (1)
.
.SH AUTHOR
Mongrel (http://mongrel.rubyforge.org/) was written by Zed Shaw.
This manual page was written for the Debian system by Filipe Lautert <filipe at icewall.org>. 
It might be used and redistributed under the same terms as the program itself.


---
Thanks,

filipe lautert

filipe { AT ] icewall.org
GPG        1024D/A6BA423E
Jabber  lautert at jabber.ru

From rgl at ruilopes.com  Thu Feb  8 09:53:44 2007
From: rgl at ruilopes.com (Rui Lopes)
Date: Thu, 08 Feb 2007 14:53:44 +0000
Subject: [Mongrel] mongrel cluster and local gems loading problem
Message-ID: <45CB3978.1030202@ruilopes.com>

Hello,

I'm trying to augment the GEM_PATH to load gems from ~/.gem/ using this
at the begging of the rails application config/environment.rb file:

  ENV['GEM_PATH'] = File.expand_path('~/.gem')

This works fine from within script/console:

  $ script/console
>> require 'pdf/writer'
=> true

But when I try to run:

  mongrel_rails cluster::start

It fails to load the local gem.

I started to dig into the code, and realized that rubygems is
initialized by mongrel_rails before it loads the environment.rb file,
which results in GEM_PATH env. variable being "ignored" (because rubygem
Gem.path method caches the path on the first use, which is done by
mongrel_rails).  To make this work, I had come to this hack:

  ENV['GEM_PATH'] = File.expand_path('~/.gem')
  require 'rubygems'; Gem.clear_paths;
Gem.instance_variable_set(:@searcher, nil)

Which clears the internal cache used by rubygems, and forces it to
re-read the GEM_PATH env. variable.

But I don't fell comfortable using it... is there a better way to do
this?  Like, setting the GEM_PATH from the mongrel cluster config file?


Best regards,
Rui Lopes

PS: require 'rubygems' is needed just in case we run script/console from
console.

From Daniel.Berger at qwest.com  Thu Feb  8 11:56:14 2007
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Thu, 8 Feb 2007 10:56:14 -0600
Subject: [Mongrel] Informal benchmarks - apache, mongrel, etc
Message-ID: <7524A45A1A5B264FA4809E2156496CFB0D0E8E@ITOMAE2KM01.AD.QINTRA.COM>

I see that Brian McCallister did some benchmarks recently, showing
Apache, Mongrel, Jetty and TwisteWeb:

http://kasparov.skife.org/blog/src/ruby/silly-micro-benchmarks.html

Regards,

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 Feb  8 16:22:02 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 8 Feb 2007 13:22:02 -0800
Subject: [Mongrel] Informal benchmarks - apache, mongrel, etc
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0E8E@ITOMAE2KM01.AD.QINTRA.COM>
References: <7524A45A1A5B264FA4809E2156496CFB0D0E8E@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <20070208132202.ef403805.zedshaw@zedshaw.com>

On Thu, 8 Feb 2007 10:56:14 -0600
"Berger, Daniel" <Daniel.Berger at qwest.com> wrote:

> I see that Brian McCallister did some benchmarks recently, showing
> Apache, Mongrel, Jetty and TwisteWeb:
> 
> http://kasparov.skife.org/blog/src/ruby/silly-micro-benchmarks.html

*Sigh*, yeah those are really informative.

Why do people do crap like this?  You don't see me over on the stomp
list bitching about it's dumbass requirement that it be accessible via
telnet.  You don't see me whining about stomp using a shit framing
mechanism or copying all the worst parts of HTTP over.  

In fact, I wrote a damn parser for Stomp with Ragel and gave it to
Brian.  Twice.

What do I get from Brian?  Whining and complaining that there's no
keep-alives or pipelining and the only "proof" he offers for their
requirement is a single sentence at the bottom of a page full of
randomness.

-- 
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.

From jarkko at jlaine.net  Thu Feb  8 16:00:17 2007
From: jarkko at jlaine.net (Jarkko Laine)
Date: Thu, 8 Feb 2007 23:00:17 +0200
Subject: [Mongrel] Informal benchmarks - apache, mongrel, etc
In-Reply-To: <20070208132202.ef403805.zedshaw@zedshaw.com>
References: <7524A45A1A5B264FA4809E2156496CFB0D0E8E@ITOMAE2KM01.AD.QINTRA.COM>
	<20070208132202.ef403805.zedshaw@zedshaw.com>
Message-ID: <5B72D6CB-DE7A-4DAB-BD8C-D99CE7BE67FD@jlaine.net>

On 8.2.2007, at 23.22, Zed A. Shaw wrote:
> What do I get from Brian?  Whining and complaining that there's no
> keep-alives or pipelining and the only "proof" he offers for their
> requirement is a single sentence at the bottom of a page full of
> randomness.

At least he self admits the benchmarks were useless :-/

//jarkko

--
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/20070208/bf958814/attachment.bin 

From stan.baptista at gmail.com  Thu Feb  8 16:15:36 2007
From: stan.baptista at gmail.com (Stan Baptista)
Date: Thu, 8 Feb 2007 11:15:36 -1000
Subject: [Mongrel] Apache+Mongrel Redirection Problems
In-Reply-To: <20070208093205.GF20182@cordoba.webit.de>
References: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>
	<1907e2ca0702071228k444fe0f2qdff431b99b768cfa@mail.gmail.com>
	<2ba0f72b0702071336n6928953foff1661a498e91a33@mail.gmail.com>
	<20070208093205.GF20182@cordoba.webit.de>
Message-ID: <2ba0f72b0702081315y3c2591b1n752ede7369bba6d2@mail.gmail.com>

 >that can't work, because the client (the browser) needs to send a
correct Host header for Apache to know which virtual host definition to
use. Usually the value for that host header is taken from the location
the user entered into the location bar. If possible you should get some
admin to create dns records for these host names pointing to your IP, so
that everyone can use these host names to access your apps.

I got this working as follows:

/etc/hosts:

# Do not remove the following line, or various programs
>
> # that require network functionality will fail.127.0.0.1    localhost.localdomain   localhost       egovm0410.4.1.84    rss10.4.1.84    railstest
>
> /usr/local/apache22/conf/httpd.conf:

   NameVirtualHost 10.4.1.84
>
>    <VirtualHost 10.4.1.84>
>
>      RewriteEngine on
>      RewriteRule ^/rss(.*) http://10.4.1.84:5432$1 [P]
>      RewriteRule ^/railstest(.*) http://10.4.1.84:8021$1 [P]
>
>    </VirtualHost>
>
>    <VirtualHost 10.4.1.84>
>
>      ServerName rss
>      ProxyPass / http://10.4.1.84:5432/
>      ProxyPassReverse /rss http://10.4.1.84:5432/
>      ProxyPreserveHost on
>
>    </VirtualHost>
>
>    <VirtualHost 10.4.1.84>
>
>      ServerName railstest
>      ProxyPass / http://10.4.1.84:8021/
>      ProxyPassReverse /railstest http://10.4.1.84:8021/
>      ProxyPreserveHost on
>
>    </VirtualHost>
>
>
Note that three VirtualHost directives are required. The first (default) is
to create the rewrite rules and the next two contain the ProxyPass...
directives that map to the Mongrel servers.

Issues

Typing this in the browser:

  http://egovm04.higov.net/rss/about
>
>
Correctly accesses the about page, but the address in the browser shows
this:

  http://egovm04.higov.net/about
>
> Link mappings within the browser do not work correctly (most likely not an
Apache problem.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070208/7be708cd/attachment.html 

From pberry at gmail.com  Thu Feb  8 17:08:48 2007
From: pberry at gmail.com (Patrick Berry)
Date: Thu, 8 Feb 2007 14:08:48 -0800
Subject: [Mongrel] Informal benchmarks - apache, mongrel, etc
In-Reply-To: <5B72D6CB-DE7A-4DAB-BD8C-D99CE7BE67FD@jlaine.net>
References: <7524A45A1A5B264FA4809E2156496CFB0D0E8E@ITOMAE2KM01.AD.QINTRA.COM>
	<20070208132202.ef403805.zedshaw@zedshaw.com>
	<5B72D6CB-DE7A-4DAB-BD8C-D99CE7BE67FD@jlaine.net>
Message-ID: <ef13ff170702081408y7af6561bg5c38237da1883735@mail.gmail.com>

On 2/8/07, Jarkko Laine <jarkko at jlaine.net> wrote:
>
> On 8.2.2007, at 23.22, Zed A. Shaw wrote:
> > What do I get from Brian?  Whining and complaining that there's no
> > keep-alives or pipelining and the only "proof" he offers for their
> > requirement is a single sentence at the bottom of a page full of
> > randomness.
>
> At least he self admits the benchmarks were useless :-/
>
> //jarkko



Yeah, I also understand Zed's frustration.  These are the kind of things
that get picked up on /. or digg on a slow day and, well...you know what
happens then.

Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070208/b203fe5e/attachment.html 

From joost at spacebabies.nl  Thu Feb  8 17:13:19 2007
From: joost at spacebabies.nl (joost baaij)
Date: Thu, 8 Feb 2007 23:13:19 +0100
Subject: [Mongrel] Informal benchmarks - apache, mongrel, etc
In-Reply-To: <20070208132202.ef403805.zedshaw@zedshaw.com>
References: <7524A45A1A5B264FA4809E2156496CFB0D0E8E@ITOMAE2KM01.AD.QINTRA.COM>
	<20070208132202.ef403805.zedshaw@zedshaw.com>
Message-ID: <74AC666B-3EB8-4ACC-BC47-CB8FDDBEC682@spacebabies.nl>


Op 8-feb-2007, om 22:22 heeft Zed A. Shaw het volgende geschreven:

> Why do people do crap like this?  You don't see me over on the stomp
> list bitching about it's dumbass requirement that it be accessible via
> telnet.  You don't see me whining about stomp using a shit framing
> mechanism or copying all the worst parts of HTTP over.

Well some people just like to hear themselves talk. The actual words  
really don't matter, it's more the sound their lips make. It's  
soothing I guess. The voices inside, yes? It makes them stop.

J.
-- 
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/20070208/0dbaab3a/attachment-0001.bin 

From Daniel.Berger at qwest.com  Thu Feb  8 17:39:32 2007
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Thu, 8 Feb 2007 16:39:32 -0600
Subject: [Mongrel] Informal benchmarks - apache, mongrel, etc
In-Reply-To: <ef13ff170702081408y7af6561bg5c38237da1883735@mail.gmail.com>
Message-ID: <7524A45A1A5B264FA4809E2156496CFB0D0E93@ITOMAE2KM01.AD.QINTRA.COM>

On 2/8/07, Jarkko Laine <jarkko at jlaine.net> wrote:

<snip>

>Yeah, I also understand Zed's frustration.  These are the kind of
things that get picked up on /. or digg on a slow day >and, well...you
know what happens then. 

Yes. You have to suffer through the following comments:

* In Soviet Russia, Mongrel benchmarks run YOU!
* Imagine a Beowulf cluster running Mongrel!
* Yes, but does Mongrel run Linux?
* Random goats.ex links
* Netcraft confirms, Mongrel is dying.
* All your Mongrel are belong to us!
* In Korea, only old people run Mongrel.
* I, for one, welcome our new Mongrelian Overlords.

And, last but not least:

1) Install Mongrel
2) Run hundreds of Mongrel instances
3) ???
4) Profit!!!

Regards,

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 joost at spacebabies.nl  Thu Feb  8 17:52:24 2007
From: joost at spacebabies.nl (joost baaij)
Date: Thu, 8 Feb 2007 23:52:24 +0100
Subject: [Mongrel] Informal benchmarks - apache, mongrel, etc
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0E93@ITOMAE2KM01.AD.QINTRA.COM>
References: <7524A45A1A5B264FA4809E2156496CFB0D0E93@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <706A4498-3DDE-4934-973F-446A5B92303E@spacebabies.nl>

You forgot one: the form response. Other than that: LOL!

You are advocating a
[ ] multi threaded webserver
[ ] multiprocess webserver
[ ] event driven webserver
[ ] single-process webserver
[ ] combination of the above

It won't scale because
[ ] there is not enough ram
[ ] you will run out of file descriptors
[ ] it cannot access a shared memory store
[ ] it's too slow
[ ] people won't use it
[ ] it's too expensive
[ ] you are not teh leet

etc...


Op 8-feb-2007, om 23:39 heeft Berger, Daniel het volgende geschreven:

> On 2/8/07, Jarkko Laine <jarkko at jlaine.net> wrote:
>
> <snip>
>
>> Yeah, I also understand Zed's frustration.  These are the kind of
> things that get picked up on /. or digg on a slow day >and, well...you
> know what happens then.
>
> Yes. You have to suffer through the following comments:
>
> * In Soviet Russia, Mongrel benchmarks run YOU!
> * Imagine a Beowulf cluster running Mongrel!
> * Yes, but does Mongrel run Linux?
> * Random goats.ex links
> * Netcraft confirms, Mongrel is dying.
> * All your Mongrel are belong to us!
> * In Korea, only old people run Mongrel.
> * I, for one, welcome our new Mongrelian Overlords.
>
> And, last but not least:
>
> 1) Install Mongrel
> 2) Run hundreds of Mongrel instances
> 3) ???
> 4) Profit!!!
>
> Regards,
>
> 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.
> _______________________________________________
> 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/20070208/d9c65731/attachment.bin 

From mongrel at philip.pjkh.com  Thu Feb  8 18:17:48 2007
From: mongrel at philip.pjkh.com (Philip Hallstrom)
Date: Thu, 8 Feb 2007 17:17:48 -0600 (CST)
Subject: [Mongrel] Informal benchmarks - apache, mongrel, etc
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0E93@ITOMAE2KM01.AD.QINTRA.COM>
References: <7524A45A1A5B264FA4809E2156496CFB0D0E93@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <20070208171506.S3035@bravo.pjkh.com>

>> Yeah, I also understand Zed's frustration.  These are the kind of
> things that get picked up on /. or digg on a slow day >and, well...you
> know what happens then.
>
> Yes. You have to suffer through the following comments:
>
> * In Soviet Russia, Mongrel benchmarks run YOU!
> * Imagine a Beowulf cluster running Mongrel!
> * Yes, but does Mongrel run Linux?
> * Random goats.ex links
> * Netcraft confirms, Mongrel is dying.
> * All your Mongrel are belong to us!
> * In Korea, only old people run Mongrel.
> * I, for one, welcome our new Mongrelian Overlords.
>
> And, last but not least:
>
> 1) Install Mongrel
> 2) Run hundreds of Mongrel instances
> 3) ???
> 4) Profit!!!

I only wish you had a typo or other error in your message so we could 
round out the selection of posts with a thourough grammatical lashing!

Followed by several more posts pointing out every error in this post.

Followed by several more telling all of us to get a life.

Otherwise I think you just about nailed it :)

From samuelgiffney at gmail.com  Thu Feb  8 20:37:23 2007
From: samuelgiffney at gmail.com (Sam Giffney)
Date: Fri, 9 Feb 2007 14:37:23 +1300
Subject: [Mongrel] mongrel, gem & cgi_multipart_eof_fix updates
Message-ID: <fc7839340702081737j212885d5u501c1a5b82a8f80a@mail.gmail.com>

This might just have affected my particular setup but thought it might
be worth noting for others.

>gem -v
0.9.2

>gem list --local
cgi_multipart_eof_fix (1.0.0)
    Fix an exploitable bug in CGI multipart parsing which affects Ruby
    <= 1.8.5.
mongrel (1.0.1, 1.0, 0.3.20, 0.3.18, 0.3.13.4)
    A small fast HTTP library and server that runs Rails, Camping, Nitro
    and Iowa apps.

>gem outdated
cgi_multipart_eof_fix (1.0.0 < 1.0.0)

which I thought was weird. Reinstalling the latest mongrel didn't
update the cgi_multipart_eof_fix

>gem install mongrel --source=http://mongrel.rubyforge.org/releases/
Building native extensions.  This could take a while...
Successfully installed mongrel-1.0.1
Installing ri documentation for mongrel-1.0.1...
Installing RDoc documentation for mongrel-1.0.1...

but uninstalling

>gem uninstall cgi_multipart_eof_fix
You have requested to uninstall the gem:
        cgi_multipart_eof_fix-1.0.0
mongrel-1.0.1 depends on [cgi_multipart_eof_fix (>= 1.0.0)]

then reinstalling mongrel updated it

>gem install mongrel --source=http://mongrel.rubyforge.org/releases/
Building native extensions.  This could take a while...
Successfully installed mongrel-1.0.1
Successfully installed cgi_multipart_eof_fix-2.1
Installing ri documentation for mongrel-1.0.1...
Installing ri documentation for cgi_multipart_eof_fix-2.1...
Installing RDoc documentation for mongrel-1.0.1...
Installing RDoc documentation for cgi_multipart_eof_fix-2.1...

Maybe just my system, or some weird rubygem thang. Hopefully of
interest to someone.
Thanks Zed.
Sam

From pberry at gmail.com  Fri Feb  9 17:37:56 2007
From: pberry at gmail.com (Patrick Berry)
Date: Fri, 9 Feb 2007 14:37:56 -0800
Subject: [Mongrel] mongrel_cluster clarification
Message-ID: <ef13ff170702091437n7954fd81ta187aafb06edae48@mail.gmail.com>

Apologizes in advance if this sounds rather dense, but I want to make sure
I'm understanding everything correctly.  We're in the process of migrating
from Apache2.0/FastCGI to Apache2.0+mongrel (why not 2.2? that story is too
long and too uninteresting to recount here, but I will tell you that it
involves RHEL and only using RHN rpms).

The init script that comes with mongrel (when configured correctly for your
system) will act on each app that you configure in /etc/mongrel_cluster/.
So, at system boot all of your configured clusters will start.

The cap recipes will only act on the cluster for that particular app.  So, a
restart will only restart that cluster and not all configured clusters.

Thanks,
Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070209/f5077fd9/attachment.html 

From jason at joyent.com  Fri Feb  9 18:18:24 2007
From: jason at joyent.com (Jason A. Hoffman)
Date: Fri, 9 Feb 2007 15:18:24 -0800
Subject: [Mongrel] mongrel_cluster clarification
In-Reply-To: <ef13ff170702091437n7954fd81ta187aafb06edae48@mail.gmail.com>
References: <ef13ff170702091437n7954fd81ta187aafb06edae48@mail.gmail.com>
Message-ID: <D4D5A4C7-0601-4FF8-A832-88DA7B491627@joyent.com>


On Feb 9, 2007, at 2:37 PM, Patrick Berry wrote:

> Apologizes in advance if this sounds rather dense, but I want to  
> make sure I'm understanding everything correctly.  We're in the  
> process of migrating from Apache2.0/FastCGI to Apache2.0+mongrel  
> (why not 2.2? that story is too long and too uninteresting to  
> recount here, but I will tell you that it involves RHEL and only  
> using RHN rpms).
>
> The init script that comes with mongrel (when configured correctly  
> for your system) will act on each app that you configure in /etc/ 
> mongrel_cluster/.  So, at system boot all of your configured  
> clusters will start.
>
> The cap recipes will only act on the cluster for that particular  
> app.  So, a restart will only restart that cluster and not all  
> configured clusters.
>
> Thanks,
> Pat


Hi Pat,

How are you going to put more than one mongrel behind Apache 2.0?

Regards, Jason



From pberry at gmail.com  Fri Feb  9 18:27:11 2007
From: pberry at gmail.com (Patrick Berry)
Date: Fri, 9 Feb 2007 15:27:11 -0800
Subject: [Mongrel] mongrel_cluster clarification
In-Reply-To: <D4D5A4C7-0601-4FF8-A832-88DA7B491627@joyent.com>
References: <ef13ff170702091437n7954fd81ta187aafb06edae48@mail.gmail.com>
	<D4D5A4C7-0601-4FF8-A832-88DA7B491627@joyent.com>
Message-ID: <ef13ff170702091527t6242051cteb612b05fb98e2ca@mail.gmail.com>

On 2/9/07, Jason A. Hoffman <jason at joyent.com> wrote:
>
> Hi Pat,
>
> How are you going to put more than one mongrel behind Apache 2.0?
>
> Regards, Jason




Our apps are, at first, going to be very low traffic.  So we're planning on
doing virtual hosts with a ProxyPass setup to a mongrel_cluster only running
one server in each one (negating the need for mod_proxy_balancer or pen).
We thought about putting pen in the mix but decided by the time we have
enough requests to make us add more mongrels, we'll have Apache 2.2 (and
thus mod_proxy_balancer).

It's a bit of a cop-out, but these are all administrative apps at a
higher-ed institution, typically with 10 or fewer users, and we want to keep
things as simple as possible and yet as automated as possible.

Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070209/23f9469f/attachment.html 

From codeturkey at comcast.net  Fri Feb  9 20:13:57 2007
From: codeturkey at comcast.net (Steven Hansen)
Date: Fri, 09 Feb 2007 17:13:57 -0800
Subject: [Mongrel] mongrel_cluster clarification
In-Reply-To: <ef13ff170702091527t6242051cteb612b05fb98e2ca@mail.gmail.com>
References: <ef13ff170702091437n7954fd81ta187aafb06edae48@mail.gmail.com>	<D4D5A4C7-0601-4FF8-A832-88DA7B491627@joyent.com>
	<ef13ff170702091527t6242051cteb612b05fb98e2ca@mail.gmail.com>
Message-ID: <45CD1C55.608@comcast.net>


>
>     How are you going to put more than one mongrel behind Apache 2.0?
>

In case anyone is interested, I ran into this article the other day that 
shows how you can run multiple mongrels behind apache 2.0

http://times.usefulinc.com/2006/09/13-mongrel-apache20

Regards,
Steven

From me at seebq.com  Sat Feb 10 01:39:54 2007
From: me at seebq.com (Charles Brian Quinn)
Date: Sat, 10 Feb 2007 01:39:54 -0500
Subject: [Mongrel] mongrel_cluster clarification
In-Reply-To: <45CD1C55.608@comcast.net>
References: <ef13ff170702091437n7954fd81ta187aafb06edae48@mail.gmail.com>
	<D4D5A4C7-0601-4FF8-A832-88DA7B491627@joyent.com>
	<ef13ff170702091527t6242051cteb612b05fb98e2ca@mail.gmail.com>
	<45CD1C55.608@comcast.net>
Message-ID: <3a2de0cd0702092239i1e920cd1u1df667c4a5f13d05@mail.gmail.com>

Hey alright, nice and simple, can anyone else confirm this works decently?

If so, I'll toss it up on the Apache documents on mongrel.rubyforge.org....

On 2/9/07, Steven Hansen <codeturkey at comcast.net> wrote:
>
> >
> >     How are you going to put more than one mongrel behind Apache 2.0?
> >
>
> In case anyone is interested, I ran into this article the other day that
> shows how you can run multiple mongrels behind apache 2.0
>
> http://times.usefulinc.com/2006/09/13-mongrel-apache20
>
> Regards,
> Steven
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
Charles Brian Quinn
self-promotion: www.seebq.com
highgroove studios: www.highgroove.com
slingshot hosting: www.slingshothosting.com
main: 678.389.9462  fax: 678.826.0969

Ruby on Rails Bootcamp at the Big Nerd Ranch
Intensive Ruby on Rails Training:
http://www.bignerdranch.com/classes/ruby.shtml

From mail at oliver-muthig.de  Sat Feb 10 03:23:19 2007
From: mail at oliver-muthig.de (Oliver Muthig)
Date: Sat, 10 Feb 2007 09:23:19 +0100
Subject: [Mongrel] primary bonus of mongrel 1.0.1?
In-Reply-To: <20070126210118.W47013@bravo.pjkh.com>
References: <epdv1l$5nl$1@sea.gmane.org>	<20070126181838.70a5532b.zedshaw@zedshaw.com>	<6a7034b0701261557g1e61653w6787077d59912700@mail.gmail.com>	<20070126193909.aa4fa9e3.zedshaw@zedshaw.com>
	<20070126210118.W47013@bravo.pjkh.com>
Message-ID: <45CD80F7.4050608@oliver-muthig.de>

Hi,

the problem is not that there is not enough change information but that 
there is too much. What Andy and probably many others want is a concise 
document explaining on a high level why someone would like to upgrade to 
a new release, what pitfalls to avoid and what the most important new 
features are good for.

Most people follow the notion of "never change a running system". Also 
every change has costs associated to it. In a commercial environment you 
would need good arguments to spend money. Why should everyone experiment 
with the same feature set? Of course every application has it's 
specifics too.

In my experience there is no way to automate such a document.

Regards
Oliver

>> That's really the best I can do without help.  I have to automate 
>> things, and svn changelogs blow so I'm stuck.  Without automation I'd be 
>> burdened with writing this same information over and over again in 
>> various forms.  Considering there's a wealth of change information 
>> including svn logs, atom feeds, news announcements, bug trackers, 
>> forums, and mailing lists it's not like there's nothing.  So, I tell 
>> people if that's not enough, then your requirements are exceptional and 
>> you should do something for yourself to solve the problem.
>>
>> But, one thing I don't hear is a solution.  Just a criticism.  If you've 
>> got a particular tool that automates change logging the way you like it 
>> and want to do the work to get it implemented in the mongrel build 
>> process then step up and help.  Otherwise, what I got is the best I can 
>> do given my time constraints.


From michael.dauria at gmail.com  Sat Feb 10 17:24:21 2007
From: michael.dauria at gmail.com (Michael D'Auria)
Date: Sat, 10 Feb 2007 17:24:21 -0500
Subject: [Mongrel] mongrel_config has no output
In-Reply-To: <1907e2ca0612182217y566c59d8tb1405e58104f8d65@mail.gmail.com>
References: <1907e2ca0612182217y566c59d8tb1405e58104f8d65@mail.gmail.com>
Message-ID: <1907e2ca0702101424x461dd70u40c6a9e3560270c7@mail.gmail.com>

I came back to this after not looking at it for a while and it looks like
you can get the plugin to work just by modifying one line:

<gems_path>/mongrel_config-0.3/lib/mongrel_config/app.rb:
[71] self << template.result(binding)

remove "self <<" as it is not needed and all works as expected.  Now i can
use this as a guide for my idea (finally!)

I hope this helps someone out.

.: Michael :.

On 12/19/06, Michael D'Auria <michael.dauria at gmail.com> wrote:
>
> I am not sure what i am doing wrong here, but no matter what i try i get
> no output from mongrel_config:
> $ mongrel_rails configtool
>
> $ telnet localhost 3001
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /config/ HTTP/1.1
>
> HTTP/1.1 200 OK
> Connection: close
> Date: Tue, 19 Dec 2006 05:33:16 GMT
> Content-Type: text/html
> Content-Length: 0
>
> Connection closed by foreign host.
>
> Here is a YAML dump of the $server object:
> --- &id001 !ruby/object:Mongrel::HttpServer
> acceptor: !ruby/object:Thread {}
>
> classifier: !ruby/object:Mongrel::URIClassifier
>   handler_map:
>     /log:
>     - !ruby/object:Mongrel::DirHandler
>       default_content_type: application/octet-stream
>       index_html: index.html
>       listener: *id001
>       listing_allowed: true
>       path: /home/michael/hhp/trebleNation/log
>     /favicon.ico:
>     - !ruby/object:Mongrel::Error404Handler
>       listener: *id001
>       response: |-
>         HTTP/1.1 404 Not Found
>         Connection: close
>         Server: Mongrel 0.3.20
>
>         NOT FOUND
>     /config/resources:
>     - !ruby/object:Mongrel::DirHandler
>       default_content_type: application/octet-stream
>       index_html: index.html
>       listener: *id001
>       listing_allowed: true
>       path: /usr/local/lib/ruby/gems/1.8/gems/mongrel_config-0.3/resources
>
>     /config:
>     - !ruby/object:Mongrel::Camping::CampingHandler
>       files: !ruby/object:Mongrel::DirHandler
>         default_content_type: application/octet-stream
>         index_html: index.html
>         listing_allowed: false
>         path: /
>       guard: !ruby/object:Mutex {}
>
>       klass: !ruby/object:Module {}
>
>       listener: *id001
> death_time: 60
> host: 0.0.0.0
> num_processors: 1073741823
> port: "3001"
> socket: !ruby/object:TCPServer {}
>
> timeout: 0
> workers: !ruby/object:ThreadGroup {}
>
> What's weird is that i can go to: http://localhost:3001/config/resources and
> see the erb template output with <% .. %>.  Currently I am running Mongrel
> 0.3.20 but i had the issue with 0.3.18 as well.  System is an Ubuntu Edgy
> on 2.6.17-10 kernel.
>
> Any help would be greatly appreciated,
>
> .: Michael :.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070210/256ac299/attachment.html 

From curtis.hatter at insightbb.com  Sun Feb 11 17:20:00 2007
From: curtis.hatter at insightbb.com (Mitchell Curtis Hatter)
Date: Sun, 11 Feb 2007 17:20:00 -0500
Subject: [Mongrel] rails cache problems
Message-ID: <FC48A7E6-7646-4128-AA31-FFB1D028B2AB@insightbb.com>

I'm having issues with page caching in Rails 1.1.6 where it's not  
always putting a .html extension at the end of the cached files (so I  
end up with files like 122.21 instead of 122.21.html). Then the next  
time it is served up via the web server (mongrel or apache) Firefox  
treats it as a binary file. I can't find a fix for this so I was  
hoping there would be a work around in Mongrel or Apache.

I tried ForceType text/html inside a <Directory> element in my apache  
configuration but that didn't seem to be completely reliable.

For now I'll switch to trying to use action caching instead.

Thanks,
Curtis

From technoweenie at gmail.com  Sun Feb 11 18:42:05 2007
From: technoweenie at gmail.com (Rick Olson)
Date: Sun, 11 Feb 2007 17:42:05 -0600
Subject: [Mongrel] rails cache problems
In-Reply-To: <FC48A7E6-7646-4128-AA31-FFB1D028B2AB@insightbb.com>
References: <FC48A7E6-7646-4128-AA31-FFB1D028B2AB@insightbb.com>
Message-ID: <48fe25b0702111542m64fcb70dsaab04d28ae72fd8f@mail.gmail.com>

On 2/11/07, Mitchell Curtis Hatter <curtis.hatter at insightbb.com> wrote:
> I'm having issues with page caching in Rails 1.1.6 where it's not
> always putting a .html extension at the end of the cached files (so I
> end up with files like 122.21 instead of 122.21.html). Then the next
> time it is served up via the web server (mongrel or apache) Firefox
> treats it as a binary file. I can't find a fix for this so I was
> hoping there would be a work around in Mongrel or Apache.
>
> I tried ForceType text/html inside a <Directory> element in my apache
> configuration but that didn't seem to be completely reliable.
>
> For now I'll switch to trying to use action caching instead.

It only adds .html if no extension is found.  It thinks .21 is the extension.

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

From curtis.hatter at insightbb.com  Sun Feb 11 19:43:58 2007
From: curtis.hatter at insightbb.com (Mitchell Curtis Hatter)
Date: Sun, 11 Feb 2007 19:43:58 -0500
Subject: [Mongrel] rails cache problems
In-Reply-To: <48fe25b0702111542m64fcb70dsaab04d28ae72fd8f@mail.gmail.com>
References: <FC48A7E6-7646-4128-AA31-FFB1D028B2AB@insightbb.com>
	<48fe25b0702111542m64fcb70dsaab04d28ae72fd8f@mail.gmail.com>
Message-ID: <13326313-B989-449E-ACC8-E7C068E7342C@insightbb.com>

> It only adds .html if no extension is found.  It thinks .21 is the  
> extension.

Thank you! I should have done this in the first place but after you  
said the above I looked into the Rails code and modified the page  
caching so that it always applies the extension.

Curtis

From eric at maverixsystems.com  Tue Feb 13 14:24:01 2007
From: eric at maverixsystems.com (Eric Dean)
Date: Tue, 13 Feb 2007 14:24:01 -0500
Subject: [Mongrel] Mongrel Stops Responding
Message-ID: <00ea01c74fa4$84844400$6501a8c0@SOHODEMO>

We have a development environment that every morning requires a restart
because Mongrel just stops responding.
 
I noticed this older thread...but I still experience the problem
http://rubyforge.org/pipermail/mongrel-users/2006-August/000950.html
 
We are running nginx..but I also have the mongrel ports open to our
IPs..both going through nginx proxy and directly through mongrel
fails...then restart it all works great:
 
any ideas?
[root at sb1 visualcareers]# mongrel_rails start --version
Version 1.0.1

 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070213/2f3ac96d/attachment.html 

From mwhitt89 at gmail.com  Tue Feb 13 15:24:46 2007
From: mwhitt89 at gmail.com (Matthew Whittaker)
Date: Tue, 13 Feb 2007 12:24:46 -0800
Subject: [Mongrel] Mongrel Stops Responding
In-Reply-To: <00ea01c74fa4$84844400$6501a8c0@SOHODEMO>
References: <00ea01c74fa4$84844400$6501a8c0@SOHODEMO>
Message-ID: <9C54D6B5-C239-4A1E-8268-8D1231C5B4BA@gmail.com>

Are you using Ruby to rotate your logs?  If so, this is your  
problem.  Have some external program manage your logs.

Cheers,

Matt


On Feb 13, 2007, at 11:24 AM, Eric Dean wrote:

> We have a development environment that every morning requires a  
> restart because Mongrel just stops responding.
>
> I noticed this older thread...but I still experience the problem
> http://rubyforge.org/pipermail/mongrel-users/2006-August/000950.html
>
> We are running nginx..but I also have the mongrel ports open to our  
> IPs..both going through nginx proxy and directly through mongrel  
> fails...then restart it all works great:
>
> any ideas?
> [root at sb1 visualcareers]# mongrel_rails start --version
> Version 1.0.1
>
>
> _______________________________________________
> 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/20070213/68018236/attachment.html 

From luislavena at gmail.com  Tue Feb 13 15:25:54 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 13 Feb 2007 17:25:54 -0300
Subject: [Mongrel] Mongrel Stops Responding
In-Reply-To: <00ea01c74fa4$84844400$6501a8c0@SOHODEMO>
References: <00ea01c74fa4$84844400$6501a8c0@SOHODEMO>
Message-ID: <71166b3b0702131225r38040318uf138cd055c78d481@mail.gmail.com>

On 2/13/07, Eric Dean <eric at maverixsystems.com> wrote:
>
>
> We have a development environment that every morning requires a restart
> because Mongrel just stops responding.
>
> I noticed this older thread...but I still experience the problem
> http://rubyforge.org/pipermail/mongrel-users/2006-August/000950.html
>
> We are running nginx..but I also have the mongrel ports open to our
> IPs..both going through nginx proxy and directly through mongrel
> fails...then restart it all works great:
>
> any ideas?
> [root at sb1 visualcareers]# mongrel_rails start --version
> Version 1.0.1
>

Will be very helpful if you could also include information about:

* The rails version you're using (ruby script/about).
* What database adapter (cat config/database.yml)
* What kind of session storage or memory cache (memcached) you're
using (in case of any).


Since it looks like the process is dying, could you read what are the
last lines of log/mongrel.log file? Maybe there is the ruby backtrace
thrown before mongrel dies.

-- 
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 matte at ruckuswireless.com  Tue Feb 13 15:20:04 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Tue, 13 Feb 2007 12:20:04 -0800
Subject: [Mongrel] mongrel_cluster 0.2.2 - plugin cluster::status does not
	exist?
Message-ID: <45D21D74.90702@ruckuswireless.com>

Hello all.  I've recently installed the 0.2.2 pre-release of 
mongrel_cluster to try out the new --clean option.  However, after 
installing, when I give a simple "mongrel_rails" command, the 
cluster::status command is not listed.  The error I receive when I do 
try and run the full "mongrel_rails cluster::status" is...

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

I'm running a FreeBSD 6 VPS.  here is the mongrel gem list.

*** LOCAL GEMS ***

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

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


I've rebooted the machine but to no avail.  And I have confirmed that my 
/usr/local/bin/mongrel* commands are the current ones.

Ideas?

Thanx in advance

matte - webmonkey
matte at ruckuswireless.com


From pberry at gmail.com  Tue Feb 13 16:44:12 2007
From: pberry at gmail.com (Patrick Berry)
Date: Tue, 13 Feb 2007 13:44:12 -0800
Subject: [Mongrel] mongrel_cluster 0.2.2 - plugin cluster::status does
	not exist?
In-Reply-To: <45D21D74.90702@ruckuswireless.com>
References: <45D21D74.90702@ruckuswireless.com>
Message-ID: <ef13ff170702131344h6ce69979ua5559b9dd12a912f@mail.gmail.com>

On 2/13/07, Matte Edens <matte at ruckuswireless.com> wrote:
>
> Hello all.  I've recently installed the 0.2.2 pre-release of
> mongrel_cluster to try out the new --clean option.  However, after
> installing, when I give a simple "mongrel_rails" command, the
> cluster::status command is not listed.  The error I receive when I do
> try and run the full "mongrel_rails cluster::status" is...
>
> ERROR RUNNING 'cluster::status': Plugin /cluster::status does not exist
> in category /commands
>
> I'm running a FreeBSD 6 VPS.  here is the mongrel gem list.
>
> *** LOCAL GEMS ***
>
> mongrel (1.0.1)
>     A small fast HTTP library and server that runs Rails, Camping, Nitro
>     and Iowa apps.
>
> mongrel_cluster (0.2.2, 0.2.1)
>     Mongrel plugin that provides commands and Capistrano tasks for
>     managing multiple Mongrel processes.
>
>
> I've rebooted the machine but to no avail.  And I have confirmed that my
> /usr/local/bin/mongrel* commands are the current ones.
>
> Ideas?



Removing the 0.2.1 version of the gem worked for me.

gem uninstall mongrel_cluster (it will prompt for which version you want to
uninstall)

Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070213/14e19ce8/attachment.html 

From matte at ruckuswireless.com  Tue Feb 13 17:59:06 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Tue, 13 Feb 2007 14:59:06 -0800
Subject: [Mongrel] mongrel_cluster 0.2.2 - plugin cluster::status does
 not exist?
In-Reply-To: <ef13ff170702131344h6ce69979ua5559b9dd12a912f@mail.gmail.com>
References: <45D21D74.90702@ruckuswireless.com>
	<ef13ff170702131344h6ce69979ua5559b9dd12a912f@mail.gmail.com>
Message-ID: <45D242BA.4020001@ruckuswireless.com>

Patrick Berry wrote:
> On 2/13/07, *Matte Edens* <matte at ruckuswireless.com 
> <mailto:matte at ruckuswireless.com>> wrote:
>
>     Hello all.  I've recently installed the 0.2.2 pre-release of
>     mongrel_cluster to try out the new --clean option.  However, after
>     installing, when I give a simple "mongrel_rails" command, the
>     cluster::status command is not listed.  The error I receive when I do
>     try and run the full "mongrel_rails cluster::status" is...
>
>     ERROR RUNNING 'cluster::status': Plugin /cluster::status does not
>     exist
>     in category /commands
>
>     I'm running a FreeBSD 6 VPS.  here is the mongrel gem list.
>
>     <snip>
>
>     Ideas?
>
>
>
> Removing the 0.2.1 version of the gem worked for me.
>
> gem uninstall mongrel_cluster (it will prompt for which version you 
> want to uninstall)
>
> Pat

Perfect.  Thanx Pat.  I used a "gem cleanup mongrel_cluster" which 
worked as well but that's more draconian since it removes ALL old 
instances instead of letting you pick and choose.  Which is fine for me

Doing that fixed the problem.  Now, finding out I have to run the 
command from inside the directory of a running app (duh), I'm getting 
the following errors output...

Checking 2 Mongrel servers...
ps: cmd: keyword not found
ps: no valid keywords; valid keywords:
Lost dog: 8000
ps: cmd: keyword not found
ps: no valid keywords; valid keywords:
Lost dog: 8001

The following line from the "status" function is incorrect (for my 
system at least)

ps_output = `ps -o cmd= -p #{pid}`

Running that line from the command line with a valid pid file gives me 
this...

$ ps -o cmd= -p 84086
ps: cmd: keyword not found
ps: no valid keywords; valid keywords:
%cpu %mem acflag acflg args blocked caught comm command cpu cputime emul 
etime f flags ignored inblk inblock jid jobc ktrace label lim lockname 
login logname
lstart lwp majflt minflt msgrcv msgsnd mwchan ni nice nivcsw nlwp 
nsignals nsigs nswap nvcsw nwchan oublk oublock paddr pagein pcpu 
pending pgid pid pmem ppid pri
re rgid rgroup rss rtprio ruid ruser sid sig sigcatch sigignore sigmask 
sl start stat state svgid svuid tdev time tpgid tsid tsiz tt tty ucomm 
uid upr uprocp user
usrpri vsize vsz wchan xstat

It works after changing the line to read...

ps_output = `ps -o command -p #{pid}`

I'm not successfully receiving...

Checking 2 Mongrel servers...
Found dog: 8000
Found dog: 8001

matte - webmonkey
matte at ruckuswireless.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070213/181a79fe/attachment.html 

From matte at ruckuswireless.com  Tue Feb 13 18:44:30 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Tue, 13 Feb 2007 15:44:30 -0800
Subject: [Mongrel] mongrel_cluster 0.2.2 - plugin cluster::status does
 not exist?
In-Reply-To: <45D242BA.4020001@ruckuswireless.com>
References: <45D21D74.90702@ruckuswireless.com>	<ef13ff170702131344h6ce69979ua5559b9dd12a912f@mail.gmail.com>
	<45D242BA.4020001@ruckuswireless.com>
Message-ID: <45D24D5E.3070508@ruckuswireless.com>

Matte Edens wrote:

<snip>

oops.  typing too fast.  that line below should read...

I'm _now_ succesfully receiving...

matte

> It works after changing the line to read...
>
> ps_output = `ps -o command -p #{pid}`
>
> I'm not successfully receiving...
>
> Checking 2 Mongrel servers...
> Found dog: 8000
> Found dog: 8001
>
> matte - webmonkey
> matte at ruckuswireless.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070213/b6f36f65/attachment.html 

From talk2sunder at gmail.com  Tue Feb 13 19:20:15 2007
From: talk2sunder at gmail.com (=?UTF-8?B?U3VuZGVyIFNvbWFzdW5kYXJhbQ==?=)
Date: Wed, 14 Feb 2007 00:20:15 +0000
Subject: [Mongrel] mongrel_cluster 0.2.2 - plugin cluster::status
	doesnot exist?
In-Reply-To: <45D242BA.4020001@ruckuswireless.com>
References: <45D21D74.90702@ruckuswireless.com><ef13ff170702131344h6ce69979ua5559b9dd12a912f@mail.gmail.com>
	<45D242BA.4020001@ruckuswireless.com>
Message-ID: <1514391032-1171412458-cardhu_blackberry.rim.net-1708577329-@bxe005-cell02.bisx.prod.on.blackberry>

R
  

-----Original Message-----
From: Matte Edens <matte at ruckuswireless.com>
Date: Tue, 13 Feb 2007 14:59:06 
To:mongrel-users at rubyforge.org
Subject: Re: [Mongrel] mongrel_cluster 0.2.2 - plugin cluster::status does
 not exist?

Patrick Berry wrote:
 
On 2/13/07, Matte Edens <matte at ruckuswireless.com> wrote: Hello all.??I've recently installed the 0.2.2 pre-release of
 mongrel_cluster to try out the new --clean option.??However, after
 installing, when I give a simple "mongrel_rails" command, the
 cluster::status command is not listed.??The error I receive when I do 
 try and run the full "mongrel_rails cluster::status" is...
 
 ERROR RUNNING 'cluster::status': Plugin /cluster::status does not exist
 in category /commands
 
 I'm running a FreeBSD 6 VPS.??here is the mongrel gem list. 
 
 <snip>
 
 Ideas? 

 
 Removing the 0.2.1 version of the gem worked for me.
 
 gem uninstall mongrel_cluster (it will prompt for which version you want to uninstall)
 
 Pat
 
 Perfect.? Thanx Pat.? I used a "gem cleanup mongrel_cluster" which worked as well but that's more draconian since it removes ALL old instances instead of letting you pick and choose.? Which is fine for me
 
 Doing that fixed the problem.? Now, finding out I have to run the command from inside the directory of a running app (duh), I'm getting the following errors output...
 
 Checking 2 Mongrel servers...
 ps: cmd: keyword not found
 ps: no valid keywords; valid keywords:
 Lost dog: 8000
 ps: cmd: keyword not found
 ps: no valid keywords; valid keywords:
 Lost dog: 8001
 
 The following line from the "status" function is incorrect (for my system at least)
 
 ps_output = `ps -o cmd= -p #{pid}`
 
 Running that line from the command line with a valid pid file gives me this...
 
 $ ps -o cmd= -p 84086
 ps: cmd: keyword not found
 ps: no valid keywords; valid keywords:
 %cpu %mem acflag acflg args blocked caught comm command cpu cputime emul etime f flags ignored inblk inblock jid jobc ktrace label lim lockname login logname
 lstart lwp majflt minflt msgrcv msgsnd mwchan ni nice nivcsw nlwp nsignals nsigs nswap nvcsw nwchan oublk oublock paddr pagein pcpu pending pgid pid pmem ppid pri
 re rgid rgroup rss rtprio ruid ruser sid sig sigcatch sigignore sigmask sl start stat state svgid svuid tdev time tpgid tsid tsiz tt tty ucomm uid upr uprocp user
 usrpri vsize vsz wchan xstat
 
 It works after changing the line to read...
 
 ps_output = `ps -o command -p #{pid}`
 
 I'm not successfully receiving...
 
 Checking 2 Mongrel servers...
 Found dog: 8000
 Found dog: 8001
 
 matte - webmonkey
 matte at ruckuswireless.com: <mailto:matte at ruckuswireless.com> 
 
 _______________________________________________
Mongrel-users mailing list
Mongrel-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

From bradley at railsmachine.com  Tue Feb 13 19:44:58 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Tue, 13 Feb 2007 19:44:58 -0500
Subject: [Mongrel] mongrel_cluster 0.2.2 - plugin cluster::status does
 not exist?
In-Reply-To: <45D242BA.4020001@ruckuswireless.com>
References: <45D21D74.90702@ruckuswireless.com>	<ef13ff170702131344h6ce69979ua5559b9dd12a912f@mail.gmail.com>
	<45D242BA.4020001@ruckuswireless.com>
Message-ID: <45D25B8A.6030008@railsmachine.com>

Hi Matte:

Thanks for trying status out on a BSD system. The command below works on 
linux, but doesn't return the same output:

bradley at machctl:~$ ps -o cmd= -p 17145
bash

bradley at machctl:~$ ps -o command -p 17145
COMMAND
bash

I'll see if I can make that ps call a little less linux-specific. In the 
mean time, I'm open to suggestions/patches from someone who can test on 
both.

Regards,
Bradley

> 
> It works after changing the line to read...
> 
> ps_output = `ps -o command -p #{pid}`
> 

From bradley at railsmachine.com  Tue Feb 13 19:56:02 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Tue, 13 Feb 2007 19:56:02 -0500
Subject: [Mongrel] mongrel_cluster 0.2.2 - plugin cluster::status does
 not exist?
In-Reply-To: <45D25B8A.6030008@railsmachine.com>
References: <45D21D74.90702@ruckuswireless.com>	<ef13ff170702131344h6ce69979ua5559b9dd12a912f@mail.gmail.com>	<45D242BA.4020001@ruckuswireless.com>
	<45D25B8A.6030008@railsmachine.com>
Message-ID: <45D25E22.50706@railsmachine.com>

I'm an idiot and didn't notice the missing '='.

bradley at machctl:~$ ps -o command= -p 17145
bash

bradley at machctl:~$ ps -o cmd= -p 17145
bash

Matte, could you please verify the above on your FreeBSD server?

Thanks,
Bradley

Bradley Taylor wrote:
> Hi Matte:
> 
> Thanks for trying status out on a BSD system. The command below works on 
> linux, but doesn't return the same output:
> 
> bradley at machctl:~$ ps -o cmd= -p 17145
> bash
> 
> bradley at machctl:~$ ps -o command -p 17145
> COMMAND
> bash
> 
> I'll see if I can make that ps call a little less linux-specific. In the 
> mean time, I'm open to suggestions/patches from someone who can test on 
> both.
> 
> Regards,
> Bradley
> 
>> It works after changing the line to read...
>>
>> ps_output = `ps -o command -p #{pid}`
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From pberry at gmail.com  Wed Feb 14 14:02:55 2007
From: pberry at gmail.com (Patrick Berry)
Date: Wed, 14 Feb 2007 11:02:55 -0800
Subject: [Mongrel] Such a nice setup thanks to mongrel/mongrel_cluster
Message-ID: <ef13ff170702141102m74cd7e24pd3b558f4c2709bd6@mail.gmail.com>

We're almost done with our migration from Apache+FastCGI to
Apache+mongrel_cluster.  There have been a few bumps in the road, mostly
deploy issues that have nothing to do with mongrel (we don't have root
access on our production server).

This is for a RedHat Enterprise Linux 4 setup.  Zed, would you want the
process we went through for the docs section of the site?  Right now it's
application specific and not OS specific, so I'm not sure if you want to
keep it in that model.  Either way I'll be documenting it on our work blog.

But, again a huge thanks to all involved in making mongrel and
mongrel_cluster.

Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070214/2c78bf3b/attachment-0001.html 

From zedshaw at zedshaw.com  Wed Feb 14 17:31:11 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 14 Feb 2007 14:31:11 -0800
Subject: [Mongrel] Such a nice setup thanks to mongrel/mongrel_cluster
In-Reply-To: <ef13ff170702141102m74cd7e24pd3b558f4c2709bd6@mail.gmail.com>
References: <ef13ff170702141102m74cd7e24pd3b558f4c2709bd6@mail.gmail.com>
Message-ID: <20070214143111.18a834f3.zedshaw@zedshaw.com>

On Wed, 14 Feb 2007 11:02:55 -0800
"Patrick Berry" <pberry at gmail.com> wrote:

> We're almost done with our migration from Apache+FastCGI to
> Apache+mongrel_cluster.  There have been a few bumps in the road, mostly
> deploy issues that have nothing to do with mongrel (we don't have root
> access on our production server).
> 
> This is for a RedHat Enterprise Linux 4 setup.  Zed, would you want the
> process we went through for the docs section of the site?  Right now it's
> application specific and not OS specific, so I'm not sure if you want to
> keep it in that model.  Either way I'll be documenting it on our work blog.
> 

Yeah, that'd be cool.  There's only OS specific instructions for Debian
and Windows.  Read

http://mongrel.rubyforge.org/docs/contrib.html

To get started making the docs, then e-mail it to me off list and I'll
post it.  Make sure you give yourself a by-line.

-- 
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.

From mental at rydia.net  Wed Feb 14 18:28:47 2007
From: mental at rydia.net (MenTaLguY)
Date: Wed, 14 Feb 2007 18:28:47 -0500
Subject: [Mongrel] [ANN] fastthread-0.6.4.1 released
Message-ID: <1171495727.12960.31.camel@localhost.localdomain>

== NOW

A new version of fastthread, the library providing better
implementations of the classes in thread.rb, has been released.

Please note that fastthread is only for Ruby 1.8, not JRuby or any other
Ruby implementation (most of them don't need it anyway!).

== WHY

The existing implementation of Mutex, Queue, etc. in thread.rb is slow.
  
fastthread's is faster (and bypasses the memory leak in Ruby 1.8's
Array#shift to boot).

This particular release fixes two issues in previous fastthread
releases:

 1) rb_bug()s due to stale wait queue entries

 2) an uninitialized variable warning on load

== HOW

To use fastthread, just require it in addition to 'thread'.  The API is
identical to the existing classes, so you shouldn't need to rewrite any
code (so long as you've been respecting the public interface of those
classes).

I'd recommend rescuing LoadError, to make it optional.  (Remember, not
all Ruby implementations need it!)

== WHERE?

Files are available from Rubyforge:

http://rubyforge.org/frs/shownotes.php?release_id=9709

== THE FUTURE

My hope is that fastthread won't be needed for much longer -- its code
has been merged into ruby_1_8 as a build option (in which case, simply
requiring 'thread' will get you the same stuff!), but there's not been a
fastthread-enabled release yet.

As for alternate Ruby implementations, JRuby already has its own
implementation of the thread.rb primitives which uses native Java
monitors, and I think we can expect other Ruby implementations to follow
its lead.

But, until we get a new fastthread-ized 1.8 release, fastthread is still
here for you.

Cheers,

-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/20070214/fe9bdce2/attachment.bin 

From gmiller at marketcetera.com  Wed Feb 14 19:16:04 2007
From: gmiller at marketcetera.com (Graham Miller)
Date: Wed, 14 Feb 2007 16:16:04 -0800
Subject: [Mongrel] Gem install from script
Message-ID: <96c48fe10702141616x1af4d46p9c11aa710e04f2ee@mail.gmail.com>

Hello all,
Apologies if this is not the right place for this question, but I thought
I'd start here.  We're trying to install the latest Mongrel from inside a
script.  Using 'gem install -v 1.0.1 mongrel' causes a prompt to come up
asking whether to install the "ruby" or "mswin32" variant.

Select which gem to install for your platform (i486-linux)
 1. mongrel 1.0.1 (ruby)
 2. mongrel 1.0.1 (mswin32)
 3. Cancel installation
>

If I don't want to have to write an expect script or something like that, is
there any way to specify on the command line that I want the "ruby" variant
so that I don't get this prompt?

Thanks in advance for any help.

graham


-- 
Marketcetera Trading Platform
download.run.trade.
www.marketcetera.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070214/5096479f/attachment.html 

From wayneeseguin at gmail.com  Wed Feb 14 20:27:16 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Wed, 14 Feb 2007 20:27:16 -0500
Subject: [Mongrel] Gem install from script
In-Reply-To: <96c48fe10702141616x1af4d46p9c11aa710e04f2ee@mail.gmail.com>
References: <96c48fe10702141616x1af4d46p9c11aa710e04f2ee@mail.gmail.com>
Message-ID: <2203438B-685E-4841-B564-FCA20A5DB025@gmail.com>

One possible method is:

echo 1 | gem install mongrel

The downside to this is if it's not always the first one (eg if ruby/ 
win32 can get switched at each next release)

~Wayne

On Feb 14, 2007, at 19:16 , Graham Miller wrote:

> Hello all,
> Apologies if this is not the right place for this question, but I  
> thought I'd start here.  We're trying to install the latest Mongrel  
> from inside a script.  Using 'gem install -v 1.0.1 mongrel' causes  
> a prompt to come up asking whether to install the "ruby" or  
> "mswin32" variant.
>
> Select which gem to install for your platform (i486-linux)
>  1. mongrel 1.0.1 (ruby)
>  2. mongrel 1.0.1 (mswin32)
>  3. Cancel installation
> >
>
> If I don't want to have to write an expect script or something like  
> that, is there any way to specify on the command line that I want  
> the "ruby" variant so that I don't get this prompt?
>
> Thanks in advance for any help.
>
> graham
>
>
> -- 
> Marketcetera Trading Platform
> download.run.trade.
> www.marketcetera.org
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From ben at gimbo.net  Wed Feb 14 20:21:22 2007
From: ben at gimbo.net (Ben Osheroff)
Date: Wed, 14 Feb 2007 17:21:22 -0800
Subject: [Mongrel] mongrel process stopped listening but "phantom thread"
	still going
Message-ID: <45D3B592.1000907@gimbo.net>

Hi,

I run a medium-sized website that uses mongrel/rails in the following
configuration:

-frontend reverse proxy to a cluster of 7 app servers
-each app server runs apache 2.2 with mod_proxy_balancer that balancers
the requests out into a mongrel cluster of 35 servers.
-each mongrel is version 1.0.1

the mongrel cluster config looks like:
port: "1620"
environment: production
address: 127.0.0.1
pid_file: log/mongrel.pid
servers: 35

The problem is, when the mongrel processes are sent a USR2 signal, some
of them seem to have threads running, that are waiting for data on a
socket that's been disconnected from the apache balancer long ago.

process 27457 has been sent a USR2 signal, and is waiting for its thread
to die:

[xxx at app04 config]$ /usr/sbin/lsof | grep 27457
[snip]
ruby      27457  ilike   28u     IPv4 214673805                   TCP
*:49242 (LISTEN)
ruby      27457  ilike   29u     IPv4 214673810                   TCP
app04:49244->10.1.2.10:mysql (ESTABLISHED)
[snip]

Here's the strace of what it's actually doing:

[ilike at app04 config]$ strace -p 27457
Process 27457 attached - interrupt to quit
select(29, [28], [], [], {0, 137000})   = 0 (Timeout)
gettimeofday({1171499150, 914277}, NULL) = 0
select(29, [28], [], [], {0, 175})      = 0 (Timeout)
gettimeofday({1171499150, 915224}, NULL) = 0
select(29, [28], [], [], {0, 0})        = 0 (Timeout)
time(NULL)                              = 1171499150
gettimeofday({1171499150, 915386}, NULL) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
write(2, "Wed Feb 14 16:25:50 PST 2007: Re"..., 86) = 86
write(2, "\n", 1)                       = 1
gettimeofday({1171499150, 915596}, NULL) = 0
write(2, "Waiting for 1 requests to finish"..., 58) = 58

Port 49242 is an irrelevant port - the mongrels listen on ports
1620-1655 (the mongrel in question has closed out its main port).  It
seems that the mongrel is waiting for data on a port that has become
disconnected from the mod_proxy_balancer.

I could probably provide an end-to-end strace if needed, although
picking out the relevant bits could be tough.

-ben



From mongrel_users at homerlex.mailshell.com  Thu Feb 15 07:24:51 2007
From: mongrel_users at homerlex.mailshell.com (mongrel_users at homerlex.mailshell.com)
Date: Thu, 15 Feb 2007 04:24:51 -0800
Subject: [Mongrel] Multiple Processes Spawned from mongrel_rails start ?
Message-ID: <1171542291.45d45113516e5@www.mailshell.com>

Hello,

I have mongrel 1.0.1, rails 1.2.2 ruby 1.8.5 running on Centos 4.4.

When I execute the mongrel_rails start -d I see that 3 processes are spawned.  See below:

[root at ccc aaa]# mongrel_rails start -d
[root at ccc aaa]# ps -def |grep mong
root      2743     1  9 07:14 ?        00:00:01 /usr/bin/ruby /usr/bin/mongrel_rails start -d
root      2744  2743  0 07:14 ?        00:00:00 /usr/bin/ruby /usr/bin/mongrel_rails start -d
root      2745  2744  0 07:14 ?        00:00:00 /usr/bin/ruby /usr/bin/mongrel_rails start -d

Is this normal?

When I had mongrel 0.3.13.3, rails 1.1.0, ruby 1.8.4 on rhel 4 only 1 process would be spawned.

I realize I changed versions of EVERYTHING so I'm wondering if this is now the normal behavior or if something is going wrong.

Regards

_______________________________________________________
The FREE service that prevents junk email http://www.mailshell.com

From mongrel_users at homerlex.mailshell.com  Thu Feb 15 08:31:56 2007
From: mongrel_users at homerlex.mailshell.com (mongrel_users at homerlex.mailshell.com)
Date: Thu, 15 Feb 2007 05:31:56 -0800
Subject: [Mongrel] Anyway to Force a start even if the .pid file exists?
Message-ID: <1171546316.45d460ccd23db@www.mailshell.com>

I'm using monit to restart mongrel processes if they go away.  With mongrel 0.3 I could issue a start command and the process would start up even if the .pid file existed (though a warning would appear).

Now, with mongrel 1.0.1 the warning says I must clear the .pid file and the process is not started.  Is there anyway to force it to start without having to clear the .pid?

Regards



_______________________________________________________
The FREE service that prevents junk email http://www.mailshell.com

From luislavena at gmail.com  Thu Feb 15 09:21:32 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 15 Feb 2007 11:21:32 -0300
Subject: [Mongrel] [ANN] fastthread-0.6.4.1 released
In-Reply-To: <1171495727.12960.31.camel@localhost.localdomain>
References: <1171495727.12960.31.camel@localhost.localdomain>
Message-ID: <71166b3b0702150621k12edd745r4f7e3806f6b61033@mail.gmail.com>

On 2/14/07, MenTaLguY <mental at rydia.net> wrote:
> == NOW
>
> A new version of fastthread, the library providing better
> implementations of the classes in thread.rb, has been released.
>
> Please note that fastthread is only for Ruby 1.8, not JRuby or any other
> Ruby implementation (most of them don't need it anyway!).
>
<snip>
> == WHERE?
>
> Files are available from Rubyforge:
>
> http://rubyforge.org/frs/shownotes.php?release_id=9709

Following MenTaLguY release, I compiled and uploaded to rubyforge
win32 gem of fastthread.

Waiting it spread to all gem mirrors.

Later

-- 
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 cronald at gmail.com  Thu Feb 15 09:31:34 2007
From: cronald at gmail.com (Paul King)
Date: Thu, 15 Feb 2007 14:31:34 +0000
Subject: [Mongrel] Anyway to Force a start even if the .pid file exists?
In-Reply-To: <1171546316.45d460ccd23db@www.mailshell.com>
References: <1171546316.45d460ccd23db@www.mailshell.com>
Message-ID: <2939187c0702150631w5b86e4b5o225e364c86675b5f@mail.gmail.com>

Take a look at http://rubyforge.org/pipermail/mongrel-users/2007-January/002803.html
- I've been using the version referenced without any problems.

- Paul

On 15/02/07, mongrel_users at homerlex.mailshell.com
<mongrel_users at homerlex.mailshell.com> wrote:
> I'm using monit to restart mongrel processes if they go away.  With mongrel 0.3 I could issue a start command and the process would start up even if the .pid file existed (though a warning would appear).
>
> Now, with mongrel 1.0.1 the warning says I must clear the .pid file and the process is not started.  Is there anyway to force it to start without having to clear the .pid?
>
> Regards
>
>
>
> _______________________________________________________
> The FREE service that prevents junk email http://www.mailshell.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From donald.ball at nashville.gov  Thu Feb 15 10:45:20 2007
From: donald.ball at nashville.gov (Ball, Donald A Jr (Library))
Date: Thu, 15 Feb 2007 09:45:20 -0600
Subject: [Mongrel] [ANN] fastthread-0.6.4.1 released
Message-ID: <918A0DD3EFA7F248BFBF447187F8A93214AD94@HOBVSISMS01.nashville.org>

> Following MenTaLguY release, I compiled and uploaded to rubyforge
> win32 gem of fastthread.
> 
> Waiting it spread to all gem mirrors.

Do you recommend using fastthread with mongrel/mongrel_service in
production on win32?

For that matter, I seem to recall you advocating against pen for load
balancing on win32. Do you have an alternate recommendation?

Thanks, and cheers.

- donald

From luislavena at gmail.com  Thu Feb 15 11:06:55 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 15 Feb 2007 13:06:55 -0300
Subject: [Mongrel] [ANN] fastthread-0.6.4.1 released
In-Reply-To: <918A0DD3EFA7F248BFBF447187F8A93214AD94@HOBVSISMS01.nashville.org>
References: <918A0DD3EFA7F248BFBF447187F8A93214AD94@HOBVSISMS01.nashville.org>
Message-ID: <71166b3b0702150806q4d4f575asee5723f62b7fa363@mail.gmail.com>

On 2/15/07, Ball, Donald A Jr (Library) <donald.ball at nashville.gov> wrote:
> > Following MenTaLguY release, I compiled and uploaded to rubyforge
> > win32 gem of fastthread.
> >
> > Waiting it spread to all gem mirrors.
>
> Do you recommend using fastthread with mongrel/mongrel_service in
> production on win32?
>

Yes, since any implementation of ruby 1.8 have the issues described by
MenTaLguY.
(even after several test win32 didn't show leak described months ago by Zed).

I recommend and been using it without troubles.

> For that matter, I seem to recall you advocating against pen for load
> balancing on win32.
>

The problem is cygwin and all the translation/compatibility layer. Pen is *nix.

Even if you see Pen on Windows (http://siag.nu/pen/). You sacrifice
performance due that extra layer around your processes.

> Do you have an alternate recommendation?

No, not yet. Guess until a serious option (without expending thousand
dollars in Windows Server 2003, which have built in support for this),
Pen will be the one.

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 donald.ball at nashville.gov  Thu Feb 15 11:52:04 2007
From: donald.ball at nashville.gov (Ball, Donald A Jr (Library))
Date: Thu, 15 Feb 2007 10:52:04 -0600
Subject: [Mongrel] [ANN] fastthread-0.6.4.1 released
Message-ID: <918A0DD3EFA7F248BFBF447187F8A93214AD96@HOBVSISMS01.nashville.org>

> The problem is cygwin and all the translation/compatibility 
> layer. Pen is *nix.
> 
> Even if you see Pen on Windows (http://siag.nu/pen/). You 
> sacrifice performance due that extra layer around your processes.

Sure, but that performance hit might be worth it if your rails webapp
serves occasional long requests, yes?

> > Do you have an alternate recommendation?
> 
> No, not yet. Guess until a serious option (without expending 
> thousand dollars in Windows Server 2003, which have built in 
> support for this), Pen will be the one.

As it turns out, this is running on win2k3, so that's a possibility for
me. Can you point me towards more documentation on this option? Thanks
muchly.

- donald

From mongrel at philip.pjkh.com  Thu Feb 15 12:24:46 2007
From: mongrel at philip.pjkh.com (Philip Hallstrom)
Date: Thu, 15 Feb 2007 11:24:46 -0600 (CST)
Subject: [Mongrel] Multiple Processes Spawned from mongrel_rails start ?
In-Reply-To: <1171542291.45d45113516e5@www.mailshell.com>
References: <1171542291.45d45113516e5@www.mailshell.com>
Message-ID: <20070215112406.L3035@bravo.pjkh.com>

> I have mongrel 1.0.1, rails 1.2.2 ruby 1.8.5 running on Centos 4.4.
>
> When I execute the mongrel_rails start -d I see that 3 processes are spawned.  See below:
>
> [root at ccc aaa]# mongrel_rails start -d
> [root at ccc aaa]# ps -def |grep mong
> root      2743     1  9 07:14 ?        00:00:01 /usr/bin/ruby /usr/bin/mongrel_rails start -d
> root      2744  2743  0 07:14 ?        00:00:00 /usr/bin/ruby /usr/bin/mongrel_rails start -d
> root      2745  2744  0 07:14 ?        00:00:00 /usr/bin/ruby /usr/bin/mongrel_rails start -d
>
> Is this normal?
>
> When I had mongrel 0.3.13.3, rails 1.1.0, ruby 1.8.4 on rhel 4 only 1 process would be spawned.
>
> I realize I changed versions of EVERYTHING so I'm wondering if this is 
> now the normal behavior or if something is going wrong.
>

Search the list for this issue... I don't remember the particulars other 
than some OS's report three instances via ps even though there really is 
only one running...

-philip

From ben at gimbo.net  Thu Feb 15 16:12:33 2007
From: ben at gimbo.net (Ben Osheroff)
Date: Thu, 15 Feb 2007 13:12:33 -0800
Subject: [Mongrel] PATCH: mongrel/rails auto-restart code
Message-ID: <45D4CCC1.9000302@gimbo.net>

Hey, this is a patch I wrote for mongrel/rails integration that monitors
modification times of the files that Rails has loaded, and when it
detects a change, the mongrel auto-restarts itself using the SIGUSR2
mechanism.

It's not complete (lack of configuration options, documentation, etc.)
but I wanted to float it here to see if this is something mainline would
want to pick up, or if it would be better implemented as a plugin, and
to get comments, etc.

-ben



-------------- next part --------------
A non-text attachment was scrubbed...
Name: mongrel_file_mods.rb
Type: application/x-ruby
Size: 3181 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070215/b428e6d7/attachment.bin 

From roys at okabashi.com  Thu Feb 15 17:01:16 2007
From: roys at okabashi.com (Roy Satterfield)
Date: Thu, 15 Feb 2007 17:01:16 -0500
Subject: [Mongrel] Mongrel Monitoring...
Message-ID: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com>

I have a website that is running Mongrel that is CONSTANTLY going down.

There seems to be no rhyme or reason... There must be something in the
way the site was written.

 

Is there a recommended Mongrel monitoring tool that will monitor our
sites mongrel services and restart mongrel when the site goes down?

The server is a UNIX machine...

 

Thanks!!

Roy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070215/040532c8/attachment.html 

From bassnode at gmail.com  Thu Feb 15 17:35:47 2007
From: bassnode at gmail.com (Ed Hickey)
Date: Thu, 15 Feb 2007 16:35:47 -0600
Subject: [Mongrel] Mongrel Monitoring...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com>
Message-ID: <733f56120702151435k689414abtce3caf11ca260c46@mail.gmail.com>

easy route: monit
http://www.tildeslash.com/monit/doc/platforms.php

complicated route: nagios
http://nagios.org/


ed


On 2/15/07, Roy Satterfield <roys at okabashi.com> wrote:
>
>  I have a website that is running Mongrel that is CONSTANTLY going down.
>
> There seems to be no rhyme or reason? There must be something in the way
> the site was written.
>
>
>
> Is there a recommended Mongrel monitoring tool that will monitor our sites
> mongrel services and restart mongrel when the site goes down?
>
> The server is a UNIX machine?
>
>
>
> Thanks!!
>
> Roy
>
> _______________________________________________
> 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/20070215/a1dcfed2/attachment.html 

From pberry at gmail.com  Thu Feb 15 17:50:51 2007
From: pberry at gmail.com (Patrick Berry)
Date: Thu, 15 Feb 2007 14:50:51 -0800
Subject: [Mongrel] Mongrel Monitoring...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com>
Message-ID: <ef13ff170702151450w12e37d9fied21ca0c25769277@mail.gmail.com>

The archives have a number of solutions, but the most popular seem to be
monit and runit.  I'm sure this is beyond obvious, but fixing the code is
your best bet.

Pat

On 2/15/07, Roy Satterfield <roys at okabashi.com> wrote:
>
>  I have a website that is running Mongrel that is CONSTANTLY going down.
>
> There seems to be no rhyme or reason? There must be something in the way
> the site was written.
>
>
>
> Is there a recommended Mongrel monitoring tool that will monitor our sites
> mongrel services and restart mongrel when the site goes down?
>
> The server is a UNIX machine?
>
>
>
> Thanks!!
>
> Roy
>
> _______________________________________________
> 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/20070215/2d4969fe/attachment.html 

From jgeiger at gmail.com  Thu Feb 15 17:51:46 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Thu, 15 Feb 2007 16:51:46 -0600
Subject: [Mongrel] Mongrel Monitoring...
In-Reply-To: <733f56120702151435k689414abtce3caf11ca260c46@mail.gmail.com>
References: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com>
	<733f56120702151435k689414abtce3caf11ca260c46@mail.gmail.com>
Message-ID: <466af3440702151451i3b8cee75sa33e42040e50d8b9@mail.gmail.com>

correct route:
fix the issue that is causing the crashes.

On 2/15/07, Ed Hickey <bassnode at gmail.com> wrote:
> easy route: monit
> http://www.tildeslash.com/monit/doc/platforms.php
>
> complicated route: nagios
> http://nagios.org/
>
>
> ed
>
>
>
> On 2/15/07, Roy Satterfield <roys at okabashi.com> wrote:
> >
> >
> >
> >
> >
> > I have a website that is running Mongrel that is CONSTANTLY going down.
> >
> > There seems to be no rhyme or reason? There must be something in the way
> the site was written.
> >
> >
> >
> > Is there a recommended Mongrel monitoring tool that will monitor our sites
> mongrel services and restart mongrel when the site goes down?
> >
> > The server is a UNIX machine?
> >
> >
> >
> > Thanks!!
> >
> > Roy
> > _______________________________________________
> > 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 roys at okabashi.com  Thu Feb 15 18:10:23 2007
From: roys at okabashi.com (Roy Satterfield)
Date: Thu, 15 Feb 2007 18:10:23 -0500
Subject: [Mongrel] Mongrel Monitoring...
References: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com><733f56120702151435k689414abtce3caf11ca260c46@mail.gmail.com>
	<466af3440702151451i3b8cee75sa33e42040e50d8b9@mail.gmail.com>
Message-ID: <D6902C3BCB779242B12A83CF4250AE77C8C3AF@okasrv1.okabashi.com>

I would try to fix the issue, but I had this issued dropped in my lap.
I work for a company who hired a contract developer that wrote the site
using Ruby On Rails and we have been battling the site crashing ever
since.
We are going to have our sites rewritten - NOT using Ruby... Sorry guys,
but when running a business critical e-commerce site there has to be
dedicated support and available developers.


-----Original Message-----
From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Joey Geiger
Sent: Thursday, February 15, 2007 5:52 PM
To: mongrel-users at rubyforge.org
Subject: Re: [Mongrel] Mongrel Monitoring...

correct route:
fix the issue that is causing the crashes.

On 2/15/07, Ed Hickey <bassnode at gmail.com> wrote:
> easy route: monit
> http://www.tildeslash.com/monit/doc/platforms.php
>
> complicated route: nagios
> http://nagios.org/
>
>
> ed
>
>
>
> On 2/15/07, Roy Satterfield <roys at okabashi.com> wrote:
> >
> >
> >
> >
> >
> > I have a website that is running Mongrel that is CONSTANTLY going
down.
> >
> > There seems to be no rhyme or reason... There must be something in
the way
> the site was written.
> >
> >
> >
> > Is there a recommended Mongrel monitoring tool that will monitor our
sites
> mongrel services and restart mongrel when the site goes down?
> >
> > The server is a UNIX machine...
> >
> >
> >
> > Thanks!!
> >
> > Roy
> > _______________________________________________
> > 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 zedshaw at zedshaw.com  Thu Feb 15 21:43:45 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 15 Feb 2007 18:43:45 -0800
Subject: [Mongrel] Mongrel Monitoring...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE77C8C3AF@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com>
	<733f56120702151435k689414abtce3caf11ca260c46@mail.gmail.com>
	<466af3440702151451i3b8cee75sa33e42040e50d8b9@mail.gmail.com>
	<D6902C3BCB779242B12A83CF4250AE77C8C3AF@okasrv1.okabashi.com>
Message-ID: <20070215184345.4c1f22fe.zedshaw@zedshaw.com>

On Thu, 15 Feb 2007 18:10:23 -0500
"Roy Satterfield" <roys at okabashi.com> wrote:

> I would try to fix the issue, but I had this issued dropped in my lap.
> I work for a company who hired a contract developer that wrote the site
> using Ruby On Rails and we have been battling the site crashing ever
> since.
> We are going to have our sites rewritten - NOT using Ruby... Sorry guys,
> but when running a business critical e-commerce site there has to be
> dedicated support and available developers.

Probably a good idea if you need dedicated support and a team of
developers on hand at a moment's notice.

If you aren't interested in keeping the source to your old system, I'd
like to have it for analysis.  Feel free to contact me off list if
you're interested.

In exchange, if I can fix it you can have the fixes.

-- 
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.

From gmiller at marketcetera.com  Thu Feb 15 18:44:51 2007
From: gmiller at marketcetera.com (Graham Miller)
Date: Thu, 15 Feb 2007 15:44:51 -0800
Subject: [Mongrel] Gem install from script
Message-ID: <96c48fe10702151544h66e835adu3169db4f1f111fd0@mail.gmail.com>

Thanks, Wayne, but you're right, that seems a little brittle.  Is there any
other way to do this?  I guess one question is that if it knows that I'm on
an "i486-linux" platform, why is it giving me the "mswin32" option in the
first place?

graham



Date: Wed, 14 Feb 2007 20:27:16 -0500
From: "Wayne E. Seguin" <wayneeseguin at gmail.com>
Subject: Re: [Mongrel] Gem install from script
To: mongrel-users at rubyforge.org
Message-ID: <2203438B-685E-4841-B564-FCA20A5DB025 at gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

One possible method is:

echo 1 | gem install mongrel

The downside to this is if it's not always the first one (eg if ruby/
win32 can get switched at each next release)

~Wayne

On Feb 14, 2007, at 19:16 , Graham Miller wrote:

> Hello all,
> Apologies if this is not the right place for this question, but I
> thought I'd start here.  We're trying to install the latest Mongrel
> from inside a script.  Using 'gem install -v 1.0.1 mongrel' causes
> a prompt to come up asking whether to install the "ruby" or
> "mswin32" variant.
>
> Select which gem to install for your platform (i486-linux)
>  1. mongrel 1.0.1 (ruby)
>  2. mongrel 1.0.1 (mswin32)
>  3. Cancel installation
> >
>
> If I don't want to have to write an expect script or something like
> that, is there any way to specify on the command line that I want
> the "ruby" variant so that I don't get this prompt?
>
> Thanks in advance for any help.
>
> graham
>
>
> --
> Marketcetera Trading Platform
> download.run.trade.
> www.marketcetera.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/20070215/fd716ac0/attachment.html 

From josh at besquared.net  Thu Feb 15 19:39:47 2007
From: josh at besquared.net (Josh Ferguson)
Date: Thu, 15 Feb 2007 19:39:47 -0500
Subject: [Mongrel] Mongrel Monitoring...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE77C8C3AF@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com><733f56120702151435k689414abtce3caf11ca260c46@mail.gmail.com>
	<466af3440702151451i3b8cee75sa33e42040e50d8b9@mail.gmail.com>
	<D6902C3BCB779242B12A83CF4250AE77C8C3AF@okasrv1.okabashi.com>
Message-ID: <CA2B1A14-0F06-4BFB-86A3-7F0BB2E0462F@besquared.net>

Oh well now lets be fair, I wrote it and then the company stopped  
returning my calls..:) I'm pretty sure there are available and  
dedicated developers.

As far as the problem goes it's a bit odd because on that machine  
there are two mongel instances running, both being proxied by apache.  
One of the instances runs just a normal RoR application with pretty  
much static views, the other one runs on the radiant CMS. So I didn't  
actually do anything with the radiant one, I just unzipped radiant,  
setup the proxy pass and off it went. I did all the rest in the in- 
browser system. I believe it's the site that is *not* using the CMS  
that is crashing. If that's the case is there any sources other than  
the mongrel logs to look for major problems? Apache and the other  
site remain fine, just mongrel goes down.

Josh
besquared

On Feb 15, 2007, at 6:10 PM, Roy Satterfield wrote:

> I would try to fix the issue, but I had this issued dropped in my lap.
> I work for a company who hired a contract developer that wrote the  
> site
> using Ruby On Rails and we have been battling the site crashing ever
> since.
> We are going to have our sites rewritten - NOT using Ruby... Sorry  
> guys,
> but when running a business critical e-commerce site there has to be
> dedicated support and available developers.
>
>
> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org
> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Joey Geiger
> Sent: Thursday, February 15, 2007 5:52 PM
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] Mongrel Monitoring...
>
> correct route:
> fix the issue that is causing the crashes.
>
> On 2/15/07, Ed Hickey <bassnode at gmail.com> wrote:
>> easy route: monit
>> http://www.tildeslash.com/monit/doc/platforms.php
>>
>> complicated route: nagios
>> http://nagios.org/
>>
>>
>> ed
>>
>>
>>
>> On 2/15/07, Roy Satterfield <roys at okabashi.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>> I have a website that is running Mongrel that is CONSTANTLY going
> down.
>>>
>>> There seems to be no rhyme or reason... There must be something in
> the way
>> the site was written.
>>>
>>>
>>>
>>> Is there a recommended Mongrel monitoring tool that will monitor our
> sites
>> mongrel services and restart mongrel when the site goes down?
>>>
>>> The server is a UNIX machine...
>>>
>>>
>>>
>>> Thanks!!
>>>
>>> Roy
>>> _______________________________________________
>>> 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
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From wayneeseguin at gmail.com  Thu Feb 15 22:03:29 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Thu, 15 Feb 2007 22:03:29 -0500
Subject: [Mongrel] Gem install from script
In-Reply-To: <96c48fe10702151544h66e835adu3169db4f1f111fd0@mail.gmail.com>
References: <96c48fe10702151544h66e835adu3169db4f1f111fd0@mail.gmail.com>
Message-ID: <86BAF615-FEE4-43A1-8186-35D02354A9B0@gmail.com>

Graham,

My understanding is that rubygems (gem) simply pulls a list of  
available gems fitting the described project from rubyforge (or the  
supplied source url). Both *nix and Windows gems are released here  
and hence they are showing up on the prompt.

You can see this here:
	http://rubyforge.org/frs/?group_id=1306&release_id=9190

or here: (where I get my releases from, I hope it's the "correct" one :)
	http://mongrel.rubyforge.org/releases/gems/

I do agree that it *should* detect the platform if it can and have a  
mechanism for choosing based on that. I don't believe that they've  
come to an agreement on the best way to do this, however you should  
research this issue yourself as I'm not completely familiar with the  
discussion track.

Here's another option:

Use either "curl -O" or "wget" to download a specific mongrel gem,  
then install it (Mac OS X comes with curl, Linux comes with one or  
the other or both based on the distro).

 > wget http://mongrel.rubyforge.org/releases/gems/mongrel-1.0.1.gem
 > gem install mongrel-1.0.1.gem

(Note: If this isn't being run as root, put a sudo in front of the  
gem install)

I prefer this method for dynamic systems as I can specify the version  
in installation / setup scripts and not have to worry about using the  
echo or other such tricks and it going awry.
Anther benefit is that you can serve the gems yourself internally so  
that you monitor which ones get "released" to your systems and  
check / test the code before pushing a new version.

Of course it has a downside, you have to manually update when new  
versions come out.
That said, shouldn't we be monitoring these and evaluating whether or  
not upgrades should occur based on the changelogs and personal  
testing etc...?
So... it should not be much of an issue, especially considering you  
were basically attempting this to begin with ;)

Ok... I'm rambling. Does this method help to accomplish your goals?

~Wayne

On Feb 15, 2007, at 18:44 , Graham Miller wrote:

> Thanks, Wayne, but you're right, that seems a little brittle.  Is  
> there any other way to do this?  I guess one question is that if it  
> knows that I'm on an "i486-linux" platform, why is it giving me the  
> "mswin32" option in the first place?
>
> graham
>
>
>
> Date: Wed, 14 Feb 2007 20:27:16 -0500
> From: "Wayne E. Seguin" <wayneeseguin at gmail.com >
> Subject: Re: [Mongrel] Gem install from script
> To: mongrel-users at rubyforge.org
> Message-ID: < 2203438B-685E-4841-B564-FCA20A5DB025 at gmail.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> One possible method is:
>
> echo 1 | gem install mongrel
>
> The downside to this is if it's not always the first one (eg if ruby/
> win32 can get switched at each next release)
>
> ~Wayne
>
> On Feb 14, 2007, at 19:16 , Graham Miller wrote:
>
> > Hello all,
> > Apologies if this is not the right place for this question, but I
> > thought I'd start here.  We're trying to install the latest Mongrel
> > from inside a script.  Using 'gem install -v 1.0.1 mongrel' causes
> > a prompt to come up asking whether to install the "ruby" or
> > "mswin32" variant.
> >
> > Select which gem to install for your platform (i486-linux)
> >  1. mongrel 1.0.1 (ruby)
> >  2. mongrel 1.0.1 (mswin32)
> >  3. Cancel installation
> > >
> >
> > If I don't want to have to write an expect script or something like
> > that, is there any way to specify on the command line that I want
> > the "ruby" variant so that I don't get this prompt?
> >
> > Thanks in advance for any help.
> >
> > graham
> >
> >
> > --
> > Marketcetera Trading Platform
> > download.run.trade .
> > www.marketcetera.org
> > ______________________________
> _________________
> > 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 joevandyk at gmail.com  Thu Feb 15 22:22:11 2007
From: joevandyk at gmail.com (Joe Van Dyk)
Date: Thu, 15 Feb 2007 19:22:11 -0800
Subject: [Mongrel] static file serving
Message-ID: <c715e640702151922i3b268c20n3aff9d3648c8cfb6@mail.gmail.com>

Hi,

I've got 40 mongrels running across 4 machines with a hardware load
balancer as a proxy.  The mongrels serve everything, even files.

How screwed am I if I have a 2MB file on my site?  Say 40 people are
downloading that file.  Are the mongrels completely locked up?

Joe

From ezmobius at gmail.com  Thu Feb 15 23:02:24 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Thu, 15 Feb 2007 20:02:24 -0800
Subject: [Mongrel] static file serving
In-Reply-To: <c715e640702151922i3b268c20n3aff9d3648c8cfb6@mail.gmail.com>
References: <c715e640702151922i3b268c20n3aff9d3648c8cfb6@mail.gmail.com>
Message-ID: <182AF2D7-54CD-4055-BD62-BDCC924FE42B@brainspl.at>


On Feb 15, 2007, at 7:22 PM, Joe Van Dyk wrote:

> Hi,
>
> I've got 40 mongrels running across 4 machines with a hardware load
> balancer as a proxy.  The mongrels serve everything, even files.
>
> How screwed am I if I have a 2MB file on my site?  Say 40 people are
> downloading that file.  Are the mongrels completely locked up?
>
> Joe
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


	Joe, Mongrel serves static files outside of the mutex lock, this  
means one mongrel can serve concurrent static files. If you are  
sending a file with send_file or send_data it might be a problem, but  
if it's just all the static assets of your site then it will be fine  
if 40 people download the file at once you will still be able to  
serve traffic.

	However it is horribly ineficient to serve static files with  
mongrel, since your mongrels will be working hard at serving static  
files at the same time they serve dynamic content. I think you should  
probably run one static file webserver on one of your boxes and use  
rails asset_host feature to send static content to a static server.  
Or you could ask for rewrite rules to be put in place on the load  
balancer to rewrite anything with /images/, /stylesheets/ and / 
javascripts/ in the url to be served by the static asset server.


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



From zedshaw at zedshaw.com  Fri Feb 16 04:03:15 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 16 Feb 2007 01:03:15 -0800
Subject: [Mongrel] Multiple Processes Spawned from mongrel_rails start ?
In-Reply-To: <1171542291.45d45113516e5@www.mailshell.com>
References: <1171542291.45d45113516e5@www.mailshell.com>
Message-ID: <20070216010315.0ed32ad5.zedshaw@zedshaw.com>

On Thu, 15 Feb 2007 04:24:51 -0800
<mongrel_users at homerlex.mailshell.com> wrote:

> Hello,
> 
> I have mongrel 1.0.1, rails 1.2.2 ruby 1.8.5 running on Centos 4.4.
> 
> When I execute the mongrel_rails start -d I see that 3 processes are spawned.  See below:
> 
> [root at ccc aaa]# mongrel_rails start -d
> [root at ccc aaa]# ps -def |grep mong
> root      2743     1  9 07:14 ?        00:00:01 /usr/bin/ruby /usr/bin/mongrel_rails start -d
> root      2744  2743  0 07:14 ?        00:00:00 /usr/bin/ruby /usr/bin/mongrel_rails start -d
> root      2745  2744  0 07:14 ?        00:00:00 /usr/bin/ruby /usr/bin/mongrel_rails start -d

Yep, some operating systems seem to list one process as many and I'm
not sure why.  Here's the ps from my archlinux setup:

zedshaw at gigantor ~/p/testapp> mongrel_rails start -d
zedshaw at gigantor ~/p/testapp> ps ax | grep mongrel_rails
19605 ?        Sl     0:01 /usr/bin/ruby /usr/bin/mongrel_rails start -d
19641 pts/0    S+     0:00 grep mongrel_rails
zedshaw at gigantor ~/p/testapp> 

So, it's just how the ps or process stuff works on that particular
flavor.

-- 
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.

From zedshaw at zedshaw.com  Fri Feb 16 04:04:36 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 16 Feb 2007 01:04:36 -0800
Subject: [Mongrel] mongrel process stopped listening but "phantom
 thread" still going
In-Reply-To: <45D3B592.1000907@gimbo.net>
References: <45D3B592.1000907@gimbo.net>
Message-ID: <20070216010436.fe1acad9.zedshaw@zedshaw.com>

On Wed, 14 Feb 2007 17:21:22 -0800
Ben Osheroff <ben at gimbo.net> wrote:

> Hi,
> 
> I run a medium-sized website that uses mongrel/rails in the following
> configuration:
> 
> The problem is, when the mongrel processes are sent a USR2 signal, some
> of them seem to have threads running, that are waiting for data on a
> socket that's been disconnected from the apache balancer long ago.

USR2 restarting isn't reliable for many reasons outside of Mongrel.
You should just do a full stop and full restart.

-- 
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.

From zedshaw at zedshaw.com  Fri Feb 16 04:55:35 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 16 Feb 2007 01:55:35 -0800
Subject: [Mongrel] mongrel cluster and local gems loading problem
In-Reply-To: <45CB3978.1030202@ruilopes.com>
References: <45CB3978.1030202@ruilopes.com>
Message-ID: <20070216015535.d8702a08.zedshaw@zedshaw.com>

On Thu, 08 Feb 2007 14:53:44 +0000
Rui Lopes <rgl at ruilopes.com> wrote:

> Hello,
> 
> I'm trying to augment the GEM_PATH to load gems from ~/.gem/ using this
> at the begging of the rails application config/environment.rb file:
> 
>   ENV['GEM_PATH'] = File.expand_path('~/.gem')

Hey Rui, I know you were chatting with me on IRC about this.  Did you
ever find a solution?

-- 
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.

From zedshaw at zedshaw.com  Fri Feb 16 04:58:11 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 16 Feb 2007 01:58:11 -0800
Subject: [Mongrel] Apache+Mongrel Redirection Problems
In-Reply-To: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>
References: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>
Message-ID: <20070216015811.90ed7a5c.zedshaw@zedshaw.com>

On Wed, 7 Feb 2007 08:53:47 -1000
"Stan Baptista" <stan.baptista at gmail.com> wrote:

> Hi folks,
> 
> Newbie issues...I'm prototying an Apache/Mongrel configuration setup
> as follows:
> 
> * Two Mongrel servers each serving a Rails application.
> * Apache front-end.
> * Linux system (CentOS)
> * The plan is to create two virtual hosts.

Did you get this resolved Stan?

-- 
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.

From zedshaw at zedshaw.com  Fri Feb 16 04:59:37 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 16 Feb 2007 01:59:37 -0800
Subject: [Mongrel] mongrel_in_a_tunnel
In-Reply-To: <4596E0D4-888B-44D3-B721-EF10B555E01E@oxdi.eu>
References: <4596E0D4-888B-44D3-B721-EF10B555E01E@oxdi.eu>
Message-ID: <20070216015937.26115a35.zedshaw@zedshaw.com>

On Wed, 7 Feb 2007 09:35:14 +0000
Chris Farmiloe <chris at oxdi.eu> wrote:

> 
> 
> Hi list:
> 
> I started to make a quick GemPlugin command [ssl::start] that sets up  
> an stunnel before calling the normal [start] command.
> 
> so
> 
> $ mongrel_rails ssl:start
> 
> will do everything that start normally does and configure/setup an  
> stunnel.

Hey Chris, this is kind of nice since some folks want an ultra small
setup.

Have you looked at just using the openssl support in Ruby?  Would be
nice if I could continue being lazy and just let you solve 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/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

From zedshaw at zedshaw.com  Fri Feb 16 05:02:16 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Fri, 16 Feb 2007 02:02:16 -0800
Subject: [Mongrel] Auto-installing Gems via boot.rb causes errors under
 Mongrel
In-Reply-To: <e3af97510702062300v4c7b8a63v268cc1d4700ae936@mail.gmail.com>
References: <e3af97510702062300v4c7b8a63v268cc1d4700ae936@mail.gmail.com>
Message-ID: <20070216020216.2b1218eb.zedshaw@zedshaw.com>

On Wed, 7 Feb 2007 00:00:29 -0700
"Chad Woolley" <thewoolleyman at gmail.com> wrote:

> Hi,
> 
> I'm trying to make my Rails app auto-install my required gems, by
> invoking the gem installation in boot.rb.  I'll use the ActionMailer
> gem as an example:

Did you ever figure this out Chad?  My thinking is that if there's
anything messing up gems it'd be GemPlugins.  The easiest way to test
that is open up mongrel_rails, go to the bottom where GemPlugin is run,
and then put that into the webrick script real quick.

If that then blows up webrick then that's the cause.  Otherwise, it
might be some kind of race condition that isn't hit because webrick is
slower.

-- 
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.

From chris at oxdi.eu  Fri Feb 16 07:53:47 2007
From: chris at oxdi.eu (Chris Farmiloe)
Date: Fri, 16 Feb 2007 12:53:47 +0000
Subject: [Mongrel] mongrel_in_a_tunnel
In-Reply-To: <20070216015937.26115a35.zedshaw@zedshaw.com>
References: <4596E0D4-888B-44D3-B721-EF10B555E01E@oxdi.eu>
	<20070216015937.26115a35.zedshaw@zedshaw.com>
Message-ID: <944AE81D-24DF-4DDE-B4A0-A2B5AB55A659@oxdi.eu>



I did skim over the OpenSSL library ... I've got fruit with more  
documentation than the OpenSSL stdlib... but that said it does  
interest me, and it would be a better solution long term to have a  
nice SSL plugin for the little scamp.


if anyone's on OSX and want's the "mongrel_rails ssl::start " command  
for stunnel

http://www.chrisfarms.com/2007/2/12/mongrel_in_a_tunnel-the- 
accidental-release



Regards.

Chris Farmiloe
Design & Development


Oxygen
Brighton, BN2 1ED


+44 1273 608708
http://www.oxdi.eu
http://www.chirsfarms.com



On 16 Feb 2007, at 09:59, Zed A. Shaw wrote:

> On Wed, 7 Feb 2007 09:35:14 +0000
> Chris Farmiloe <chris at oxdi.eu> wrote:
>
>>
>>
>> Hi list:
>>
>> I started to make a quick GemPlugin command [ssl::start] that sets up
>> an stunnel before calling the normal [start] command.
>>
>> so
>>
>> $ mongrel_rails ssl:start
>>
>> will do everything that start normally does and configure/setup an
>> stunnel.
>
> Hey Chris, this is kind of nice since some folks want an ultra small
> setup.
>
> Have you looked at just using the openssl support in Ruby?  Would be
> nice if I could continue being lazy and just let you solve 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/
> 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/20070216/96056ff7/attachment.html 

From bradley at railsmachine.com  Fri Feb 16 08:34:29 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Fri, 16 Feb 2007 08:34:29 -0500
Subject: [Mongrel] Mongrel Monitoring...
In-Reply-To: <CA2B1A14-0F06-4BFB-86A3-7F0BB2E0462F@besquared.net>
References: <D6902C3BCB779242B12A83CF4250AE77C8C3AC@okasrv1.okabashi.com><733f56120702151435k689414abtce3caf11ca260c46@mail.gmail.com>	<466af3440702151451i3b8cee75sa33e42040e50d8b9@mail.gmail.com>	<D6902C3BCB779242B12A83CF4250AE77C8C3AF@okasrv1.okabashi.com>
	<CA2B1A14-0F06-4BFB-86A3-7F0BB2E0462F@besquared.net>
Message-ID: <45D5B2E5.6010107@railsmachine.com>

Josh Ferguson wrote:
> If that's the case is there any sources other than  
> the mongrel logs to look for major problems? Apache and the other  
> site remain fine, just mongrel goes down.

Does the mongrel.log show a segfault?

Is this running on a Xen VPS? If so, check /var/log/messages to see if 
that pesky oom-killer is taking out the mongrels due to an out of memory 
condition.


Bradley

From jgeiger at gmail.com  Fri Feb 16 09:42:17 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Fri, 16 Feb 2007 08:42:17 -0600
Subject: [Mongrel] Mongrel upload progress and models with other fields
Message-ID: <466af3440702160642x2d68d7dbhf59ecd9a7db6b986@mail.gmail.com>

I'm trying to set up a system that will allow users to upload files
using the mongrel upload progress gem to a model that includes other
information.

While I'm willing to hack around with this myself for a while to get
it working, I was hoping that someone had done this before and might
be able to give me some hints/code to look at.


My mediafile has a description, mediatype, filename, size,
content_type and data field. (Yes I'm storing it in the db, but I will
also save it on the drive to serve).

Essentially I'm using the upload example but I added in a couple of
fields into the code. I think among the issues I'm running into is
that the mongrel handler is catching the file before the active record
validations are hit, and thus will still upload the file, even though
the description is blank. The other problem is that if there is an
error, or it finishes correctly, it's sending the response back to the
iframe. I'm not using rjs/js for the response at the moment, as I'm
trying to use the rails AR error handlers for a consistent look.

The other question I have is how or where the best place to start the
drb service "ruby lib/upload.rb" so I don't have to do it by hand. Is
this something monit could handle, since I'm using monit to start up
my mongrel cluster, or can I drop that code into one of the config
files?

Thanks.

From wes.sheldahl at gmail.com  Fri Feb 16 09:51:49 2007
From: wes.sheldahl at gmail.com (Wes Sheldahl)
Date: Fri, 16 Feb 2007 09:51:49 -0500
Subject: [Mongrel] mongrel_cluster clarification
In-Reply-To: <3a2de0cd0702092239i1e920cd1u1df667c4a5f13d05@mail.gmail.com>
References: <ef13ff170702091437n7954fd81ta187aafb06edae48@mail.gmail.com>
	<D4D5A4C7-0601-4FF8-A832-88DA7B491627@joyent.com>
	<ef13ff170702091527t6242051cteb612b05fb98e2ca@mail.gmail.com>
	<45CD1C55.608@comcast.net>
	<3a2de0cd0702092239i1e920cd1u1df667c4a5f13d05@mail.gmail.com>
Message-ID: <c0a118d70702160651y534080afv676addbeefef7ced@mail.gmail.com>

Looks like a nice idea. One thing I wonder, just looking at it, is if it
wouldn't redirect to all the configured ports, even if the mongrel on one of
those ports had died. I'm pretty sure the load balancer in apache 2.2 would
be smart enough to not forward to a port that stopped responding, but it
looks like this would continue doing so. Can anyone confirm this?

Of course, you could work around this limitation by using monit or something
similar to make sure that all the mongrels that are supposed to be running,
get restarted if they ever need to be. Just something to keep in mind.

--
Wes Sheldahl
wes.sheldahl at gmail.com

On 2/10/07, Charles Brian Quinn <me at seebq.com> wrote:
>
> Hey alright, nice and simple, can anyone else confirm this works decently?
>
> If so, I'll toss it up on the Apache documents on mongrel.rubyforge.org...
> .
>
> On 2/9/07, Steven Hansen <codeturkey at comcast.net> wrote:
> >
> > >
> > >     How are you going to put more than one mongrel behind Apache 2.0?
> > >
> >
> > In case anyone is interested, I ran into this article the other day that
> > shows how you can run multiple mongrels behind apache 2.0
> >
> > http://times.usefulinc.com/2006/09/13-mongrel-apache20
> >
> > Regards,
> > Steven
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
>
> --
> Charles Brian Quinn
> self-promotion: www.seebq.com
> highgroove studios: www.highgroove.com
> slingshot hosting: www.slingshothosting.com
> main: 678.389.9462  fax: 678.826.0969
>
> Ruby on Rails Bootcamp at the Big Nerd Ranch
> Intensive Ruby on Rails Training:
> http://www.bignerdranch.com/classes/ruby.shtml
> _______________________________________________
> 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/20070216/f11adf53/attachment.html 

From stan.baptista at gmail.com  Fri Feb 16 14:50:05 2007
From: stan.baptista at gmail.com (Stan Baptista)
Date: Fri, 16 Feb 2007 09:50:05 -1000
Subject: [Mongrel] Apache+Mongrel Redirection Problems
In-Reply-To: <20070216015811.90ed7a5c.zedshaw@zedshaw.com>
References: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>
	<20070216015811.90ed7a5c.zedshaw@zedshaw.com>
Message-ID: <2ba0f72b0702161150u1f65544cn276f7f9377e70606@mail.gmail.com>

> Did you get this resolved Stan?

Yes, thanks. Basically a misunderstanding on my part about how VirtualHost
directives work in the Apache httpd.conf file. I meant to post the
solution because I'm curious as to whether I came up with the best approach.
But it will have to wait until next week when I'm back in the office and
have access to the Linux system (4-day weekend:-)

I also discovered that the CSS styles aren't rendering in the Rails app
being served by Mongrel. I strongly suspect it's a ReverseProxy setup issue.
I'm a little hesitant to bring this up here since I don't think it's a
Mongrel problem. But I'll post some of the code and if it seems too OT, let
me know.

-Stan

> Newbie issues...I'm prototying an Apache/Mongrel configuration setup
> as follows:
>
> * Two Mongrel servers each serving a Rails application.
> * Apache front-end.
> * Linux system (CentOS)
> * The plan is to create two virtual hosts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070216/92ba3247/attachment.html 

From pberry at gmail.com  Sat Feb 17 11:40:48 2007
From: pberry at gmail.com (Patrick Berry)
Date: Sat, 17 Feb 2007 08:40:48 -0800
Subject: [Mongrel] mongrel_cluster clarification
In-Reply-To: <c0a118d70702160651y534080afv676addbeefef7ced@mail.gmail.com>
References: <ef13ff170702091437n7954fd81ta187aafb06edae48@mail.gmail.com>
	<D4D5A4C7-0601-4FF8-A832-88DA7B491627@joyent.com>
	<ef13ff170702091527t6242051cteb612b05fb98e2ca@mail.gmail.com>
	<45CD1C55.608@comcast.net>
	<3a2de0cd0702092239i1e920cd1u1df667c4a5f13d05@mail.gmail.com>
	<c0a118d70702160651y534080afv676addbeefef7ced@mail.gmail.com>
Message-ID: <ef13ff170702170840q5798f8e2t5428b228dc861a4e@mail.gmail.com>

I have to admit I'm a tiny bit worried about this, and I'm eagerly
awaiting our migration to RHEL 5 (if it ever comes out...).  One thing
that I think will help is that part of our log rotation is to restart
the cluster at night.  A nightly cluster restart might not be an
acceptable option for everyone though.  Sometimes working in higher-ed
has advantages...

On 2/16/07, Wes Sheldahl <wes.sheldahl at gmail.com> wrote:
> Looks like a nice idea. One thing I wonder, just looking at it, is if it
> wouldn't redirect to all the configured ports, even if the mongrel on one of
> those ports had died. I'm pretty sure the load balancer in apache 2.2 would
> be smart enough to not forward to a port that stopped responding, but it
> looks like this would continue doing so. Can anyone confirm this?
>
> Of course, you could work around this limitation by using monit or something
> similar to make sure that all the mongrels that are supposed to be running,
> get restarted if they ever need to be. Just something to keep in mind.
>
> --
> Wes Sheldahl
> wes.sheldahl at gmail.com
>
>
> On 2/10/07, Charles Brian Quinn < me at seebq.com> wrote:
> > Hey alright, nice and simple, can anyone else confirm this works decently?
> >
> > If so, I'll toss it up on the Apache documents on
> mongrel.rubyforge.org....
> >
> > On 2/9/07, Steven Hansen <codeturkey at comcast.net> wrote:
> > >
> > > >
> > > >     How are you going to put more than one mongrel behind Apache 2.0?
> > > >
> > >
> > > In case anyone is interested, I ran into this article the other day that
> > > shows how you can run multiple mongrels behind apache 2.0
> > >
> > > http://times.usefulinc.com/2006/09/13-mongrel-apache20
> > >
> > > Regards,
> > > Steven
> > > _______________________________________________
> > > Mongrel-users mailing list
> > > Mongrel-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/mongrel-users
> > >
> >
> >
> > --
> > Charles Brian Quinn
> > self-promotion: www.seebq.com
> > highgroove studios: www.highgroove.com
> > slingshot hosting: www.slingshothosting.com
> > main: 678.389.9462  fax: 678.826.0969
> >
> > Ruby on Rails Bootcamp at the Big Nerd Ranch
> > Intensive Ruby on Rails Training:
> > http://www.bignerdranch.com/classes/ruby.shtml
> > _______________________________________________
> > 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 luke at madstop.com  Sun Feb 18 15:46:36 2007
From: luke at madstop.com (Luke Kanies)
Date: Sun, 18 Feb 2007 14:46:36 -0600
Subject: [Mongrel] Passing XMLRPC errors on to clients
Message-ID: <AE82C02F-053E-47A5-A457-376F480B30F2@madstop.com>

Hi,

I'm experimenting with using Mongrel to serve XMLRPC, and I'm having  
trouble passing the XMLRPC errors on to the client.

In my webrick implementation, I just raise the XMLRPC error and the  
client receives it and can handle it like a normal exception.  With  
Mongrel, when I raise the error, Mongrel catches it and just closes  
the client connection, which means the client gets a very  
uninformative EOF instead of a useful error message.

Has anyone on the list found a way to effectively pass the error on  
to the client?  If not, can someone recommend a place for me to start  
looking at how to do it?

It looks like I could try overriding the 'process_client' method in  
the HttpServer class, but I'd still need to know how to convert the  
error into a valid XMLRPC error, which somehow the webrick stuff just  
does for me.  Clearly this might be a necessity, but I'm hoping I can  
leave the error handling to the libraries instead of doing it myself.

If anyone is interested in how I'm doing it right now, you can check  
the source of the mongrel class I've written[1] and the xmlrpc_server  
class[2].  I'm not going to say any of this code is "good", but I've  
seen a dearth of examples and I'm doing what I can.

Any help is muchly appreciated.

1 - https://reductivelabs.com/trac/puppet/browser/branches/ 
webserver_portability/lib/puppet/network/server/mongrel.rb
2 - https://reductivelabs.com/trac/puppet/browser/branches/ 
webserver_portability/lib/puppet/network/xmlrpc_server.rb

  --
  Sometimes I think we're alone. Sometimes I think we're not. In
  either case, the thought is staggering.   --R. Buckminster Fuller
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com



From zedshaw at zedshaw.com  Sun Feb 18 21:46:14 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Sun, 18 Feb 2007 18:46:14 -0800
Subject: [Mongrel] Passing XMLRPC errors on to clients
In-Reply-To: <AE82C02F-053E-47A5-A457-376F480B30F2@madstop.com>
References: <AE82C02F-053E-47A5-A457-376F480B30F2@madstop.com>
Message-ID: <20070218184614.7c381333.zedshaw@zedshaw.com>

On Sun, 18 Feb 2007 14:46:36 -0600
Luke Kanies <luke at madstop.com> wrote:

> Hi,
> 
> I'm experimenting with using Mongrel to serve XMLRPC, and I'm having  
> trouble passing the XMLRPC errors on to the client.
> 
> In my webrick implementation, I just raise the XMLRPC error and the  
> client receives it and can handle it like a normal exception.  With  
> Mongrel, when I raise the error, Mongrel catches it and just closes  
> the client connection, which means the client gets a very  
> uninformative EOF instead of a useful error message.

The contract a handler has with Mongrel is the handler must handle
*all* exceptions.  If any are leaked to Mongrel it's bad news and the
connection is closed.  Period.

If you look at your webrick code you've got several places where you
catch the exceptions you want, but none of this code in the Mongrel
version.

Since XMLRPC requires that exceptions be translated into an XML fault
format, you'll have to write that.  Mongrel can't do it.

Hope that helps.

-- 
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.

From work at ashleymoran.me.uk  Mon Feb 19 05:27:13 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Mon, 19 Feb 2007 10:27:13 +0000
Subject: [Mongrel] Mongrel on FreeBSD
Message-ID: <1E47358C-A11D-446D-BFF0-16B96A523E8C@ashleymoran.me.uk>

Hi

We have mongrel 0.3.4 (off the top of my head) on two FreeBSD  
webservers, installed it out of ports.  The rc script has been  
installed.  Is this done by the port, or does the gem do it?  We want  
to upgrade to mongrel 1.0.1 - are there any changes to the rc  
script?  I'm not sure if upgrading through gems will leave the rc  
script broken in any way.

Unfortunately there's no maintainer for the port right now, which is  
a shame.  I was really pleased to see the rc script being added.

Thanks
Ashley

From jw at innerewut.de  Mon Feb 19 06:38:25 2007
From: jw at innerewut.de (Jonathan Weiss)
Date: Mon, 19 Feb 2007 12:38:25 +0100
Subject: [Mongrel] Mongrel on FreeBSD
In-Reply-To: <1E47358C-A11D-446D-BFF0-16B96A523E8C@ashleymoran.me.uk>
References: <1E47358C-A11D-446D-BFF0-16B96A523E8C@ashleymoran.me.uk>
Message-ID: <45D98C31.8030802@innerewut.de>

Cheers,

Ashley Moran wrote:
> Hi
> 
> We have mongrel 0.3.4 (off the top of my head) on two FreeBSD  
> webservers, installed it out of ports.  The rc script has been  
> installed.  Is this done by the port, or does the gem do it?  We want  
> to upgrade to mongrel 1.0.1 - are there any changes to the rc  
> script?  I'm not sure if upgrading through gems will leave the rc  
> script broken in any way.
> 

Upgrading through the gems will leave the old gem (installed through the 
ports) in place as gems can co-exist.

> Unfortunately there's no maintainer for the port right now, which is  
> a shame.  I was really pleased to see the rc script being added.
> 

I do not know why the maintainer droped it. But I will ask him and if he 
does not want it anymore, I will update the port.

> Thanks
> Ashley

Regards,
Jonathan


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

From work at ashleymoran.me.uk  Mon Feb 19 08:48:40 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Mon, 19 Feb 2007 13:48:40 +0000
Subject: [Mongrel] Mongrel on FreeBSD
In-Reply-To: <45D98C31.8030802@innerewut.de>
References: <1E47358C-A11D-446D-BFF0-16B96A523E8C@ashleymoran.me.uk>
	<45D98C31.8030802@innerewut.de>
Message-ID: <78B5CA72-3224-4350-87E3-17033476D71A@ashleymoran.me.uk>


On 19 Feb 2007, at 11:38, Jonathan Weiss wrote:

>
> I do not know why the maintainer droped it. But I will ask him and  
> if he
> does not want it anymore, I will update the port.

Hi Jonathan

That would be great!  I've never modified a port before so would  
probably take me a while to do it myself.

Thanks
Ashley


From msoulier at digitaltorque.ca  Mon Feb 19 08:51:00 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Mon, 19 Feb 2007 08:51:00 -0500
Subject: [Mongrel] Mongrel on FreeBSD
In-Reply-To: <1E47358C-A11D-446D-BFF0-16B96A523E8C@ashleymoran.me.uk>
References: <1E47358C-A11D-446D-BFF0-16B96A523E8C@ashleymoran.me.uk>
Message-ID: <20070219135059.GH14947@tigger.digitaltorque.ca>

On 19/02/07 Ashley Moran said:

> We have mongrel 0.3.4 (off the top of my head) on two FreeBSD  
> webservers, installed it out of ports.  The rc script has been  
> installed.  Is this done by the port, or does the gem do it?  We want  
> to upgrade to mongrel 1.0.1 - are there any changes to the rc  
> script?  I'm not sure if upgrading through gems will leave the rc  
> script broken in any way.
> 
> Unfortunately there's no maintainer for the port right now, which is  
> a shame.  I was really pleased to see the rc script being added.

Personally, I use runit on freebsd to supervise mongrel. Works great. 

Mike
-- 
Michael P. Soulier <msoulier at digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070219/9ced30a4/attachment.bin 

From peter.boling at gmail.com  Tue Feb 20 14:04:56 2007
From: peter.boling at gmail.com (Peter Boling)
Date: Tue, 20 Feb 2007 14:04:56 -0500
Subject: [Mongrel] service::start borken
Message-ID: <50bd2f960702201104m1ce32595ga17651e997f53e88@mail.gmail.com>

Hello Mongrel Users!

This is my first post!

Is there an expected release date for the fixed version of
mongrel_service that will resolve the missing service::start command?
I would love to use the much improved features of the new
mongrel_service, but I haven't been able to yet.  I haven't figured
out how to follow Zed's advice on a previous thread to just use the
start command to start the service.  Does anyone know if there is a
way to get a mongrel service started using the most recent release of
mongrel_service?

Thanks!

-- 
(**********************************************************
* l*eter H. l3oling
* Web Application Designer - PanEther, LLC
* email:      peter.boling at gmail.com
* blog:        http://galtzo.blogspot.com/
* languages:  English, Spanish, Portuguese
***********************************************************)

From donald.ball at nashville.gov  Tue Feb 20 14:26:41 2007
From: donald.ball at nashville.gov (Ball, Donald A Jr (Library))
Date: Tue, 20 Feb 2007 13:26:41 -0600
Subject: [Mongrel] service::start borken
Message-ID: <918A0DD3EFA7F248BFBF447187F8A93214ADA3@HOBVSISMS01.nashville.org>

> Is there an expected release date for the fixed version of 
> mongrel_service that will resolve the missing service::start command?
> I would love to use the much improved features of the new 
> mongrel_service, but I haven't been able to yet.  I haven't 
> figured out how to follow Zed's advice on a previous thread 
> to just use the start command to start the service.  Does 
> anyone know if there is a way to get a mongrel service 
> started using the most recent release of mongrel_service?

net start "servicename" works just fine for me.

- donald

From luislavena at gmail.com  Tue Feb 20 14:43:38 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 20 Feb 2007 16:43:38 -0300
Subject: [Mongrel] service::start borken
In-Reply-To: <50bd2f960702201104m1ce32595ga17651e997f53e88@mail.gmail.com>
References: <50bd2f960702201104m1ce32595ga17651e997f53e88@mail.gmail.com>
Message-ID: <71166b3b0702201143o2b8f6489rf6b391208528f810@mail.gmail.com>

On 2/20/07, Peter Boling <peter.boling at gmail.com> wrote:
> Hello Mongrel Users!
>
> This is my first post!
>

hello Peter, welcome to the list.

> Is there an expected release date for the fixed version of
> mongrel_service that will resolve the missing service::start command?

No, it wouldn't. ::start and ::stop commands where removed since they
duplicate simple functionality found built in windows.

The same you achieve calling mongrel_rails service::start -N myservice
could be done with just 3 words at the command line:

net start myservice

Doing a simple comparison:

"mongrel_rails service::start -N myservice".length
=> 41
"net start myservice".length
=> 19

Guess which one wins? This is also valid for stop (4 letters).

> I would love to use the much improved features of the new
> mongrel_service, but I haven't been able to yet.

Why? you only need to remove and then reinstall the service (::remove
and then ::install again).

> I haven't figured out how to follow Zed's advice on a previous thread to just use the
> start command to start the service.  Does anyone know if there is a
> way to get a mongrel service started using the most recent release of
> mongrel_service?
>

Just use: net start myservice, net stop myservice (being 'myservice'
the actual service you provided with -N option at service::install).

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 stan.baptista at gmail.com  Tue Feb 20 14:56:19 2007
From: stan.baptista at gmail.com (Stan Baptista)
Date: Tue, 20 Feb 2007 09:56:19 -1000
Subject: [Mongrel] Apache+Mongrel Redirection Problems
In-Reply-To: <2ba0f72b0702161150u1f65544cn276f7f9377e70606@mail.gmail.com>
References: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>
	<20070216015811.90ed7a5c.zedshaw@zedshaw.com>
	<2ba0f72b0702161150u1f65544cn276f7f9377e70606@mail.gmail.com>
Message-ID: <2ba0f72b0702201156t54fbb7ccx554a3b542dd10fa8@mail.gmail.com>

 On 2/16/07, Stan Baptista <stan.baptista at gmail.com> wrote:
>
> > Did you get this resolved Stan?
>
> Yes, thanks. Basically a misunderstanding on my part about how VirtualHost
> directives work in the Apache httpd.conf file. I meant to post the
> solution because I'm curious as to whether I came up with the best approach.
> But it will have to wait until next week when I'm back in the office and
> have access to the Linux system (4-day weekend:-)
>
> I also discovered that the CSS styles aren't rendering in the Rails app
> being served by Mongrel. I strongly suspect it's a ReverseProxy setup issue.
> I'm a little hesitant to bring this up here since I don't think it's a
> Mongrel problem. But I'll post some of the code and if it seems too OT, let
> me know.
>


I'm using Apache 2.2. Here's a snip of httpd.conf.:


> NameVirtualHost 10.4.1.84
>
> <VirtualHost 10.4.1.84>
>
>     RewriteEngine on
>     RewriteRule ^/rss(.*) http://10.4.1.84:5432$1 [P]
>     RewriteRule ^/railstest(.*) http://10.4.1.84:8021$1 [P]
>
> </VirtualHost>
>
> <VirtualHost 10.4.1.84>
>
>     ServerName rss
>     ProxyPass / http://10.4.1.84:5432/
>     ProxyPassReverse /rss http://10.4.1.84:5432/
>     ProxyPreserveHost on
>
> </VirtualHost>
>
> <VirtualHost 10.4.1.84>
>
>     ServerName railstest
>     ProxyPass / http://10.4.1.84:8021/
>     ProxyPassReverse /railstest http://10.4.1.84:8021/
>     ProxyPreserveHost on
>
> </VirtualHost>
>


-Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070220/563a10a2/attachment.html 

From matte at ruckuswireless.com  Tue Feb 20 15:27:20 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Tue, 20 Feb 2007 12:27:20 -0800
Subject: [Mongrel] Apache+Mongrel Redirection Problems
In-Reply-To: <2ba0f72b0702201156t54fbb7ccx554a3b542dd10fa8@mail.gmail.com>
References: <2ba0f72b0702071053i5f38d228qefeadce3f6fb5411@mail.gmail.com>	<20070216015811.90ed7a5c.zedshaw@zedshaw.com>	<2ba0f72b0702161150u1f65544cn276f7f9377e70606@mail.gmail.com>
	<2ba0f72b0702201156t54fbb7ccx554a3b542dd10fa8@mail.gmail.com>
Message-ID: <45DB59A8.5070103@ruckuswireless.com>

I'm researching the reverseproxy situation on a side project, not 
mongrel-related, but relevant I believe.  You might want to look at the 
following page...

http://apache.webthing.com/mod_proxy_html/

This rewrites inline html urls when using reverse proxies and has an 
"extended" option that looks into linked stylesheets and JS files to 
rewrite urls there too.  Dunno if this will help with your problem but 
it might connect a few neurons.

matte - webmonkey
matte at ruckuswireless.com

Stan Baptista wrote:
> On 2/16/07, *Stan Baptista* <stan.baptista at gmail.com 
> <mailto:stan.baptista at gmail.com>> wrote:
>
>     > Did you get this resolved Stan?
>      
>     Yes, thanks. Basically a misunderstanding on my part about how
>     VirtualHost directives work in the Apache httpd.conf file. I meant
>     to post the solution because I'm curious as to whether I came up
>     with the best approach. But it will have to wait until next week
>     when I'm back in the office and have access to the Linux
>     system (4-day weekend:-)
>      
>     I also discovered that the CSS styles aren't rendering in the
>     Rails app being served by Mongrel. I strongly suspect it's a
>     ReverseProxy setup issue. I'm a little hesitant to bring this up
>     here since I don't think it's a Mongrel problem. But I'll post
>     some of the code and if it seems too OT, let me know. 
>
>  
>
> I'm using Apache 2.2. Here's a snip of httpd.conf.:
>  
>
>     NameVirtualHost 10.4.1.84 <http://10.4.1.84>
>
>     <VirtualHost 10.4.1.84 <http://10.4.1.84>>
>
>         RewriteEngine on
>         RewriteRule ^/rss(.*) http://10.4.1.84:5432$1 [P]
>         RewriteRule ^/railstest(.*) http://10.4.1.84:8021$1 [P]
>
>     </VirtualHost>
>
>     <VirtualHost 10.4.1.84 <http://10.4.1.84>>
>
>         ServerName rss
>         ProxyPass / http://10.4.1.84:5432/
>         ProxyPassReverse /rss http://10.4.1.84:5432/
>         ProxyPreserveHost on
>
>     </VirtualHost>
>
>     <VirtualHost 10.4.1.84 <http://10.4.1.84>>
>
>         ServerName railstest
>         ProxyPass / http://10.4.1.84:8021/
>         ProxyPassReverse /railstest http://10.4.1.84:8021/
>         ProxyPreserveHost on
>
>     </VirtualHost>
>
>
>
> -Stan
>  

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

From donnie at darthik.com  Tue Feb 20 22:19:34 2007
From: donnie at darthik.com (donnie at darthik.com)
Date: Tue, 20 Feb 2007 22:19:34 -0500
Subject: [Mongrel] Mongrel_Cluster PID File Creation Error.
Message-ID: <45DBBA46.9080109@darthik.com>

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.

I have attached below a diff of the current working copy in the trunk
and the changes I made to overcome this problem.  I kept your convention
of assuming the file ends with ".pid" in my changes.

Hope this helps.
__
Donnie Jones



svn diff
Index: init.rb
===================================================================
--- init.rb     (revision 519)
+++ init.rb     (working copy)
@@ -24,7 +24,7 @@
         }
         conf = YAML.load_file(@config_file)
         @options.merge! conf if conf
-        @pid_file = @options["pid_file"].split(".")
+        @pid_file = @options["pid_file"].split(".pid")

         start_port = end_port = @only
         start_port ||=  @options["port"].to_i
@@ -34,7 +34,7 @@
       end

       def port_pid_file(port)
-        "#{@pid_file[0]}.#{port}.#{@pid_file[1]}"
+                               "#{@pid_file}.#{port}.pid"
       end

       def start



From roys at okabashi.com  Wed Feb 21 14:47:41 2007
From: roys at okabashi.com (Roy Satterfield)
Date: Wed, 21 Feb 2007 14:47:41 -0500
Subject: [Mongrel] Critical Issue - Site down...
Message-ID: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>

We have a site that is running Mongrel and is down.

Below is the Mongrel log file information.

 

The server is a Linux server with 2gb of RAM.

EV1 (hosting site) says that since this is a Linux server that the RAM
is cached and that there is plenty of free memory available.

 

Can anyone make sense of this error and have some suggestion of options
that I may take to correct this issue and get our site up and running?

 

Below is the Mongrel.log file:

** Daemonized, any open files are closed.  Look at log/mongrel.3010.pid
and log/mongrel.log for info.

** Starting Mongrel listening at 127.0.0.1:3010

** Starting Rails with production environment... 

** Rails loaded.

** Loading any Rails specific GemPlugins

** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no
restart).

** Rails signals registered.  HUP => reload (without restart).  It might
not work well. 

** Mongrel available at 127.0.0.1:3010

[FATAL] failed to allocate memory

 

Here is the server information:

 

General 

CPU

GenuineIntel, Intel(R) Pentium(R) 4 CPU 3.06GHz

Version

psa v7.5.4_build75050824.12 os_RedHat el3

OS

Linux 2.4.20-021stab028.3.777-smp

Key number

PLSK.00317196.0002

System Uptime: 

02:40

CPU usage 

Last 1 minute

0.24

Last 5 minutes

0.38

Last 15 minutes

0.38

Memory Usage 

Total

Used

Free

Shared

Buffer

Cached

Usage

1.97 GB

1.85 GB

123.08 MB

0 B

249.13 MB

726.05 MB

93.9%

 

 

 

 

Swap usage 

Total

Used

Free

Usage

1.95 GB

736.53 MB

1.23 GB

36.82%









Hard Disk Usage 

Filesystem

Total

Used

Available

Capacity

/dev/vzfs

15 360.00 MB

2 677.79 MB

12 682.21 MB

17.43%









Directories

/usr/local/psa
/var/lib/mysql
/var/www/vhosts
/var/qmail/mailnames
/var/named/run-root

proc

0.00 MB

0.00 MB

0.00 MB

0%

 





devpts

0.00 MB

0.00 MB

0.00 MB

0%







Domains 

Active

3

Problem

0

Passive

0

 

 

 

Thanks!!

Roy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/cfb3660b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 104 bytes
Desc: image001.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/cfb3660b/attachment-0005.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 70 bytes
Desc: image002.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/cfb3660b/attachment-0006.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 54 bytes
Desc: image003.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/cfb3660b/attachment-0007.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 100 bytes
Desc: image004.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/cfb3660b/attachment-0008.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 76 bytes
Desc: image005.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/cfb3660b/attachment-0009.gif 

From bradley at railsmachine.com  Wed Feb 21 14:50:31 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Wed, 21 Feb 2007 14:50:31 -0500
Subject: [Mongrel] Mongrel_Cluster PID File Creation Error.
In-Reply-To: <45DBBA46.9080109@darthik.com>
References: <45DBBA46.9080109@darthik.com>
Message-ID: <45DCA287.8040208@railsmachine.com>

Hi Donnie:

Thanks for raising this issue and the patch. Locally, I've patched it 
using ruby's File.basename and it seems to work for your use case and 
supports other file extensions.

I'm working on another prerelease now.

Regards,
Bradley Taylor

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.
> 
> I have attached below a diff of the current working copy in the trunk
> and the changes I made to overcome this problem.  I kept your convention
> of assuming the file ends with ".pid" in my changes.
> 
> Hope this helps.
> __
> Donnie Jones
> 
> 
> 
> svn diff
> Index: init.rb
> ===================================================================
> --- init.rb     (revision 519)
> +++ init.rb     (working copy)
> @@ -24,7 +24,7 @@
>          }
>          conf = YAML.load_file(@config_file)
>          @options.merge! conf if conf
> -        @pid_file = @options["pid_file"].split(".")
> +        @pid_file = @options["pid_file"].split(".pid")
> 
>          start_port = end_port = @only
>          start_port ||=  @options["port"].to_i
> @@ -34,7 +34,7 @@
>        end
> 
>        def port_pid_file(port)
> -        "#{@pid_file[0]}.#{port}.#{@pid_file[1]}"
> +                               "#{@pid_file}.#{port}.pid"
>        end
> 
>        def start
> 
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From donnie at darthik.com  Wed Feb 21 15:04:00 2007
From: donnie at darthik.com (donnie at darthik.com)
Date: Wed, 21 Feb 2007 15:04:00 -0500
Subject: [Mongrel] Mongrel_Cluster PID File Creation Error.
In-Reply-To: <45DCA287.8040208@railsmachine.com>
References: <45DBBA46.9080109@darthik.com> <45DCA287.8040208@railsmachine.com>
Message-ID: <45DCA5B0.4080205@darthik.com>

Hello Bradley,

Excellent, glad I was of some assistance.  :)
It does look like File.basename would be more consistent and less
error-prone. 
__
Donnie

Bradley Taylor wrote:
> Hi Donnie:
>
> Thanks for raising this issue and the patch. Locally, I've patched it 
> using ruby's File.basename and it seems to work for your use case and 
> supports other file extensions.
>
> I'm working on another prerelease now.
>
> Regards,
> Bradley Taylor
>
> 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.
>>
>> I have attached below a diff of the current working copy in the trunk
>> and the changes I made to overcome this problem.  I kept your convention
>> of assuming the file ends with ".pid" in my changes.
>>
>> Hope this helps.
>> __
>> Donnie Jones
>>
>>
>>
>> svn diff
>> Index: init.rb
>> ===================================================================
>> --- init.rb     (revision 519)
>> +++ init.rb     (working copy)
>> @@ -24,7 +24,7 @@
>>          }
>>          conf = YAML.load_file(@config_file)
>>          @options.merge! conf if conf
>> -        @pid_file = @options["pid_file"].split(".")
>> +        @pid_file = @options["pid_file"].split(".pid")
>>
>>          start_port = end_port = @only
>>          start_port ||=  @options["port"].to_i
>> @@ -34,7 +34,7 @@
>>        end
>>
>>        def port_pid_file(port)
>> -        "#{@pid_file[0]}.#{port}.#{@pid_file[1]}"
>> +                               "#{@pid_file}.#{port}.pid"
>>        end
>>
>>        def start
>>
>>
>> _______________________________________________
>> 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 rsanheim at gmail.com  Wed Feb 21 15:15:32 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 21 Feb 2007 14:15:32 -0600
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
Message-ID: <fc113d400702211215j3b7ee35et88133473687b92ea@mail.gmail.com>

Did you look at these files from your log output?  You should include those,
and the rails log if you have anything there.


  Look at log/mongrel.3010.pid and log/mongrel.log for info.

- Rob

On 2/21/07, Roy Satterfield <roys at okabashi.com> wrote:
>
>  We have a site that is running Mongrel and is down.
>
> Below is the Mongrel log file information.
>
>
>
> The server is a Linux server with 2gb of RAM.
>
> EV1 (hosting site) says that since this is a Linux server that the RAM is
> cached and that there is plenty of free memory available.
>
>
>
> Can anyone make sense of this error and have some suggestion of options
> that I may take to correct this issue and get our site up and running?
>
>
>
> Below is the Mongrel.log file:
>
> ** Daemonized, any open files are closed.  Look at log/mongrel.3010.pid
> and log/mongrel.log for info.
>
> ** Starting Mongrel listening at 127.0.0.1:3010
>
> ** Starting Rails with production environment...
>
> ** Rails loaded.
>
> ** Loading any Rails specific GemPlugins
>
> ** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no
> restart).
>
> ** Rails signals registered.  HUP => reload (without restart).  It might
> not work well.
>
> ** Mongrel available at 127.0.0.1:3010
>
> [FATAL] failed to allocate memory
>
>
>
> Here is the server information:
>
>
>
> General
>
> CPU
>
> GenuineIntel, Intel(R) Pentium(R) 4 CPU 3.06GHz
>
> Version
>
> psa v7.5.4_build75050824.12 os_RedHat el3
>
> OS
>
> Linux 2.4.20-021stab028.3.777-smp
>
> Key number
>
> PLSK.00317196.0002
>
> System Uptime:
>
> 02:40
>
> CPU usage
>
> Last 1 minute
>
> 0.24
>
> Last 5 minutes
>
> 0.38
>
> Last 15 minutes
>
> 0.38
>
> Memory Usage
>
> *Total*
>
> *Used*
>
> *Free*
>
> *Shared*
>
> *Buffer*
>
> *Cached*
>
> *Usage*
>
> 1.97 GB
>
> 1.85 GB
>
> 123.08 MB
>
> 0 B
>
> 249.13 MB
>
> 726.05 MB
>
> 93.9%
>
> [image: Bar Begin]
>
> [image: 93.9% used]
>
> [image: 6.1% available]
>
> [image: Bar End]
>
> Swap usage
>
> *Total*
>
> *Used*
>
> *Free*
>
> *Usage*
>
> 1.95 GB
>
> 736.53 MB
>
> 1.23 GB
>
> 36.82%
>
> [image: Bar Begin]
>
> [image: 36.82% used]
>
> [image: 63.18% available]
>
> [image: Bar End]
>
> Hard Disk Usage
>
> *Filesystem*
>
> *Total*
>
> *Used*
>
> *Available*
>
> *Capacity*
>
> /dev/vzfs
>
> 15 360.00 MB
>
> 2 677.79 MB
>
> 12 682.21 MB
>
> 17.43%
>
> [image: Bar Begin]
>
> [image: 17.43% used]
>
> [image: 82.57% available]
>
> [image: Bar End]
>
> Directories
>
> /usr/local/psa
> /var/lib/mysql
> /var/www/vhosts
> /var/qmail/mailnames
> /var/named/run-root
>
> proc
>
> 0.00 MB
>
> 0.00 MB
>
> 0.00 MB
>
> 0%
>
> [image: Bar Begin]
>
> [image: 100% available]
>
> [image: Bar End]
>
> devpts
>
> 0.00 MB
>
> 0.00 MB
>
> 0.00 MB
>
> 0%
>
> [image: Bar Begin]
>
> [image: 100% available]
>
> [image: Bar End]
>
> Domains
>
> Active
>
> 3
>
> Problem
>
> 0
>
> Passive
>
> 0
>
>
>
>
>
>
>
> Thanks!!
>
> Roy
>
> _______________________________________________
> 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/20070221/872292f0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 104 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/872292f0/attachment-0005.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.gif
Type: image/gif
Size: 76 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/872292f0/attachment-0006.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 54 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/872292f0/attachment-0007.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.gif
Type: image/gif
Size: 100 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/872292f0/attachment-0008.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 70 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/872292f0/attachment-0009.gif 

From zedshaw at zedshaw.com  Wed Feb 21 18:33:20 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 21 Feb 2007 15:33:20 -0800
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
Message-ID: <20070221153320.1d72a0df.zedshaw@zedshaw.com>

On Wed, 21 Feb 2007 14:47:41 -0500
"Roy Satterfield" <roys at okabashi.com> wrote:

> [FATAL] failed to allocate memory

You ran out of memory.

-- 
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.

From roys at okabashi.com  Wed Feb 21 15:54:11 2007
From: roys at okabashi.com (Roy Satterfield)
Date: Wed, 21 Feb 2007 15:54:11 -0500
Subject: [Mongrel] Critical Issue - Site down...
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<20070221153320.1d72a0df.zedshaw@zedshaw.com>
Message-ID: <D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>

Zed,
Are you saying that this issue is caused by there not being enough RAM
on the server?
There are 2 sites running on this server. EV1 restarted the VPS and I
took my other site down....
Even with the other site down this site would not restart.

But the weird part is the other site will restart without any problems.
So if it is a memory problem then why will one site start properly?

Thanks,
Roy 

-----Original Message-----
From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed A. Shaw
Sent: Wednesday, February 21, 2007 6:33 PM
To: mongrel-users at rubyforge.org
Subject: Re: [Mongrel] Critical Issue - Site down...

On Wed, 21 Feb 2007 14:47:41 -0500
"Roy Satterfield" <roys at okabashi.com> wrote:

> [FATAL] failed to allocate memory

You ran out of memory.

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

From jason at joyent.com  Wed Feb 21 16:00:30 2007
From: jason at joyent.com (Jason A. Hoffman)
Date: Wed, 21 Feb 2007 13:00:30 -0800
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <fc113d400702211215j3b7ee35et88133473687b92ea@mail.gmail.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<fc113d400702211215j3b7ee35et88133473687b92ea@mail.gmail.com>
Message-ID: <0CC9AC0E-55A3-4189-8D09-AF4D5B31E9C8@joyent.com>

The graphic that you sent has 123.08 MB of RAM free (not too much),  
and you're exhausting that with the single mongrel process.

Regards, Jason


On Feb 21, 2007, at 12:15 PM, Rob Sanheim wrote:

> Did you look at these files from your log output?  You should  
> include those, and the rails log if you have anything there.
>
>
>   Look at log/mongrel.3010.pid and log/mongrel.log for info.
>
> - Rob
>
> On 2/21/07, Roy Satterfield <roys at okabashi.com > wrote:
> We have a site that is running Mongrel and is down.
>
> Below is the Mongrel log file information.
>
>
> The server is a Linux server with 2gb of RAM.
>
> EV1 (hosting site) says that since this is a Linux server that the  
> RAM is cached and that there is plenty of free memory available.
>
>
> Can anyone make sense of this error and have some suggestion of  
> options that I may take to correct this issue and get our site up  
> and running?
>
>
> Below is the Mongrel.log file:
>
> ** Daemonized, any open files are closed.  Look at log/mongrel. 
> 3010.pid and log/mongrel.log for info.
>
> ** Starting Mongrel listening at 127.0.0.1:3010
>
> ** Starting Rails with production environment...
>
> ** Rails loaded.
>
> ** Loading any Rails specific GemPlugins
>
> ** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no  
> restart).
>
> ** Rails signals registered.  HUP => reload (without restart).  It  
> might not work well.
>
> ** Mongrel available at 127.0.0.1:3010
>
> [FATAL] failed to allocate memory
>
>
> Here is the server information:
>
>
> General
>
> CPU
>
> GenuineIntel, Intel(R) Pentium(R) 4 CPU 3.06GHz
>
> Version
>
> psa v7.5.4_build75050824.12 os_RedHat el3
>
> OS
>
> Linux 2.4.20-021stab028.3.777-smp
>
> Key number
>
> PLSK.00317196.0002
>
> System Uptime:
>
> 02:40
>
> CPU usage
>
> Last 1 minute
>
> 0.24
>
> Last 5 minutes
>
> 0.38
>
> Last 15 minutes
>
> 0.38
>
> Memory Usage
>
> Total
>
> Used
>
> Free
>
> Shared
>
> Buffer
>
> Cached
>
> Usage
>
> 1.97 GB
>
> 1.85 GB
>
> 123.08 MB
>
> 0 B
>
> 249.13 MB
>
> 726.05 MB
>
> 93.9%
>
> <image001.gif>
>
> <image002.gif>
>
> <image003.gif>
>
> <image004.gif>
>
> Swap usage
>
> Total
>
> Used
>
> Free
>
> Usage
>
> 1.95 GB
>
> 736.53 MB
>
> 1.23 GB
>
> 36.82%
>
> <image001.gif>
>
> <image002.gif>
>
> <image003.gif>
>
> <image004.gif>
>
> Hard Disk Usage
>
> Filesystem
>
> Total
>
> Used
>
> Available
>
> Capacity
>
> /dev/vzfs
>
> 15 360.00 MB
>
> 2 677.79 MB
>
> 12 682.21 MB
>
> 17.43%
>
> <image001.gif>
>
> <image002.gif>
>
> <image003.gif>
>
> <image004.gif>
>
> Directories
>
> /usr/local/psa
> /var/lib/mysql
> /var/www/vhosts
> /var/qmail/mailnames
> /var/named/run-root
>
> proc
>
> 0.00 MB
>
> 0.00 MB
>
> 0.00 MB
>
> 0%
>
> <image005.gif>
>
> <image003.gif>
>
> <image004.gif>
>
> devpts
>
> 0.00 MB
>
> 0.00 MB
>
> 0.00 MB
>
> 0%
>
> <image005.gif>
>
> <image003.gif>
>
> <image004.gif>
>
> Domains
>
> Active
>
> 3
>
> Problem
>
> 0
>
> Passive
>
> 0
>
>
>
>
> Thanks!!
>
> Roy
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
> <image001.gif>
> <image005.gif>
> <image003.gif>
> <image004.gif>
> <image002.gif>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From zedshaw at zedshaw.com  Wed Feb 21 19:02:35 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 21 Feb 2007 16:02:35 -0800
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<20070221153320.1d72a0df.zedshaw@zedshaw.com>
	<D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
Message-ID: <20070221160235.a97c01e7.zedshaw@zedshaw.com>

On Wed, 21 Feb 2007 15:54:11 -0500
"Roy Satterfield" <roys at okabashi.com> wrote:

> Zed,
> Are you saying that this issue is caused by there not being enough RAM
> on the server?
> There are 2 sites running on this server. EV1 restarted the VPS and I
> took my other site down....
> Even with the other site down this site would not restart.
> 
> But the weird part is the other site will restart without any problems.
> So if it is a memory problem then why will one site start properly?

I don't know, but what I see is a fatal out of memory error.  No matter
what the other application does, this one seems to be trying to use too
much RAM and then dying.  You can get this because of process
restrictions, not enough RAM, etc.

-- 
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.

From erik.hetzner at ucop.edu  Wed Feb 21 16:06:55 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Wed, 21 Feb 2007 13:06:55 -0800
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<20070221153320.1d72a0df.zedshaw@zedshaw.com>
	<D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
Message-ID: <871wkjnrtc.wl%erik.hetzner@ucop.edu>

At Wed, 21 Feb 2007 15:54:11 -0500,
"Roy Satterfield" <roys at okabashi.com> wrote:
>
> Zed,
> Are you saying that this issue is caused by there not being enough RAM
> on the server?
> There are 2 sites running on this server. EV1 restarted the VPS and I
> took my other site down....
> Even with the other site down this site would not restart.
>
> But the weird part is the other site will restart without any problems.
> So if it is a memory problem then why will one site start properly?

On a VPS the numbers which may be reported by utilities like top, etc.
don?t correspond to the amount of memory which actually available for
your server instance. I?m not all that familiar with the way these
things work but it?s happened to me. You are running out of memory. It
has nothing to do with mongrel except mongrel is using that last bit
of memory. Kill unnecessary processes, or talk to your ISP and have
them increase your memory allocation.

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

From joost at spacebabies.nl  Wed Feb 21 16:06:13 2007
From: joost at spacebabies.nl (joost baaij)
Date: Wed, 21 Feb 2007 22:06:13 +0100
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<20070221153320.1d72a0df.zedshaw@zedshaw.com>
	<D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
Message-ID: <E506543D-D0AB-41E0-8F45-CBC336D39B89@spacebabies.nl>

What happens when you fire up WEBrick (script/server) instead of  
Mongrel?

Op 21-feb-2007, om 21:54 heeft Roy Satterfield het volgende geschreven:

> Zed,
> Are you saying that this issue is caused by there not being enough RAM
> on the server?
> There are 2 sites running on this server. EV1 restarted the VPS and I
> took my other site down....
> Even with the other site down this site would not restart.
>
> But the weird part is the other site will restart without any  
> problems.
> So if it is a memory problem then why will one site start properly?
>
> Thanks,
> Roy
>
> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org
> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed A. Shaw
> Sent: Wednesday, February 21, 2007 6:33 PM
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] Critical Issue - Site down...
>
> On Wed, 21 Feb 2007 14:47:41 -0500
> "Roy Satterfield" <roys at okabashi.com> wrote:
>
>> [FATAL] failed to allocate memory
>
> You ran out of memory.
>
> -- 
> 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
> _______________________________________________
> 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/20070221/3a21921b/attachment.bin 

From josh at besquared.net  Wed Feb 21 16:10:51 2007
From: josh at besquared.net (Josh Ferguson)
Date: Wed, 21 Feb 2007 16:10:51 -0500
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <0CC9AC0E-55A3-4189-8D09-AF4D5B31E9C8@joyent.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<fc113d400702211215j3b7ee35et88133473687b92ea@mail.gmail.com>
	<0CC9AC0E-55A3-4189-8D09-AF4D5B31E9C8@joyent.com>
Message-ID: <64971DC1-F59E-4228-87E7-DB4BA74252F8@besquared.net>

I'm also looking at this same box and what's happening is that I'm  
starting a single mongrel server which starts, but the first proxied  
request to it causes the out of memory error. It's only using about  
24M of memory at the time it starts and it dies immediately. I'm not  
sure exactly what the VPS is doing or how it handles its memory.  
Nothing happens in the /var/log/messages log when it dies so I'm not  
really sure if it's a mongrel issue or a Xen issue. Any other ideas?
Josh

On Feb 21, 2007, at 4:00 PM, Jason A. Hoffman wrote:

> The graphic that you sent has 123.08 MB of RAM free (not too much),
> and you're exhausting that with the single mongrel process.
>
> Regards, Jason
>
>
> On Feb 21, 2007, at 12:15 PM, Rob Sanheim wrote:
>
>> Did you look at these files from your log output?  You should
>> include those, and the rails log if you have anything there.
>>
>>
>>   Look at log/mongrel.3010.pid and log/mongrel.log for info.
>>
>> - Rob
>>
>> On 2/21/07, Roy Satterfield <roys at okabashi.com > wrote:
>> We have a site that is running Mongrel and is down.
>>
>> Below is the Mongrel log file information.
>>
>>
>> The server is a Linux server with 2gb of RAM.
>>
>> EV1 (hosting site) says that since this is a Linux server that the
>> RAM is cached and that there is plenty of free memory available.
>>
>>
>> Can anyone make sense of this error and have some suggestion of
>> options that I may take to correct this issue and get our site up
>> and running?
>>
>>
>> Below is the Mongrel.log file:
>>
>> ** Daemonized, any open files are closed.  Look at log/mongrel.
>> 3010.pid and log/mongrel.log for info.
>>
>> ** Starting Mongrel listening at 127.0.0.1:3010
>>
>> ** Starting Rails with production environment...
>>
>> ** Rails loaded.
>>
>> ** Loading any Rails specific GemPlugins
>>
>> ** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no
>> restart).
>>
>> ** Rails signals registered.  HUP => reload (without restart).  It
>> might not work well.
>>
>> ** Mongrel available at 127.0.0.1:3010
>>
>> [FATAL] failed to allocate memory
>>
>>
>> Here is the server information:
>>
>>
>> General
>>
>> CPU
>>
>> GenuineIntel, Intel(R) Pentium(R) 4 CPU 3.06GHz
>>
>> Version
>>
>> psa v7.5.4_build75050824.12 os_RedHat el3
>>
>> OS
>>
>> Linux 2.4.20-021stab028.3.777-smp
>>
>> Key number
>>
>> PLSK.00317196.0002
>>
>> System Uptime:
>>
>> 02:40
>>
>> CPU usage
>>
>> Last 1 minute
>>
>> 0.24
>>
>> Last 5 minutes
>>
>> 0.38
>>
>> Last 15 minutes
>>
>> 0.38
>>
>> Memory Usage
>>
>> Total
>>
>> Used
>>
>> Free
>>
>> Shared
>>
>> Buffer
>>
>> Cached
>>
>> Usage
>>
>> 1.97 GB
>>
>> 1.85 GB
>>
>> 123.08 MB
>>
>> 0 B
>>
>> 249.13 MB
>>
>> 726.05 MB
>>
>> 93.9%
>>
>> <image001.gif>
>>
>> <image002.gif>
>>
>> <image003.gif>
>>
>> <image004.gif>
>>
>> Swap usage
>>
>> Total
>>
>> Used
>>
>> Free
>>
>> Usage
>>
>> 1.95 GB
>>
>> 736.53 MB
>>
>> 1.23 GB
>>
>> 36.82%
>>
>> <image001.gif>
>>
>> <image002.gif>
>>
>> <image003.gif>
>>
>> <image004.gif>
>>
>> Hard Disk Usage
>>
>> Filesystem
>>
>> Total
>>
>> Used
>>
>> Available
>>
>> Capacity
>>
>> /dev/vzfs
>>
>> 15 360.00 MB
>>
>> 2 677.79 MB
>>
>> 12 682.21 MB
>>
>> 17.43%
>>
>> <image001.gif>
>>
>> <image002.gif>
>>
>> <image003.gif>
>>
>> <image004.gif>
>>
>> Directories
>>
>> /usr/local/psa
>> /var/lib/mysql
>> /var/www/vhosts
>> /var/qmail/mailnames
>> /var/named/run-root
>>
>> proc
>>
>> 0.00 MB
>>
>> 0.00 MB
>>
>> 0.00 MB
>>
>> 0%
>>
>> <image005.gif>
>>
>> <image003.gif>
>>
>> <image004.gif>
>>
>> devpts
>>
>> 0.00 MB
>>
>> 0.00 MB
>>
>> 0.00 MB
>>
>> 0%
>>
>> <image005.gif>
>>
>> <image003.gif>
>>
>> <image004.gif>
>>
>> Domains
>>
>> Active
>>
>> 3
>>
>> Problem
>>
>> 0
>>
>> Passive
>>
>> 0
>>
>>
>>
>>
>> Thanks!!
>>
>> Roy
>>
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>> <image001.gif>
>> <image005.gif>
>> <image003.gif>
>> <image004.gif>
>> <image002.gif>
>> _______________________________________________
>> 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 kylekochis at gmail.com  Wed Feb 21 16:18:20 2007
From: kylekochis at gmail.com (Kyle Kochis)
Date: Wed, 21 Feb 2007 14:18:20 -0700
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <E506543D-D0AB-41E0-8F45-CBC336D39B89@spacebabies.nl>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<20070221153320.1d72a0df.zedshaw@zedshaw.com>
	<D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
	<E506543D-D0AB-41E0-8F45-CBC336D39B89@spacebabies.nl>
Message-ID: <6a7034b0702211318p6dd09cbfq388d8609016e6726@mail.gmail.com>

You really shouldn't be running out of memory with 2GB unless you have a
huge amount of traffic or other crap going on that server. To me it looks
like it is caused by one of the following:
1: horribly put together ruby app with bad memory leaking gem/plugins like
rmagick
2: Lots of other crap running on you server that shouldn't be that is
causing high memory leaking.
3: a linux kernel or VPS issue.
There are too many possibilities for us to pin point exactly what is going
on unless you explain what you are doing with your server.

On 2/21/07, joost baaij <joost at spacebabies.nl> wrote:
>
> What happens when you fire up WEBrick (script/server) instead of
> Mongrel?
>
> Op 21-feb-2007, om 21:54 heeft Roy Satterfield het volgende geschreven:
>
> > Zed,
> > Are you saying that this issue is caused by there not being enough RAM
> > on the server?
> > There are 2 sites running on this server. EV1 restarted the VPS and I
> > took my other site down....
> > Even with the other site down this site would not restart.
> >
> > But the weird part is the other site will restart without any
> > problems.
> > So if it is a memory problem then why will one site start properly?
> >
> > Thanks,
> > Roy
> >
> > -----Original Message-----
> > From: mongrel-users-bounces at rubyforge.org
> > [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed A. Shaw
> > Sent: Wednesday, February 21, 2007 6:33 PM
> > To: mongrel-users at rubyforge.org
> > Subject: Re: [Mongrel] Critical Issue - Site down...
> >
> > On Wed, 21 Feb 2007 14:47:41 -0500
> > "Roy Satterfield" <roys at okabashi.com> wrote:
> >
> >> [FATAL] failed to allocate memory
> >
> > You ran out of memory.
> >
> > --
> > 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
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/f6464869/attachment-0001.html 

From josh at besquared.net  Wed Feb 21 16:27:18 2007
From: josh at besquared.net (Josh Ferguson)
Date: Wed, 21 Feb 2007 16:27:18 -0500
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <E506543D-D0AB-41E0-8F45-CBC336D39B89@spacebabies.nl>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<20070221153320.1d72a0df.zedshaw@zedshaw.com>
	<D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
	<E506543D-D0AB-41E0-8F45-CBC336D39B89@spacebabies.nl>
Message-ID: <B55E5851-98BF-414A-BB96-A9CC9991CB90@besquared.net>

I started webrick and get the same issue, I think it's a virtual  
server problem. Here is what's happening:

1) Start webrick on port 3010 in production mode (or mongrel)
2) make a request to the site
3) Production log shows a request to the front page
4) Fatal message occurs in webrick/mongrel log
5) Web browser recieves 500 Application Error response

If you refresh the page you get a proxy error response similar to  
this from apache:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.

Reason: Error reading from remote server

If you refresh it again you get the normal Bad Gateway response, and  
then forever more it is that.

Here's webrick running

-bash-2.05b$ script/server -p 3010 -e production
=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3010
=> Ctrl-C to shutdown server; call with --help for options
[2007-02-21 15:21:33] INFO  WEBrick 1.3.1
[2007-02-21 15:21:33] INFO  ruby 1.8.4 (2005-12-24) [i686-linux]
[2007-02-21 15:21:33] INFO  WEBrick::HTTPServer#start: pid=26139  
port=3010
127.0.0.1 - - [21/Feb/2007:15:21:35 CST] "GET / HTTP/1.1" 200 60
- -> /
[FATAL] failed to allocate memory

This is the site running the Radiant CMS and it has been running  
stable for the past 6 months or so until now.

Josh

On Feb 21, 2007, at 4:06 PM, joost baaij wrote:

> What happens when you fire up WEBrick (script/server) instead of  
> Mongrel?
>
> Op 21-feb-2007, om 21:54 heeft Roy Satterfield het volgende  
> geschreven:
>
>> Zed,
>> Are you saying that this issue is caused by there not being enough  
>> RAM
>> on the server?
>> There are 2 sites running on this server. EV1 restarted the VPS and I
>> took my other site down....
>> Even with the other site down this site would not restart.
>>
>> But the weird part is the other site will restart without any  
>> problems.
>> So if it is a memory problem then why will one site start properly?
>>
>> Thanks,
>> Roy
>>
>> -----Original Message-----
>> From: mongrel-users-bounces at rubyforge.org
>> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed A. Shaw
>> Sent: Wednesday, February 21, 2007 6:33 PM
>> To: mongrel-users at rubyforge.org
>> Subject: Re: [Mongrel] Critical Issue - Site down...
>>
>> On Wed, 21 Feb 2007 14:47:41 -0500
>> "Roy Satterfield" <roys at okabashi.com> wrote:
>>
>>> [FATAL] failed to allocate memory
>>
>> You ran out of memory.
>>
>> -- 
>> 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
>> _______________________________________________
>> 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 bradley at railsmachine.com  Wed Feb 21 17:08:46 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Wed, 21 Feb 2007 17:08:46 -0500
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <871wkjnrtc.wl%erik.hetzner@ucop.edu>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>	<20070221153320.1d72a0df.zedshaw@zedshaw.com>	<D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
	<871wkjnrtc.wl%erik.hetzner@ucop.edu>
Message-ID: <45DCC2EE.1030609@railsmachine.com>

use 'free -m' and look at the "-/+ buffers/cache' line.

Bradley

Erik Hetzner wrote:
> At Wed, 21 Feb 2007 15:54:11 -0500,
> "Roy Satterfield" <roys at okabashi.com> wrote:
>> Zed,
>> Are you saying that this issue is caused by there not being enough RAM
>> on the server?
>> There are 2 sites running on this server. EV1 restarted the VPS and I
>> took my other site down....
>> Even with the other site down this site would not restart.
>>
>> But the weird part is the other site will restart without any problems.
>> So if it is a memory problem then why will one site start properly?
> 
> On a VPS the numbers which may be reported by utilities like top, etc.
> don?t correspond to the amount of memory which actually available for
> your server instance. I?m not all that familiar with the way these
> things work but it?s happened to me. You are running out of memory. It
> has nothing to do with mongrel except mongrel is using that last bit
> of memory. Kill unnecessary processes, or talk to your ISP and have
> them increase your memory allocation.
> 
> best,
> Erik Hetzner
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From rsanheim at gmail.com  Wed Feb 21 17:14:49 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 21 Feb 2007 16:14:49 -0600
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <B55E5851-98BF-414A-BB96-A9CC9991CB90@besquared.net>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<20070221153320.1d72a0df.zedshaw@zedshaw.com>
	<D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
	<E506543D-D0AB-41E0-8F45-CBC336D39B89@spacebabies.nl>
	<B55E5851-98BF-414A-BB96-A9CC9991CB90@besquared.net>
Message-ID: <fc113d400702211414j2ed04544x5f7c31c336798eef@mail.gmail.com>

Have you tried backing out any recent changes (if any?) that were made
to the code or the configuration?  Especially gems or plugins used?

- Rob

On 2/21/07, Josh Ferguson <josh at besquared.net> wrote:
> I started webrick and get the same issue, I think it's a virtual
> server problem. Here is what's happening:
>
> 1) Start webrick on port 3010 in production mode (or mongrel)
> 2) make a request to the site
> 3) Production log shows a request to the front page
> 4) Fatal message occurs in webrick/mongrel log
> 5) Web browser recieves 500 Application Error response
>
> If you refresh the page you get a proxy error response similar to
> this from apache:
>
> Proxy Error
>
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request GET /.
>
> Reason: Error reading from remote server
>
> If you refresh it again you get the normal Bad Gateway response, and
> then forever more it is that.
>
> Here's webrick running
>
> -bash-2.05b$ script/server -p 3010 -e production
> => Booting WEBrick...
> => Rails application started on http://0.0.0.0:3010
> => Ctrl-C to shutdown server; call with --help for options
> [2007-02-21 15:21:33] INFO  WEBrick 1.3.1
> [2007-02-21 15:21:33] INFO  ruby 1.8.4 (2005-12-24) [i686-linux]
> [2007-02-21 15:21:33] INFO  WEBrick::HTTPServer#start: pid=26139
> port=3010
> 127.0.0.1 - - [21/Feb/2007:15:21:35 CST] "GET / HTTP/1.1" 200 60
> - -> /
> [FATAL] failed to allocate memory
>
> This is the site running the Radiant CMS and it has been running
> stable for the past 6 months or so until now.
>
> Josh
>
> On Feb 21, 2007, at 4:06 PM, joost baaij wrote:
>
> > What happens when you fire up WEBrick (script/server) instead of
> > Mongrel?
> >
> > Op 21-feb-2007, om 21:54 heeft Roy Satterfield het volgende
> > geschreven:
> >
> >> Zed,
> >> Are you saying that this issue is caused by there not being enough
> >> RAM
> >> on the server?
> >> There are 2 sites running on this server. EV1 restarted the VPS and I
> >> took my other site down....
> >> Even with the other site down this site would not restart.
> >>
> >> But the weird part is the other site will restart without any
> >> problems.
> >> So if it is a memory problem then why will one site start properly?
> >>
> >> Thanks,
> >> Roy
> >>
> >> -----Original Message-----
> >> From: mongrel-users-bounces at rubyforge.org
> >> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed A. Shaw
> >> Sent: Wednesday, February 21, 2007 6:33 PM
> >> To: mongrel-users at rubyforge.org
> >> Subject: Re: [Mongrel] Critical Issue - Site down...
> >>
> >> On Wed, 21 Feb 2007 14:47:41 -0500
> >> "Roy Satterfield" <roys at okabashi.com> wrote:
> >>
> >>> [FATAL] failed to allocate memory
> >>
> >> You ran out of memory.
> >>
> >> --
> >> 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
> >> _______________________________________________
> >> 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
>

From joost at spacebabies.nl  Wed Feb 21 18:01:39 2007
From: joost at spacebabies.nl (joost baaij)
Date: Thu, 22 Feb 2007 00:01:39 +0100
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <45DCC2EE.1030609@railsmachine.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>	<20070221153320.1d72a0df.zedshaw@zedshaw.com>	<D6902C3BCB779242B12A83CF4250AE770146FE3C@okasrv1.okabashi.com>
	<871wkjnrtc.wl%erik.hetzner@ucop.edu>
	<45DCC2EE.1030609@railsmachine.com>
Message-ID: <2316D448-B665-4FC9-AE12-A2C4E3F751F3@spacebabies.nl>

Also, this might help in profiling possible memory leaks.
http://scottstuff.net/blog/articles/2006/08/17/memory-leak-profiling- 
with-rails

Op 21-feb-2007, om 23:08 heeft Bradley Taylor het volgende geschreven:

> use 'free -m' and look at the "-/+ buffers/cache' line.
>
> Bradley
>
> Erik Hetzner wrote:
>> At Wed, 21 Feb 2007 15:54:11 -0500,
>> "Roy Satterfield" <roys at okabashi.com> wrote:
>>> Zed,
>>> Are you saying that this issue is caused by there not being  
>>> enough RAM
>>> on the server?
>>> There are 2 sites running on this server. EV1 restarted the VPS  
>>> and I
>>> took my other site down....
>>> Even with the other site down this site would not restart.
>>>
>>> But the weird part is the other site will restart without any  
>>> problems.
>>> So if it is a memory problem then why will one site start properly?
>>
>> On a VPS the numbers which may be reported by utilities like top,  
>> etc.
>> don?t correspond to the amount of memory which actually available for
>> your server instance. I?m not all that familiar with the way these
>> things work but it?s happened to me. You are running out of  
>> memory. It
>> has nothing to do with mongrel except mongrel is using that last bit
>> of memory. Kill unnecessary processes, or talk to your ISP and have
>> them increase your memory allocation.
>>
>> best,
>> Erik Hetzner
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> 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/20070222/49dbac2a/attachment.bin 

From stan.baptista at gmail.com  Wed Feb 21 21:21:51 2007
From: stan.baptista at gmail.com (Stan Baptista)
Date: Wed, 21 Feb 2007 16:21:51 -1000
Subject: [Mongrel] OT(?): ReverseProxy and URLs
Message-ID: <2ba0f72b0702211821r301af944i87a8c4252c7e4321@mail.gmail.com>

This could be OT. If so, just let me know and I apologize in advance.

I mentioned in an earlier email that I have Mongrel setup as a proxy server
behind Apache. Rails applications served by Mongrel do not find the CSS file
and hence no styles are displayed. In fact, many of the actions are not
found.The reason, I believe, is because the URLs for styles and actions
typically follow this pattern:

<!-- Style sheets -->
<link href="/stylesheets/style.css?1171939096" media="screen"
rel="Stylesheet" type="text/css" />

(Note the first '/'.)

When accessing a Rails app directly via a port# (http://10.4.1.84:5222)
things are fine, but not so when accessing via Apache (http://10.4.1.84/rss
).

Presumably, in this case, it's looking for the style sheet in the Apache
webroot and failing.

I'm fairly sure this is a ReverseProxy problem and also suspect it's not
uncommon. Before investigating too deeply, I wonder if some of you have
already found solutions.

The Apache httpd.conf VirtualHost directives are these:

NameVirtualHost 10.4.1.84

<VirtualHost 10.4.1.84>

    RewriteEngine on
    RewriteRule ^/rss(.*) http://10.4.1.84:5222$1 [P]
    RewriteRule ^/railstest(.*) http://10.4.1.84:8223$1 [P]

</VirtualHost>

<VirtualHost 10.4.1.84>

    ServerName rss
    ProxyPass / http://10.4.1.84:5222/
    ProxyPassReverse /rss http://10.4.1.84:5222/
    ProxyPreserveHost on

</VirtualHost>

<VirtualHost 10.4.1.84>

    ServerName railstest
    ProxyPass / http://10.4.1.84:8223/
    ProxyPassReverse /railstest http://10.4.1.84:8223/
    ProxyPreserveHost on

</VirtualHost>

Any help, as always, is appreciated.

Thanks,
Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070221/53f66c4d/attachment.html 

From maze at strahlungsfrei.de  Thu Feb 22 06:37:47 2007
From: maze at strahlungsfrei.de (Martin Honermeyer)
Date: Thu, 22 Feb 2007 12:37:47 +0100
Subject: [Mongrel] HTTP_REFERER support?
Message-ID: <erjv7p$t84$1@sea.gmane.org>

Hello,

we want to read the referer URL from the HTTP headers, in order to be able
to track where someone is coming from, in a Rails application.

As I can see in the source, Mongrel doesn't even parse the HTTP_REFERER
field from HTTP requests. This would make a useful feature, I guess.

Apart from that, Mongrel is (IMHO) simply the best solution for deploying
Rails - keep on going!


Greetings
Martin



From hutch at recursive.ca  Thu Feb 22 08:41:53 2007
From: hutch at recursive.ca (Bob Hutchison)
Date: Thu, 22 Feb 2007 08:41:53 -0500
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <64971DC1-F59E-4228-87E7-DB4BA74252F8@besquared.net>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<fc113d400702211215j3b7ee35et88133473687b92ea@mail.gmail.com>
	<0CC9AC0E-55A3-4189-8D09-AF4D5B31E9C8@joyent.com>
	<64971DC1-F59E-4228-87E7-DB4BA74252F8@besquared.net>
Message-ID: <42318BEE-5F78-426C-B881-B8A26AF46DA8@recursive.ca>

Hi,

On 21-Feb-07, at 4:10 PM, Josh Ferguson wrote:

> I'm also looking at this same box and what's happening is that I'm
> starting a single mongrel server which starts, but the first proxied
> request to it causes the out of memory error. It's only using about
> 24M of memory at the time it starts and it dies immediately. I'm not
> sure exactly what the VPS is doing or how it handles its memory.
> Nothing happens in the /var/log/messages log when it dies so I'm not
> really sure if it's a mongrel issue or a Xen issue. Any other ideas?
> Josh

I had something similar happen on a new VPS. It was a user quota  
problem. I whined to the ISP and it was fixed in a couple of minutes.  
I'd suggest looking into user and process quotas that might be  
exceeded or changed recently (doing this isn't necessarily all that  
easy and you might need the sys admin's help/co-operation).

Cheers,
Bob


----
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 jgeiger at gmail.com  Thu Feb 22 09:21:32 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Thu, 22 Feb 2007 08:21:32 -0600
Subject: [Mongrel] OT(?): ReverseProxy and URLs
In-Reply-To: <2ba0f72b0702211821r301af944i87a8c4252c7e4321@mail.gmail.com>
References: <2ba0f72b0702211821r301af944i87a8c4252c7e4321@mail.gmail.com>
Message-ID: <466af3440702220621q2415e4eavf40dcf08ff5f8404@mail.gmail.com>

You're going to run into issues because you want to access your
application from both urls (with the port and without).

If you just chose to use the /rss, you could start mongrel with the
app prefix /rss, which would be a start. I'm not sure if you also need
to add /rss to the end of your proxy and reverse proxy statements.

On 2/21/07, Stan Baptista <stan.baptista at gmail.com> wrote:
> This could be OT. If so, just let me know and I apologize in advance.
>
> I mentioned in an earlier email that I have Mongrel setup as a proxy server
> behind Apache. Rails applications served by Mongrel do not find the CSS file
> and hence no styles are displayed. In fact, many of the actions are not
> found.The reason, I believe, is because the URLs for styles and actions
> typically follow this pattern:
>
> <!-- Style sheets -->
> <link href="/stylesheets/style.css?1171939096"
> media="screen" rel="Stylesheet" type="text/css" />
>
> (Note the first '/'.)
>
> When accessing a Rails app directly via a port# (http://10.4.1.84:5222)
> things are fine, but not so when accessing via Apache (http://10.4.1.84/rss
> ).
>
> Presumably, in this case, it's looking for the style sheet in the Apache
> webroot and failing.
>
> I'm fairly sure this is a ReverseProxy problem and also suspect it's not
> uncommon. Before investigating too deeply, I wonder if some of you have
> already found solutions.
>
> The Apache httpd.conf VirtualHost directives are these:
>
> NameVirtualHost 10.4.1.84
>
> <VirtualHost 10.4.1.84>
>
>     RewriteEngine on
>     RewriteRule ^/rss(.*) http://10.4.1.84:5222$1 [P]
>     RewriteRule ^/railstest(.*) http://10.4.1.84:8223$1 [P]
>
> </VirtualHost>
>
> <VirtualHost 10.4.1.84>
>
>     ServerName rss
>     ProxyPass / http://10.4.1.84:5222/
>     ProxyPassReverse /rss http://10.4.1.84:5222/
>     ProxyPreserveHost on
>
> </VirtualHost>
>
> <VirtualHost 10.4.1.84>
>
>     ServerName railstest
>     ProxyPass / http://10.4.1.84:8223/
>     ProxyPassReverse /railstest http://10.4.1.84:8223/
>     ProxyPreserveHost on
>
> </VirtualHost>
> Any help, as always, is appreciated.
>
> Thanks,
> Stan
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From eden.li at gmail.com  Thu Feb 22 11:33:48 2007
From: eden.li at gmail.com (Eden Li)
Date: Fri, 23 Feb 2007 00:33:48 +0800
Subject: [Mongrel] HTTP_REFERER support?
In-Reply-To: <erjv7p$t84$1@sea.gmane.org>
References: <erjv7p$t84$1@sea.gmane.org>
Message-ID: <565dbdd40702220833hac851dfp683a7d64bf36386a@mail.gmail.com>

Er, the referrer should be available in request.env['HTTP_REFERER'].

Note, this key won't exist unless your browser sends the Referer:
header which only shows up if you click on a link to or within your
site.  You won't see this header being sent if you type the URL of
your action directly into the address bar (as stipulated by the HTTP
spec).

On 2/22/07, Martin Honermeyer <maze at strahlungsfrei.de> wrote:
> Hello,
>
> we want to read the referer URL from the HTTP headers, in order to be able
> to track where someone is coming from, in a Rails application.
>
> As I can see in the source, Mongrel doesn't even parse the HTTP_REFERER
> field from HTTP requests. This would make a useful feature, I guess.
>
> Apart from that, Mongrel is (IMHO) simply the best solution for deploying
> Rails - keep on going!
>
>
> Greetings
> Martin
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From roys at okabashi.com  Thu Feb 22 11:41:41 2007
From: roys at okabashi.com (Roy Satterfield)
Date: Thu, 22 Feb 2007 11:41:41 -0500
Subject: [Mongrel] Critical Issue - Site down...
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com><fc113d400702211215j3b7ee35et88133473687b92ea@mail.gmail.com><0CC9AC0E-55A3-4189-8D09-AF4D5B31E9C8@joyent.com><64971DC1-F59E-4228-87E7-DB4BA74252F8@besquared.net>
	<42318BEE-5F78-426C-B881-B8A26AF46DA8@recursive.ca>
Message-ID: <D6902C3BCB779242B12A83CF4250AE770146FE69@okasrv1.okabashi.com>

Here is the current view of system resources on our site
configuration...

 

Resources based on VPS template 

Name

VPS-184MB-15GB-150GB-754

Description

184 MB RAM, 15 GB Hard Drive Space, 150 GB Bandwidth

 

Tools 

ExtendedExtended 

 

CPU Usage 

Resource

 

Capacity

CPU

 

 

 

 

 

2.0%

Load Average

 

0.3, 0.48, 0.45

	

 

System Usage 

Resource

 

Capacity

System











67.68%

 

Disk Usage 

Resource

 

Capacity

Total

Used

Available

Disk Space











17.48%

15 Gb

3 Gb

12 Gb

Disk Inodes











20.31%

634,507

128,867

505,640

 

 

-----Original Message-----
From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Bob Hutchison
Sent: Thursday, February 22, 2007 8:42 AM
To: mongrel-users at rubyforge.org
Subject: Re: [Mongrel] Critical Issue - Site down...

 

Hi,

 

On 21-Feb-07, at 4:10 PM, Josh Ferguson wrote:

 

> I'm also looking at this same box and what's happening is that I'm

> starting a single mongrel server which starts, but the first proxied

> request to it causes the out of memory error. It's only using about

> 24M of memory at the time it starts and it dies immediately. I'm not

> sure exactly what the VPS is doing or how it handles its memory.

> Nothing happens in the /var/log/messages log when it dies so I'm not

> really sure if it's a mongrel issue or a Xen issue. Any other ideas?

> Josh

 

I had something similar happen on a new VPS. It was a user quota  

problem. I whined to the ISP and it was fixed in a couple of minutes.  

I'd suggest looking into user and process quotas that might be  

exceeded or changed recently (doing this isn't necessarily all that  

easy and you might need the sys admin's help/co-operation).

 

Cheers,

Bob

 

 

----

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/>

 

 

 

_______________________________________________

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/20070222/b87fe813/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 559 bytes
Desc: image001.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070222/b87fe813/attachment-0005.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 104 bytes
Desc: image002.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070222/b87fe813/attachment-0006.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 70 bytes
Desc: image003.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070222/b87fe813/attachment-0007.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 54 bytes
Desc: image004.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070222/b87fe813/attachment-0008.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 100 bytes
Desc: image005.gif
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070222/b87fe813/attachment-0009.gif 

From zedshaw at zedshaw.com  Thu Feb 22 16:55:04 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 22 Feb 2007 13:55:04 -0800
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE770146FE69@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<fc113d400702211215j3b7ee35et88133473687b92ea@mail.gmail.com>
	<0CC9AC0E-55A3-4189-8D09-AF4D5B31E9C8@joyent.com>
	<64971DC1-F59E-4228-87E7-DB4BA74252F8@besquared.net>
	<42318BEE-5F78-426C-B881-B8A26AF46DA8@recursive.ca>
	<D6902C3BCB779242B12A83CF4250AE770146FE69@okasrv1.okabashi.com>
Message-ID: <20070222135504.9ef9d83b.zedshaw@zedshaw.com>

On Thu, 22 Feb 2007 11:41:41 -0500
"Roy Satterfield" <roys at okabashi.com> wrote:

> 184 MB RAM, 15 GB Hard Drive Space, 150 GB Bandwidth

Roy, 184M of ram is *not* enough to run most production sites.  Ever.

This is why you get an out of memory error.

Sorry to be short, but you seriously need to expand this or get someone
to help you.

-- 
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.

From lists at lastonepicked.com  Thu Feb 22 13:28:46 2007
From: lists at lastonepicked.com (Hunter Hillegas)
Date: Thu, 22 Feb 2007 10:28:46 -0800
Subject: [Mongrel] Modifying Apache Conf To Block Leachers
Message-ID: <4AF85326-ADF7-46CB-B6B5-B69AE509FF26@lastonepicked.com>

Howdy,

I'm using Apache 2.2 + Mongrel with great success, using the sample  
configs from the Mongrel site.

We have some MP3s on the site and recently someone has been stealing  
them and basically leaching them from the site, linking to them from  
an off-site location.

I've been trying to modify my Apache conf to check the referrer and  
adjust accordingly as below but no luck. I'm wondering if someone  
else has any suggestions on getting this to work... I would expect  
this to send the user to error.html if the referrer is not the site  
in question but nothing at all happens...

Any suggestions appreciated, this stuff drives me batty.

URL: http://www.mysite.com/audio_file/the_audio_file/file.mp3

RewriteCond %{REQUEST_FILENAME} .*mp3$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !mysite\.com [NC]
RewriteCond %{HTTP_REFERER} !friendlysite\.com [NC]
RewriteCond %{HTTP_REFERER} !google\. [NC]
RewriteCond %{HTTP_REFERER} !search\?q=cache [NC]
RewriteRule (.*) /error.html

RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /maintenance.html [L]
# Rewrite index to check for static index.html
RewriteRule ^/$ /index.html [QSA]
# Rewrite to check for Rails cached pages with .html extensions
RewriteRule ^([^.]+)$ $1.html [QSA]
# All dynamic requests get sent to the cluster
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://sitejive%{REQUEST_URI} [P,QSA,L]

Thanks,
Hunter

From njvack at wisc.edu  Thu Feb 22 14:46:00 2007
From: njvack at wisc.edu (Nathan Vack)
Date: Thu, 22 Feb 2007 13:46:00 -0600
Subject: [Mongrel] Modifying Apache Conf To Block Leachers
In-Reply-To: <4AF85326-ADF7-46CB-B6B5-B69AE509FF26@lastonepicked.com>
References: <4AF85326-ADF7-46CB-B6B5-B69AE509FF26@lastonepicked.com>
Message-ID: <90F4305A-1DA7-4956-8862-8F05AB3BB702@wisc.edu>

If people are stealing MP3s, checking referer won't work. It can be  
trivially spoofed.

You'll need real authentication to stop theft -- either with  
sessions, or HTTP auth.

-Nate

On Feb 22, 2007, at 12:28 PM, Hunter Hillegas wrote:

> We have some MP3s on the site and recently someone has been stealing
> them and basically leaching them from the site, linking to them from
> an off-site location.
>
> I've been trying to modify my Apache conf to check the referrer and
> adjust accordingly as below but no luck. I'm wondering if someone
> else has any suggestions on getting this to work... I would expect
> this to send the user to error.html if the referrer is not the site
> in question but nothing at all happens...


From joost at spacebabies.nl  Thu Feb 22 16:04:10 2007
From: joost at spacebabies.nl (joost baaij)
Date: Thu, 22 Feb 2007 22:04:10 +0100
Subject: [Mongrel] Modifying Apache Conf To Block Leachers
In-Reply-To: <90F4305A-1DA7-4956-8862-8F05AB3BB702@wisc.edu>
References: <4AF85326-ADF7-46CB-B6B5-B69AE509FF26@lastonepicked.com>
	<90F4305A-1DA7-4956-8862-8F05AB3BB702@wisc.edu>
Message-ID: <EC075D99-7D22-446C-83BF-927DBEC8F88F@spacebabies.nl>


Op 22-feb-2007, om 20:46 heeft Nathan Vack het volgende geschreven:

> If people are stealing MP3s, checking referer won't work. It can be
> trivially spoofed.

Can be, but usually isn't. The good thing about hotlinking is that  
nobody uses the web with referers disabled. I certainly don't.

> You'll need real authentication to stop theft -- either with
> sessions, or HTTP auth.

That would be best indeed. It's just that direct links to mp3 files  
never see Rails, so you need to fix it in the web server. Pretty soon  
you're looking at quite some work if you want to do it right. Some  
web servers provide an easy switch to prevent hotlinking; it might-- 
might--be an interesting addition to Mongrel. At Zed's discretion.

I use sessions and prevent hotlinking at server level too--it's just  
an easy thing to do and has great results. I think there might be a  
problem with the poster's regexps. This page lists good ones and has  
a quick test to see of your rules work.

http://altlab.com/htaccess_tutorial.html

The example they provide:

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?livejournal\.com/ [NC]
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]
-------------- 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/20070222/4ccb19c2/attachment.bin 

From lists at lastonepicked.com  Thu Feb 22 16:28:40 2007
From: lists at lastonepicked.com (Hunter Hillegas)
Date: Thu, 22 Feb 2007 13:28:40 -0800
Subject: [Mongrel] Modifying Apache Conf To Block Leachers
In-Reply-To: <90F4305A-1DA7-4956-8862-8F05AB3BB702@wisc.edu>
References: <4AF85326-ADF7-46CB-B6B5-B69AE509FF26@lastonepicked.com>
	<90F4305A-1DA7-4956-8862-8F05AB3BB702@wisc.edu>
Message-ID: <97FA45C4-2E6B-452D-A99F-9EE0489FCA2C@lastonepicked.com>

Actually, the minimum of checking is fine - we just want to stop the  
lazy people, not create a secure system to protect these files.

This is content that is available to the world, we just want folks  
grabbing it from our site, not linking in stuff from MySpace, etc..

The technique I'm trying to implement is used often for images and  
the like.

So, given that, anyone have any idea why the checking isn't working?

On Feb 22, 2007, at 11:46 AM, Nathan Vack wrote:

> If people are stealing MP3s, checking referer won't work. It can be
> trivially spoofed.
>
> You'll need real authentication to stop theft -- either with
> sessions, or HTTP auth.
>
> -Nate
>
> On Feb 22, 2007, at 12:28 PM, Hunter Hillegas wrote:
>
>> We have some MP3s on the site and recently someone has been stealing
>> them and basically leaching them from the site, linking to them from
>> an off-site location.
>>
>> I've been trying to modify my Apache conf to check the referrer and
>> adjust accordingly as below but no luck. I'm wondering if someone
>> else has any suggestions on getting this to work... I would expect
>> this to send the user to error.html if the referrer is not the site
>> in question but nothing at all happens...
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From jjhogue at sbcglobal.net  Thu Feb 22 17:50:10 2007
From: jjhogue at sbcglobal.net (Jim Hogue)
Date: Thu, 22 Feb 2007 17:50:10 -0500
Subject: [Mongrel] Critical Issue - Site down...
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com><fc113d400702211215j3b7ee35et88133473687b92ea@mail.gmail.com><0CC9AC0E-55A3-4189-8D09-AF4D5B31E9C8@joyent.com><64971DC1-F59E-4228-87E7-DB4BA74252F8@besquared.net><42318BEE-5F78-426C-B881-B8A26AF46DA8@recursive.ca><D6902C3BCB779242B12A83CF4250AE770146FE69@okasrv1.okabashi.com>
	<20070222135504.9ef9d83b.zedshaw@zedshaw.com>
Message-ID: <00a601c756d3$cf6e77c0$0400a8c0@DEN2>

Zed,

I haven't followed this discussion, but I was running Apache 2.2 + 3 
mongrels on a Pent 2 with 64Mb of memory running Linux and it worked. 
It was dog slow because it was always swapping, but it ran.  Does his 
system not swap?

BTW, just an excuse to say thanks for Mongrel.  I was ready to abandon 
the whole rails thing after many months of fighting with various 
mod_ruby, fastcgi, etc solutions only to have them work sometimes and 
sometimes not.  Mongrel saved the day.  Thanks!

    - Jim

----- Original Message ----- 
From: "Zed A. Shaw" <zedshaw at zedshaw.com>
To: <mongrel-users at rubyforge.org>
Sent: Thursday, February 22, 2007 4:55 PM
Subject: Re: [Mongrel] Critical Issue - Site down...


> On Thu, 22 Feb 2007 11:41:41 -0500
> "Roy Satterfield" <roys at okabashi.com> wrote:
>
>> 184 MB RAM, 15 GB Hard Drive Space, 150 GB Bandwidth
>
> Roy, 184M of ram is *not* enough to run most production sites. 
> Ever.
>
> This is why you get an out of memory error.
>
> Sorry to be short, but you seriously need to expand this or get 
> someone
> to help you.
>
> -- 
> 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
> 



From kylekochis at gmail.com  Thu Feb 22 18:24:04 2007
From: kylekochis at gmail.com (Kyle Kochis)
Date: Thu, 22 Feb 2007 16:24:04 -0700
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <00a601c756d3$cf6e77c0$0400a8c0@DEN2>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
	<fc113d400702211215j3b7ee35et88133473687b92ea@mail.gmail.com>
	<0CC9AC0E-55A3-4189-8D09-AF4D5B31E9C8@joyent.com>
	<64971DC1-F59E-4228-87E7-DB4BA74252F8@besquared.net>
	<42318BEE-5F78-426C-B881-B8A26AF46DA8@recursive.ca>
	<D6902C3BCB779242B12A83CF4250AE770146FE69@okasrv1.okabashi.com>
	<20070222135504.9ef9d83b.zedshaw@zedshaw.com>
	<00a601c756d3$cf6e77c0$0400a8c0@DEN2>
Message-ID: <6a7034b0702221524r78716dd3s550360c5648f42d5@mail.gmail.com>

I have set up a few VPS's with low ram (one had 128MB with no swap) a
couple mongrels behind nginx and it is rather fast and can handle it
well. The Rails app on that site is fairly small but uses file_upload
and rmagick and has never stalled in production (not saying i like
rmagick or anything). The traffic on it is fairly low but you can hit
it with httperf at 50 requests per second (10,000 request batch) and
it doesn't even slow down in response time too much. This site isn't
anything to brag about but I just want to make the point on what you
can do as long as you set things up correctly. if you are just running
single mongrel instance you shouldn't need very much ram, if you are
having problems that tells me that something else is amiss.

Kyle Kochis

On 2/22/07, Jim Hogue <jjhogue at sbcglobal.net> wrote:
> Zed,
>
> I haven't followed this discussion, but I was running Apache 2.2 + 3
> mongrels on a Pent 2 with 64Mb of memory running Linux and it worked.
> It was dog slow because it was always swapping, but it ran.  Does his
> system not swap?
>
> BTW, just an excuse to say thanks for Mongrel.  I was ready to abandon
> the whole rails thing after many months of fighting with various
> mod_ruby, fastcgi, etc solutions only to have them work sometimes and
> sometimes not.  Mongrel saved the day.  Thanks!
>
>     - Jim
>
> ----- Original Message -----
> From: "Zed A. Shaw" <zedshaw at zedshaw.com>
> To: <mongrel-users at rubyforge.org>
> Sent: Thursday, February 22, 2007 4:55 PM
> Subject: Re: [Mongrel] Critical Issue - Site down...
>
>
> > On Thu, 22 Feb 2007 11:41:41 -0500
> > "Roy Satterfield" <roys at okabashi.com> wrote:
> >
> >> 184 MB RAM, 15 GB Hard Drive Space, 150 GB Bandwidth
> >
> > Roy, 184M of ram is *not* enough to run most production sites.
> > Ever.
> >
> > This is why you get an out of memory error.
> >
> > Sorry to be short, but you seriously need to expand this or get
> > someone
> > to help you.
> >
> > --
> > 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
> >
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From pete at nextengine.com  Thu Feb 22 21:35:26 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Thu, 22 Feb 2007 18:35:26 -0800
Subject: [Mongrel] Mongrel::Uploads.check() not returning status
In-Reply-To: <56C5F01B-4E1C-45C7-BC30-A4D00DF8EDDC@nextengine.com>
References: <56C5F01B-4E1C-45C7-BC30-A4D00DF8EDDC@nextengine.com>
Message-ID: <900556C3-EB73-463E-A7BE-E6F27925CD18@nextengine.com>

Hi,

I wrote a message earlier regarding how I wasn't getting any feedback  
from mongrel_upload_progress.  After putting lots of debug messages  
in the plugin, I figured out what was going on.

I had a route like this setup in routes.rb (this was the problem):

	map.upload "upload/:upload_id",
		               :controller => "file",
          		       :action => "upload"

And here's my config/mongrel_upload_progress.conf file:

	uri "/",
	  :handler => plugin("/handlers/upload", :path_info => '/file/upload'),
  	 :in_front => true

My form was sending to :controller => file, :action => upload.  Well,  
the route turned this into "/upload/xxxxxxx", and this didn't match  
the path_info "/file/upload".

Once I removed the route, the problem was fixed and progress started  
coming through.

-Pete

On Feb 22, 2007, at 8:04 AM, Pete DeLaurentis wrote:

> Hi guys,
>
> I'm using mongrel_upload_progress and experiencing an error similar  
> to what another user hit on the list on Jan 19th.
>
> For this test, I'm running one mongrel:
>
> 	mongrel_rails start -p 3000 -S config/mongrel_upload_progress.conf
> 	
> Here's my config/mongrel_upload_progress.conf file:
>
> 	uri "/",
> 	  :handler => plugin("/handlers/upload", :path_info => '/file/ 
> upload'),
>  	 :in_front => true
>
> Here's my controller progress method.  The upload ID is correct,  
> but the status that comes back is always nil:
>
> 	def progress
> 		puts "Upload ID is valid: " + params[:upload_id]
>
> 		@status = Mongrel::Uploads.check(params[:upload_id])
> 		...
> 	end
>
> Thanks for the help!
> Pete
>
> Here's the Jan 19 post:
>
> I am trying to get the mongrel upload progress working and am  
> having some problems. I am using Rails 1.1.6 and the latest install  
> of mongrel. I created the config/mongrel_upload_progress.conf per  
> the instructions ... it looks like this ...
>
> uri "/",
> :handler => plugin("/handlers/upload", :path_info => '/listings/  
> add_photo'),
>   :frequency => 1,
>   :in_front => true
>
> Then I start mongrel like this ...
>
> mongrel_rails start -d -p 3000 -S config/mongrel_upload_progress.conf
>
> In my controller's progress method I call ...
>
>       @status = Mongrel::Uploads.check(params[:upload_id])
>
> However, @status is always nil. Any ideas? The upload_id is  
> properly being sent.
>
> The file does upload; but the progress bar just goes from 0% to  
> 100% once the upload is finished.
>
> Thanks.
>
> Bill Siggelkow
> AIM: siggelkowb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070222/5da58d82/attachment-0001.html 

From kraemer at webit.de  Fri Feb 23 05:01:03 2007
From: kraemer at webit.de (Jens Kraemer)
Date: Fri, 23 Feb 2007 11:01:03 +0100
Subject: [Mongrel] Modifying Apache Conf To Block Leachers
In-Reply-To: <4AF85326-ADF7-46CB-B6B5-B69AE509FF26@lastonepicked.com>
References: <4AF85326-ADF7-46CB-B6B5-B69AE509FF26@lastonepicked.com>
Message-ID: <20070223100103.GF19149@cordoba.webit.de>

On Thu, Feb 22, 2007 at 10:28:46AM -0800, Hunter Hillegas wrote:
> Howdy,
> 
> I'm using Apache 2.2 + Mongrel with great success, using the sample  
> configs from the Mongrel site.
> 
> We have some MP3s on the site and recently someone has been stealing  
> them and basically leaching them from the site, linking to them from  
> an off-site location.
> 
> I've been trying to modify my Apache conf to check the referrer and  
> adjust accordingly as below but no luck. I'm wondering if someone  
> else has any suggestions on getting this to work... I would expect  
> this to send the user to error.html if the referrer is not the site  
> in question but nothing at all happens...
> 
> Any suggestions appreciated, this stuff drives me batty.
> 
> URL: http://www.mysite.com/audio_file/the_audio_file/file.mp3
> 
> RewriteCond %{REQUEST_FILENAME} .*mp3$ [NC]
> RewriteCond %{HTTP_REFERER} !^$
> RewriteCond %{HTTP_REFERER} !mysite\.com [NC]
> RewriteCond %{HTTP_REFERER} !friendlysite\.com [NC]
> RewriteCond %{HTTP_REFERER} !google\. [NC]
> RewriteCond %{HTTP_REFERER} !search\?q=cache [NC]
> RewriteRule (.*) /error.html

try appending [L] to the RewriteRule above. And be sure to enable
rewrite logging to debug such things:

RewriteLog /path/to/logfile
RewriteLogLevel 4 

and be sure to disable logging once it works - these logs tend to grow
to enormous sizes fast :-)

cheers,
Jens

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

From ben.myles at gmail.com  Fri Feb 23 07:18:00 2007
From: ben.myles at gmail.com (Ben Myles)
Date: Fri, 23 Feb 2007 22:18:00 +1000
Subject: [Mongrel] Critical Issue - Site down...
In-Reply-To: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
References: <D6902C3BCB779242B12A83CF4250AE770146FE33@okasrv1.okabashi.com>
Message-ID: <c28b65fc0702230418g453f2746mbbfb5cfdb0353f18@mail.gmail.com>

On 2/22/07, Roy Satterfield <roys at okabashi.com> wrote:

> [FATAL] failed to allocate memory

Login via SSH as the user your mongrels are running as.

What does the command 'ulimit -a' report? There may be resource limits in place.

If that's not it, you probably have very little (or no) swap, and
really are running out of RAM. As Zed said, 184mb really isn't enough,
especially if you also have a database server on there.

- Ben

From peter.boling at gmail.com  Fri Feb 23 14:09:05 2007
From: peter.boling at gmail.com (Peter Boling)
Date: Fri, 23 Feb 2007 14:09:05 -0500
Subject: [Mongrel] Problems getting mongrel service working
Message-ID: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>

Hello list!

I have mongrel service 0.1.0 working on my current production machine.
 Upgrading to a new server and also moving to mongrel service 0.3.1
has not worked yet.  I am hoping someone will have an idea as to why.

I have mongrel installed properly (I think):
C:\rails\igacc>gem list --local

*** LOCAL GEMS ***
...

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

mongrel_service (0.3.1)
    Mongrel Native Win32 Service Plugin for Rails (debug build)

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

...

I install the service correctly (I think):

C:\rails\igacc>mongrel_rails service::install -N callcenter -p 4001 -e
production -c "C:\rails\igacc" -r "C:\rails\igacc" -l
"log/mongrel.log" -P "log/mongrel.pid" -t 0 -n 1024 -a "http://localhost:4001"
Mongrel service 'callcenter' installed as 'callcenter'.

I attempt to start the service correctly (I think):

C:\rails\igacc>net start callcenter
The callcenter service is starting.
The callcenter service could not be started.

The service did not report an error.

More help is available by typing NET HELPMSG 3534.

I appear to have a working setup.  When I start mongrel_rails I get a
working site:

C:\rails\igacc>mongrel_rails start -p 4001 -e production
** Starting Mongrel listening at 0.0.0.0:4001
** Starting Rails with production environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  INT => stop (no restart).
** Mongrel available at 0.0.0.0:4001
** Use CTRL-C to stop.

Ruby looks good:

C:\rails\igacc>ruby -v
ruby 1.8.5 (2006-08-25) [i386-mswin32]

C:\rails\igacc>irb
irb(main):001:0> exit

My program loads in the console fine:

C:\rails\igacc>ruby script/console production
Loading production environment.
>> exit

Any ideas? I am stumped.

-- 
(**********************************************************
* l*eter H. l3oling
* Web Application Designer - PanEther, LLC
* email:      peter.boling at gmail.com
* blog:        http://galtzo.blogspot.com/
* languages:  English, Spanish, Portuguese
***********************************************************)

From jaywhy at gmail.com  Fri Feb 23 15:33:49 2007
From: jaywhy at gmail.com (Jason Yates)
Date: Fri, 23 Feb 2007 15:33:49 -0500
Subject: [Mongrel] cluster with environment variables
Message-ID: <4cbfccd70702231233g5b4defdy80981ae109c7d0d5@mail.gmail.com>

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

From bradley at railsmachine.com  Fri Feb 23 22:23:39 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Fri, 23 Feb 2007 22:23:39 -0500
Subject: [Mongrel] [ANN] Mongrel Cluster 1.0.1.1 Prerelease: Healing power
	of the pack!
Message-ID: <45DFAFBB.7080503@railsmachine.com>

Hello all...

I know its been a while since the last one, but a new prerelease is 
available with a gratuitous increase in version numbers!

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

This one has some new features in it that need to be tested on all unix 
platforms. Please run --clean and cluster::status on every *nix you can 
find. I run linux so the rest are up to you.

Thanks to the following for patches, bug reports, and suggestions:
Corey Donahue, Matt Trott, Donnie Jones, Matte Edens, Joey Geiger, 
Nathan Vack, and others.

New Features:

* The cluster::start, stop and restart commands now support --clean. On 
start, any orphaned pid_files will be removed and any missing members 
will be started. Running members will be ignored. On stop, orphaned 
members (with missing pids) will be killed. On restart, --clean will be 
passed to stop and start. Feel the healing power of the pack!

* cluster::status - Reports the status of the cluster members with 
respect to pid_file and the existence of the process. Returns 0 if ok, 2 
if not.

* --only PORT - run a command only a specific port.

* Capistrano - added variables for the mongrel_rails path, pid_file, 
log_file, clean, and a task for status.

* The init.d script (resources/mongrel_cluster) will now create
/var/run/mongrel_cluster and chown to a defined user on start (see 
file). To fully use this feature, update your cluster yml files to store 
the pidfile in /var/run/mongrel_cluster. This will support cleaning up 
orphaned pidfiles at boot time. For example:
pid_file: /var/run/mongrel_cluster/foo.pid

Changes/Fixes:

* Each mongrel_rails process now has its own log file.
* Improved parsing of log_file and pid_file filenames to support "." in 
the names.
* start/stop messages for each port
* Fixed a parameter bug with mongrel_cluster_ctl calling mongrel_rails.
* Default pid_file is now "tmp/pids/mongrel.pid" to match Rails rake 
tasks. NOTE: I recommend using /var/run/mongrel_cluster so pids are 
properly cleaned up after a crash.

How does it work?

## check status of your cluster
[me at fluxura ~]$ mongrel_rails cluster::status -C 
/etc/mongrel_cluster/fluxura.conf
found pid_file: /var/run/mongrel_cluster/fluxura.8000.pid
mongrel_rails (port: 8000, pid:27286) is running...

found pid_file: /var/run/mongrel_cluster/fluxura.8001.pid
mongrel_rails (port: 8001, pid:27289) is running...

## simulate process death
[me at fluxura ~]$ kill -9 27289

## uh-oh
[me at fluxura ~]$ mongrel_rails cluster::status -C 
/etc/mongrel_cluster/fluxura.conf
found pid_file: /var/run/mongrel_cluster/fluxura.8000.pid
mongrel_rails (port: 8000, pid:27286) is running...

found pid_file: /var/run/mongrel_cluster/fluxura.8001.pid
!! mongrel_rails (port: 8001) is not running...

## start --clean ignores the good process, removes orphaned pid_file,
## and starts new process. healing pack power!
[me at fluxura ~]$ mongrel_rails cluster::start --clean -C 
/etc/mongrel_cluster/fluxura.conf
already started port 8000
missing process: removing /var/run/mongrel_cluster/fluxura.8001.pid
starting port 8001

Give it a go and let me know...

Regards,
Bradley Taylor
http://railsmachine.com


From pete at nextengine.com  Sat Feb 24 00:04:19 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Fri, 23 Feb 2007 21:04:19 -0800
Subject: [Mongrel]  Upload progress size incorrect
In-Reply-To: <45DFAFBB.7080503@railsmachine.com>
References: <45DFAFBB.7080503@railsmachine.com>
Message-ID: <3E34A662-87BF-4FEE-B44B-B953F2119BF6@nextengine.com>

Hi guys,

I've hooked mongrel_upload_progress into our application, and it's  
working now, but I noticed what might be a small bug.

The size of the file as reported by Mongrel is slightly bigger than  
the actual file size (both on the source computer + when it's stored  
on the server).

This difference varies slightly each time, but seems to be in the  
neighborhood of 420 - 486 extra bytes.  My guess is that when Mongrel  
calculates the file size to give to upload progress, it doesn't strip  
out the HTTP header.

Here's the code snippet for the upload progress gem where the issue  
seems to be.  The content length is returning the wrong number.

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

   ...

   def request_begins(params)
     upload_notify(:add, params, params 
[Mongrel::Const::CONTENT_LENGTH].to_i)
   end

I use this file size to ensure the upload completed successfully, but  
I have a workaround.  I'm doing Flash based upload, and I can get the  
file size from Flash and send it to the server before the upload  
starts.  But the all-server-side approach seems cleaner and more  
portable.

Small bug aside... this is a really cool gem ... it's letting me  
upload a file from one client and show the progress of the upload to  
other clients as they wait for the file.

-Pete

------
Pete DeLaurentis
Lead Software Engineer
NextEngine, Inc.
pete at nextengine.com




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

From luislavena at gmail.com  Sat Feb 24 00:45:50 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 24 Feb 2007 02:45:50 -0300
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
Message-ID: <71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>

On 2/23/07, Peter Boling <peter.boling at gmail.com> wrote:
> Hello list!
>

Welcome to the list!

> I have mongrel service 0.1.0 working on my current production machine.
>  Upgrading to a new server and also moving to mongrel service 0.3.1
> has not worked yet.  I am hoping someone will have an idea as to why.
>
> I have mongrel installed properly (I think):
> C:\rails\igacc>gem list --local
>
> *** LOCAL GEMS ***
> ...
>
> mongrel (1.0.1)
>     A small fast HTTP library and server that runs Rails, Camping, Nitro
>     and Iowa apps.
>
> mongrel_service (0.3.1)
>     Mongrel Native Win32 Service Plugin for Rails (debug build)
>
> rails (1.2.2, 1.2.1)
>     Web-application framework with template engine, control-flow layer,
>     and ORM.
>
> ...
>
> I install the service correctly (I think):
>
> C:\rails\igacc>mongrel_rails service::install -N callcenter -p 4001 -e
> production -c "C:\rails\igacc" -r "C:\rails\igacc" -l
> "log/mongrel.log" -P "log/mongrel.pid" -t 0 -n 1024 -a "http://localhost:4001"
> Mongrel service 'callcenter' installed as 'callcenter'.
>

Ok, you didn't install it properly.

-a takes an "address" parameter, some IP to bind to, like 127.0.0.1
(which is localhost) or, if you don't provide it, will bind to any
available IP in your system (that's why mongrel report 0.0.0.0)

Instead, you supplied a URL, which is not valid.


> I attempt to start the service correctly (I think):
>
> C:\rails\igacc>net start callcenter
> The callcenter service is starting.
> The callcenter service could not be started.
>
> The service did not report an error.
>
> More help is available by typing NET HELPMSG 3534.
>
> I appear to have a working setup.  When I start mongrel_rails I get a
> working site:
>
> C:\rails\igacc>mongrel_rails start -p 4001 -e production
> ** Starting Mongrel listening at 0.0.0.0:4001
> ** Starting Rails with production environment...
> ** Rails loaded.
> ** Loading any Rails specific GemPlugins
> ** Signals ready.  INT => stop (no restart).
> ** Mongrel available at 0.0.0.0:4001
> ** Use CTRL-C to stop.
>

When you started mongrel "manually", you didn't supplied all the
parameters you used during installation of the service.

If you try to start mongrel_rails with these parameters, you will get an error.

mongrel_rails start -p 4001 -e production -c "C:\rails\igacc" -r
"C:\rails\igacc" -t 0 -n 1024 -a "http://localhost:4001"


> Ruby looks good:
>
> C:\rails\igacc>ruby -v
> ruby 1.8.5 (2006-08-25) [i386-mswin32]
>
> C:\rails\igacc>irb
> irb(main):001:0> exit
>
> My program loads in the console fine:
>
> C:\rails\igacc>ruby script/console production
> Loading production environment.
> >> exit
>
> Any ideas? I am stumped.
>

I'll also suggest you add fastthread (mswin32) gem too:

gem install fastthread


-- 
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 jcfischer at gmail.com  Sat Feb 24 19:49:44 2007
From: jcfischer at gmail.com (Jens-Christian Fischer)
Date: Sun, 25 Feb 2007 01:49:44 +0100
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
Message-ID: <FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>

I have the same problems:

C:\Documents and Settings\Administrator>mongrel_rails start -c "c: 
\Program Files
\xxx\xxx" -p 3000 -e production
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with production environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  INT => stop (no restart).
** Mongrel available at 0.0.0.0:3000
** Use CTRL-C to stop.
** INT signal received.
Terminate batch job (Y/N)? y

 >> At this point the application runs without problems

C:\Documents and Settings\Administrator>mongrel_service console  
single -c "C:\Pr
ogram Files\xxx\xxx" -p 3000 -e production -a 127.0.0.1 -B
Mongrel Win32 Service, version 0.3.1
(c) 2006 The Mongrel development team.

Starting service 'single' in console mode, please wait...
Service is in running state.
Press Ctrl-C to stop it.
Stop signal received, stopping...
Waiting for onStart() to exit...
Service stopped, doing cleanup.
Done.

 >> The application is not running - no log files generated

C:\Documents and Settings\Administrator>mongrel_rails service::remove  
-N xxx

xxx service removed.

C:\Documents and Settings\Administrator>mongrel_rails  
service::install -N xxx
-c "C:\Program Files\xxx\xxx" -p 3000 -e production -a 127.0.0.1 -
B -l log -p log
Mongrel service 'xxx' installed as 'xxx'.

C:\Documents and Settings\Administrator>net start xxx
The xxx service is starting.
The xxx service could not be started.

The service did not report an error.

More help is available by typing NET HELPMSG 3534.

 >> And of course no running service either...

Installed Gems:

fastthread (0.6.4.1)
gem_plugin (0.2.2)
mongrel (1.0.1)
mongrel_service (0.3.1)
win32-service (0.5.2)

and Rails 1.1.6

This is Windows 2003 Server

Any ideas?


thanks
Jens-Christian



From luislavena at gmail.com  Sun Feb 25 11:44:54 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 25 Feb 2007 13:44:54 -0300
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
	<FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
Message-ID: <71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>

On 2/24/07, Jens-Christian Fischer <jcfischer at gmail.com> wrote:
> I have the same problems:
>
> C:\Documents and Settings\Administrator>mongrel_rails start -c "c:
> \Program Files
> \xxx\xxx" -p 3000 -e production
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Starting Rails with production environment...
> ** Rails loaded.
> ** Loading any Rails specific GemPlugins
> ** Signals ready.  INT => stop (no restart).
> ** Mongrel available at 0.0.0.0:3000
> ** Use CTRL-C to stop.
> ** INT signal received.
> Terminate batch job (Y/N)? y
>
>  >> At this point the application runs without problems
>
> C:\Documents and Settings\Administrator>mongrel_service console
> single -c "C:\Pr
> ogram Files\xxx\xxx" -p 3000 -e production -a 127.0.0.1 -B
> Mongrel Win32 Service, version 0.3.1
> (c) 2006 The Mongrel development team.
>
> Starting service 'single' in console mode, please wait...
> Service is in running state.
> Press Ctrl-C to stop it.
> Stop signal received, stopping...
> Waiting for onStart() to exit...
> Service stopped, doing cleanup.
> Done.
>
>  >> The application is not running - no log files generated
>

Ok, at this point I should say what previously posted to the list:
test the environment in the same conditions, with the same options!

In your first mongrel_rails call, you let mongrel choose the default
options for you. Under windows isn't possible right now, and debug
information is disabled (by default).

Now, when you tested the "console", you passed -B, debug mode, which
help you pinpoint some leacks of Ruby VM and your application.

In your statement, you said no log files where created, that is true,
but the application works???

> C:\Documents and Settings\Administrator>mongrel_rails service::remove
> -N xxx
>
> xxx service removed.
>
> C:\Documents and Settings\Administrator>mongrel_rails
> service::install -N xxx
> -c "C:\Program Files\xxx\xxx" -p 3000 -e production -a 127.0.0.1 -
> B -l log -p log
> Mongrel service 'xxx' installed as 'xxx'.
>

You passed "-l log" which is invalid, since -l expect a file and not a folder.
One important thing: -p is PORT parameter, and you used to pass your
PID (-p log), which will generate some problems, please review you
command parameters.

The service will fail, since if you type that command in plain mongrel_rails:

C:\Program Files\yyyy\zzzz>mongrel_rails start -c "C:\Program
Files\yyyy\zzzz" -p 3000 -e production -a 127.0.0.1 -B -l log -p log

** Starting Mongrel listening at 127.0.0.1:log
** Installing debugging prefixed filters. Look in log/mongrel_debug
for the files.

Its good to know that log port is always available! (sarcasm).

===

If I perform some checkings, I get everything working:

C:\Program Files\yyyy\zzzz>type config\environment.rb
...
# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '1.1.6'
...


C:\Program Files\yyyy\zzzz>type config\database.yml
# SQLite version 3.x
#   gem install sqlite3-ruby
...
production:
  adapter: sqlite3
  database: db/production.sqlite3


# Test WEBrick
C:\Program Files\yyyy\zzzz>ruby script\server webrick -e production
./script/../config/boot.rb:28:Warning: require_gem is obsolete.  Use
gem instead.
=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2007-02-25 13:03:25] INFO  WEBrick 1.3.1
[2007-02-25 13:03:25] INFO  ruby 1.8.4 (2005-12-24) [i386-mswin32]
[2007-02-25 13:03:25] INFO  WEBrick::HTTPServer#start: pid=1396 port=3000

Browsing to the default rails info page:
Ruby version	1.8.4 (i386-mswin32)
RubyGems version	0.9.2
Rails version	1.1.6
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
Application root	C:/Program Files/yyyy/zzzz
Environment	production
Database adapter	sqlite3


# Now running mongrel_rails
C:\Program Files\yyyy\zzzz>mongrel_rails start --help
Usage: mongrel_rails <command> [options]
    -e, --environment ENV            Rails environment to run as
    -p, --port PORT                  Which port to bind to
    -a, --address ADDR               Address to bind to
    -l, --log FILE                   Where to write log messages
    -P, --pid FILE                   Where to write the PID
    -c, --chdir PATH                 Change to dir before starting
(will be expanded)
    -B, --debug                      Enable debugging mode

C:\Program Files\yyyy\zzzz>mongrel_rails start -c "C:\Program
Files\yyyy\zzzz" -p 3000 -e production -a 127.0.0.1
** Starting Mongrel listening at 127.0.0.1:3000
** Starting Rails with production environment...
C:0:Warning: require_gem is obsolete.  Use gem instead.
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  INT => stop (no restart).
** Mongrel available at 127.0.0.1:3000
** Use CTRL-C to stop.

# Browsing to that address:port report me the same results as previosly listed.

# Testing using 'console'
C:\Program Files\yyyy\zzzz>mongrel_service console single -e
production -p 3000 -a 127.0.0.1
Mongrel Win32 Service, version 0.3.1
(c) 2006 The Mongrel development team.

Starting service 'single' in console mode, please wait...
Service is in running state.
Press Ctrl-C to stop it.

# Browsing to the site show me the page, and also got the rails information too.
# Pressing Ctrl-C...

Stop signal received, stopping...
Waiting for onStart() to exit...
Service stopped, doing cleanup.
Done.

# Now install the service.
C:\Program Files\yyyy\zzzz>mongrel_rails service::install -N myservice
-c "C:\Program Files\yyyy\zzzz" -p 3000 -e production -a 127.0.0.1
** Copying native mongrel_service executable...
Mongrel service 'myservice' installed as 'myservice'.

# Verify the Executable Path (ImagePath) installed by service::install:
(Administrative Tools -> Services, locate 'myservice' and get properties):

"C:/Ruby/bin/mongrel_service.exe" single -e production -p 3000 -a
127.0.0.1 -l "log/mongrel.log" -P "log/mongrel.pid" -c "C:/Program
Files/yyyy/zzzz" -t 0 -r "public" -n 1024

# Now start the service.
C:\Program Files\yyyy\zzzz>net start myservice
The myservice service is starting.
The myservice service was started successfully.

# Check if ruby process is actually running:
C:\Program Files\yyyy\zzzz>tasklist /SVC /FI "SERVICES eq myservice"

Image Name                   PID Services
mongrel_service.exe          300 myservice


C:\Program Files\yyyy\zzzz>tasklist /FI "SERVICES eq myservice"

Image Name                   PID Session Name     Session#    Mem Usage
mongrel_service.exe          300 Console                 0      1.452 K


C:\Program Files\yyyy\zzzz>tasklist /FI "IMAGENAME eq ruby.exe"

Image Name                   PID Session Name     Session#    Mem Usage
ruby.exe                    1312 Console                 0     25.796 K


# With Process Explorer [1] you could see that ruby.exe process is a
child process of mongrel_service.exe

# Stopping the service
C:\Program Files\yyyy\zzzz>net stop myservice
The myservice service is stopping.
The myservice service was stopped successfully.


> C:\Documents and Settings\Administrator>net start xxx
> The xxx service is starting.
> The xxx service could not be started.
>

If you get this is because mongrel_service couldn't get ruby and
mongrel_rails to start properly.

Also, PLEASE REMEMBER that the default configuration for a service is
run under NT AUTHORITY\SYSTEM account, and NOT YOUR account.

That could show problems due NTFS permissions in your folders and/or files.

> Installed Gems:
>
> fastthread (0.6.4.1)
> gem_plugin (0.2.2)
> mongrel (1.0.1)
> mongrel_service (0.3.1)
> win32-service (0.5.2)
>
> and Rails 1.1.6
>

I mimic-ed your environment with the same gems, even reinstalled rails 1.1.6 :-)

> This is Windows 2003 Server
>

Tested under Windows XP SP2 and Windows Storage Server 2003 R2 (which
is the same, but optimized for file serving NAS like functionality).

> Any ideas?
>

Please, try perform the comparisons/tests with the same parameters.
Also check permission issues which often show no error but there are
present and brake almost every application "transparently".

Check this thread on Rubyforge about same problems with services under
managed environments:

http://rubyforge.org/forum/forum.php?thread_id=11060&forum_id=5450


[1] http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx


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 jcfischer at gmail.com  Sun Feb 25 17:26:10 2007
From: jcfischer at gmail.com (Jens-Christian Fischer)
Date: Sun, 25 Feb 2007 23:26:10 +0100
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
	<FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
	<71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>
Message-ID: <F07FEFD5-C098-4540-BE38-E3ED4A9D2A0F@gmail.com>

Hi Luis

>
> Ok, at this point I should say what previously posted to the list:
> test the environment in the same conditions, with the same options!

I did :-)

> In your first mongrel_rails call, you let mongrel choose the default
> options for you. Under windows isn't possible right now, and debug
> information is disabled (by default).

ok - thanks, didn't realize that....

> You passed "-l log" which is invalid, since -l expect a file and  
> not a folder.
> One important thing: -p is PORT parameter, and you used to pass your
> PID (-p log), which will generate some problems, please review you
> command parameters.

gnnnn - it was quite late when I tried this - sorry.

>
>
> Also, PLEASE REMEMBER that the default configuration for a service is
> run under NT AUTHORITY\SYSTEM account, and NOT YOUR account.
>
> That could show problems due NTFS permissions in your folders and/ 
> or files.

Users, Adminstrators and SYSTEM have "Full control" over the relevant  
folder.

Ok, some progress:

I removed everything and reinstalled Ruby 1.8.4 (down from 1.8.5)

Even with the correct parameters (I checked, double checked and  
everything) I get the same results:
* mongrel_rails .... -> Application runs
* mongrel_service console single .... -> Can't connect to  
application. I looked at "netstat -a" and no process is bound to port  
3000
* service -> doesn't run

Then on the same machine, I created a brand new application:
 > rails test
 > cd test
 > mongrel_rails start -> Application runs
 > mongrel_service console single -e development -p 3000 -a 127.0.0.1  
-l "log/mongrel.log" -P "log/mongrel.pid" -t 0 -r "public" -n 1024 -c  
"c:\Program Files\xxx\test" -B

And now the application runs....  So there must be something in my  
application that makes it fail, when it's run as a service. Without  
any logfiles, that's pretty difficult to diagnose though...

Any more ideas?

thanks for your help
jc






From luislavena at gmail.com  Sun Feb 25 18:44:48 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 25 Feb 2007 20:44:48 -0300
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <F07FEFD5-C098-4540-BE38-E3ED4A9D2A0F@gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
	<FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
	<71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>
	<F07FEFD5-C098-4540-BE38-E3ED4A9D2A0F@gmail.com>
Message-ID: <71166b3b0702251544x2f9071abpb89e7527e006b430@mail.gmail.com>

On 2/25/07, Jens-Christian Fischer <jcfischer at gmail.com> wrote:
> [...]
>
> Users, Adminstrators and SYSTEM have "Full control" over the relevant
> folder.
>
> Ok, some progress:
>
> I removed everything and reinstalled Ruby 1.8.4 (down from 1.8.5)
>
> Even with the correct parameters (I checked, double checked and
> everything) I get the same results:
> * mongrel_rails .... -> Application runs
> * mongrel_service console single .... -> Can't connect to
> application. I looked at "netstat -a" and no process is bound to port
> 3000
> * service -> doesn't run
>
> Then on the same machine, I created a brand new application:
>  > rails test
>  > cd test
>  > mongrel_rails start -> Application runs
>  > mongrel_service console single -e development -p 3000 -a 127.0.0.1
> -l "log/mongrel.log" -P "log/mongrel.pid" -t 0 -r "public" -n 1024 -c
> "c:\Program Files\xxx\test" -B
>
> And now the application runs....  So there must be something in my
> application that makes it fail, when it's run as a service. Without
> any logfiles, that's pretty difficult to diagnose though...
>

Ok, what are you using in your application? any gems, libs?

Sorry for the logfiles, didn't have time to re implement them in the
new service executable (work was too much the past months).

> Any more ideas?
>

Yeah, download psexec [1] from Sysinternals, and using it start a new
cmd console with stripped rights:

>psexec -l cmd.exe

This will pop a new cmd.exe window, and try starting your application
(mongrel_rails start ...) from it.

That console is the safest console you could get, and would show the
problems since you will be logging to STDOUT :-)


[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 jcfischer at gmail.com  Mon Feb 26 07:28:40 2007
From: jcfischer at gmail.com (Jens-Christian Fischer)
Date: Mon, 26 Feb 2007 13:28:40 +0100
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <71166b3b0702251544x2f9071abpb89e7527e006b430@mail.gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
	<FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
	<71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>
	<F07FEFD5-C098-4540-BE38-E3ED4A9D2A0F@gmail.com>
	<71166b3b0702251544x2f9071abpb89e7527e006b430@mail.gmail.com>
Message-ID: <D2EE3728-4902-413D-996F-B37194626008@gmail.com>

>
>> psexec -l cmd.exe
>
> This will pop a new cmd.exe window, and try starting your application
> (mongrel_rails start ...) from it.
>
> That console is the safest console you could get, and would show the
> problems since you will be logging to STDOUT :-)

we are getting there:

this in a psexec'd shell:

C:\Program Files\xxx\xxxx>mongrel_rails start
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
C:/Program Files/ruby/bin/mongrel_rails: No such file or directory -  
uname
C:/Program Files/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ 
active_record/connection_adapters/abstract_adapter.rb:120:in `log':  
SQLite3::SQLException: SQL logic error or missing database: INSERT  
INTO wantypes ("name", "bandwidth", "latency") VALUES('E1', 2048, 10)  
(ActiveRecord::StatementInvalid)

It seems, that SQLite does not find the database. I get a similar  
error when running the console.

HOWEVER: doing the following works:

 > Wantype.find :all
=> [... array of wantypes ]

while

 >> w = Wantype.create( :name => 'gaga', :bandwidth => 12, :latency  
=> 10)
ActiveRecord::StatementInvalid: SQLite3::SQLException: SQL logic  
error or missing database: INSERT INTO wantypes ("name", "bandwidth",  
"latency") VALUES('gaga', 12, 10)

fails.

That led me to examine the security properties for the log and db  
directory and the db files in it. Giving everybody full access to  
everything makes mongrel_rails start in the psexec shell.

However:
mongrel_service console single -e production -p 3000 -a 127.0.0.1 -l  
"log/mongrel.log" -P "log/mongrel.pid" -t 0 -r "public" -n 1024 -c "c: 
\Program Files\xxx\xxx"

still fails. The server doesn't start, no log or pid files written.

More ideas?

thanks for your help
jc



From gethemant at gmail.com  Mon Feb 26 09:20:07 2007
From: gethemant at gmail.com (hemant)
Date: Mon, 26 Feb 2007 19:50:07 +0530
Subject: [Mongrel] cross thread violation
Message-ID: <fb283d5e0702260620p464b14ache14bccb8ddbae0cb@mail.gmail.com>

recently i noticed in my mongrel log files:

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:374:
[BUG] cross-thread violation on rb_thread_schedule()
ruby 1.8.4 (2005-12-24) [i486-linux]

any ideas why?

With mongrel 1.0.1

-- 
gnufied
-----------
There was only one Road; that it was like a great river: its springs
were at every doorstep, and every path was its tributary.
http://people.inxsasia.com/~hemant

From peter.boling at gmail.com  Mon Feb 26 09:27:15 2007
From: peter.boling at gmail.com (Peter Boling)
Date: Mon, 26 Feb 2007 09:27:15 -0500
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <D2EE3728-4902-413D-996F-B37194626008@gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
	<FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
	<71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>
	<F07FEFD5-C098-4540-BE38-E3ED4A9D2A0F@gmail.com>
	<71166b3b0702251544x2f9071abpb89e7527e006b430@mail.gmail.com>
	<D2EE3728-4902-413D-996F-B37194626008@gmail.com>
Message-ID: <50bd2f960702260627g4246f732vf171965e148eaa50@mail.gmail.com>

Thanks Luis!  Your help solved my problem:

C:\rails\igacc>mongrel_rails start -p 4001 -e production -c
"C:\rails\igacc" -r "C:\rails\igacc" -t 0 -n 1024 -a "127.0.0.1"
** Starting Mongrel listening at 127.0.0.1:4001
** Starting Rails with production environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  INT => stop (no restart).
** Mongrel available at 127.0.0.1:4001
** Use CTRL-C to stop.
** INT signal received.
Terminate batch job (Y/N)? Y

C:\rails\igacc>mongrel_rails service::remove -N callcenter
callcenter service removed.

C:\rails\igacc>mongrel_rails service::install -N callcenter -p 4001 -e
production -c "C:\rails\igacc" -r "C:\rails\igacc" -t
0 -n 1024 -a "127.0.0.1" -l "log/mongrel.log" -P "log/mongrel.pid"
Mongrel service 'callcenter' installed as 'callcenter'.

C:\rails\igacc>net start callcenter
The callcenter service is starting..
The callcenter service was started successfully.

And the app functions normally!
-- 
(**********************************************************
* l*eter H. l3oling
* Web Application Designer - PanEther, LLC
* email:      peter.boling at gmail.com
* blog:        http://galtzo.blogspot.com/
* languages:  English, Spanish, Portuguese
***********************************************************)

From luislavena at gmail.com  Mon Feb 26 09:30:47 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 26 Feb 2007 11:30:47 -0300
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <D2EE3728-4902-413D-996F-B37194626008@gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
	<FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
	<71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>
	<F07FEFD5-C098-4540-BE38-E3ED4A9D2A0F@gmail.com>
	<71166b3b0702251544x2f9071abpb89e7527e006b430@mail.gmail.com>
	<D2EE3728-4902-413D-996F-B37194626008@gmail.com>
Message-ID: <71166b3b0702260630q50bd7d39w398f9f07dd82449b@mail.gmail.com>

On 2/26/07, Jens-Christian Fischer <jcfischer at gmail.com> wrote:
> >
> >> psexec -l cmd.exe
> >
> > This will pop a new cmd.exe window, and try starting your application
> > (mongrel_rails start ...) from it.
> >
> > That console is the safest console you could get, and would show the
> > problems since you will be logging to STDOUT :-)
>
> we are getting there:
>
> this in a psexec'd shell:
>
> C:\Program Files\xxx\xxxx>mongrel_rails start
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Starting Rails with development environment...
> C:/Program Files/ruby/bin/mongrel_rails: No such file or directory -
> uname
> C:/Program Files/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
> active_record/connection_adapters/abstract_adapter.rb:120:in `log':
> SQLite3::SQLException: SQL logic error or missing database: INSERT
> INTO wantypes ("name", "bandwidth", "latency") VALUES('E1', 2048, 10)
> (ActiveRecord::StatementInvalid)
>

That's is good news! (err, well, they are actually).

> It seems, that SQLite does not find the database. I get a similar
> error when running the console.
>

Could you post info of your config/database.yml?
Also, you're using sqlite3-ruby gem? You *really* need this (there are
problems with the Ruby/DL binding of previous versions).

Also, sqlite3.dll must be in the PATH (I prefer put it
windows\system32 since I use with other tools).

Please note that versions higher than 3.3.7 of Sqlite3 have issues
with Rails, only solved in 1.2.2 (in your case didn't apply).

> HOWEVER: doing the following works:
>
>  > Wantype.find :all
> => [... array of wantypes ]
>
> while
>
>  >> w = Wantype.create( :name => 'gaga', :bandwidth => 12, :latency
> => 10)
> ActiveRecord::StatementInvalid: SQLite3::SQLException: SQL logic
> error or missing database: INSERT INTO wantypes ("name", "bandwidth",
> "latency") VALUES('gaga', 12, 10)
>
> fails.
>
> That led me to examine the security properties for the log and db
> directory and the db files in it. Giving everybody full access to
> everything makes mongrel_rails start in the psexec shell.
>
> However:
> mongrel_service console single -e production -p 3000 -a 127.0.0.1 -l
> "log/mongrel.log" -P "log/mongrel.pid" -t 0 -r "public" -n 1024 -c "c:
> \Program Files\xxx\xxx"
>

Since console will run in the current user context (which differ from
psexec env.), I guess the problem is outside mongrel faults, and
specific to your environment... could you contact me via gtalk or msn?
(same username @hotmail.com).

> still fails. The server doesn't start, no log or pid files written.
>

No log or pid will be written, since that functionality isn't set in
the current version... will try to fix that ASAP.

> More ideas?
>

Contact me via IM and we could check whats happening.

-- 
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  Mon Feb 26 10:40:21 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 26 Feb 2007 12:40:21 -0300
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <50bd2f960702260627g4246f732vf171965e148eaa50@mail.gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
	<FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
	<71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>
	<F07FEFD5-C098-4540-BE38-E3ED4A9D2A0F@gmail.com>
	<71166b3b0702251544x2f9071abpb89e7527e006b430@mail.gmail.com>
	<D2EE3728-4902-413D-996F-B37194626008@gmail.com>
	<50bd2f960702260627g4246f732vf171965e148eaa50@mail.gmail.com>
Message-ID: <71166b3b0702260740v1f6a18al50fd69575e316774@mail.gmail.com>

On 2/26/07, Peter Boling <peter.boling at gmail.com> wrote:
> Thanks Luis!  Your help solved my problem:
>

Thats good to know!

Could you share what you changed to get it working? that will help others :-)

< [...]
>
> And the app functions normally!
> --

-- 
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 peter.boling at gmail.com  Mon Feb 26 12:54:32 2007
From: peter.boling at gmail.com (Peter Boling)
Date: Mon, 26 Feb 2007 12:54:32 -0500
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <71166b3b0702260740v1f6a18al50fd69575e316774@mail.gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
	<FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
	<71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>
	<F07FEFD5-C098-4540-BE38-E3ED4A9D2A0F@gmail.com>
	<71166b3b0702251544x2f9071abpb89e7527e006b430@mail.gmail.com>
	<D2EE3728-4902-413D-996F-B37194626008@gmail.com>
	<50bd2f960702260627g4246f732vf171965e148eaa50@mail.gmail.com>
	<71166b3b0702260740v1f6a18al50fd69575e316774@mail.gmail.com>
Message-ID: <50bd2f960702260954r2f14e0b8vbb4aad4ebca87901@mail.gmail.com>

On 2/26/07, Luis Lavena <luislavena at gmail.com> wrote:
> On 2/26/07, Peter Boling <peter.boling at gmail.com> wrote:
> > Thanks Luis!  Your help solved my problem:
>
> Thats good to know!
>
> Could you share what you changed to get it working? that will help others :-)

Your tip on the '-a' parameter fixed it.  That was apparently the
hangup for me.  Once I changed it from a URL ( -a
"http://localhost:4001") to an IP (-a "127.0.0.1") everything worked!
Didn't need the port number in the -a parameter as I had assumed.

-- 
(**********************************************************
* l*eter H. l3oling
* Web Application Designer - PanEther, LLC
* email:      peter.boling at gmail.com
* blog:        http://galtzo.blogspot.com/
* languages:  English, Spanish, Portuguese
***********************************************************)

From jcfischer at gmail.com  Mon Feb 26 13:16:04 2007
From: jcfischer at gmail.com (Jens-Christian Fischer)
Date: Mon, 26 Feb 2007 19:16:04 +0100
Subject: [Mongrel] Problems getting mongrel service working
In-Reply-To: <71166b3b0702260630q50bd7d39w398f9f07dd82449b@mail.gmail.com>
References: <50bd2f960702231109i6fa4fa67jc2369c37d4d3e1ab@mail.gmail.com>
	<71166b3b0702232145q26cc9574g223166b08699a519@mail.gmail.com>
	<FC891407-48C8-48A7-885D-64452B1E29B5@gmail.com>
	<71166b3b0702250844l7384722aucbea41e45e791156@mail.gmail.com>
	<F07FEFD5-C098-4540-BE38-E3ED4A9D2A0F@gmail.com>
	<71166b3b0702251544x2f9071abpb89e7527e006b430@mail.gmail.com>
	<D2EE3728-4902-413D-996F-B37194626008@gmail.com>
	<71166b3b0702260630q50bd7d39w398f9f07dd82449b@mail.gmail.com>
Message-ID: <DF6652B9-E229-4A71-9D09-9AA7219C0C94@gmail.com>

> Could you post info of your config/database.yml?
> Also, you're using sqlite3-ruby gem? You *really* need this (there are
> problems with the Ruby/DL binding of previous versions).

I was using both the sqlit3-ruby gem and the one bundled by _why  
(which includes the DLL). Because I can actually read the DB (and  
write to it, when not running as a service) I don't think that's the  
problem.

Here's my database.yml for good measure:

   development:
     adapter: sqlite3
     dbfile: db/com_prod.db

   test:
     adapter: sqlite3
     dbfile: db/com_test.db

   production:
     adapter: sqlite3
     dbfile: db/com_prod.db

> Since console will run in the current user context (which differ from
> psexec env.), I guess the problem is outside mongrel faults, and
> specific to your environment... could you contact me via gtalk or msn?
> (same username @hotmail.com).

I have added you to my gtalk account.

>
> Contact me via IM and we could check whats happening.
>

I'll catch you :-) Thanks for the help!

cheers jc

From atmos at atmos.org  Mon Feb 26 14:00:38 2007
From: atmos at atmos.org (Corey Donohoe)
Date: Mon, 26 Feb 2007 13:00:38 -0600
Subject: [Mongrel] [ANN] Mongrel Cluster 1.0.1.1 Prerelease: Healing
	power of the pack!
In-Reply-To: <45DFAFBB.7080503@railsmachine.com>
References: <45DFAFBB.7080503@railsmachine.com>
Message-ID: <c75e5f320702261100i61491f94p1705067abcddcbcc@mail.gmail.com>

On 2/23/07, Bradley Taylor <bradley at railsmachine.com> wrote:
>
> Hello all...
>
> I know its been a while since the last one, but a new prerelease is
> available with a gratuitous increase in version numbers!
>
> gem install mongrel_cluster --source
> http://mongrel.rubyforge.org/releases/
>
> * Default pid_file is now "tmp/pids/mongrel.pid" to match Rails rake
> tasks. NOTE: I recommend using /var/run/mongrel_cluster so pids are
> properly cleaned up after a crash.


For what it's worth I had to change my pid file path in my
mongrel_cluster.yml file to make cap deploy happy.  It appears cap calls
restart before relinking the pid directory down into tmp.  If you give the
absolute path to shared/pids in your config file you should be setup.  This
is only if you go against what Bradley advises above. :)

Thanks for the upgrade I can finally ditch my custom tasks. :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070226/8ce75843/attachment.html 

From atmos at atmos.org  Mon Feb 26 14:11:59 2007
From: atmos at atmos.org (Corey Donohoe)
Date: Mon, 26 Feb 2007 13:11:59 -0600
Subject: [Mongrel] teeny mongrel_cluster hack
Message-ID: <c75e5f320702261111w7dba448em2a6efceccaffcde1@mail.gmail.com>

I was playing around with merb over the weekend and whipped up a simple form
that takes your mongrel_cluster.yml file and outputs monit files for you.
Not exactly earth shattering info, but if you have a couple of pups it might
save you some braindead typing.  It's using the new mongrel_cluster syntax,
of --only and clean for each port in your system.  Hope it saves someone
some time.

Site is at http://monitr.atmos.org

__
Corey Donohoe
http://www.atmos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070226/5f92196f/attachment.html 

From chris.collins at fuse.net  Mon Feb 26 15:57:10 2007
From: chris.collins at fuse.net (Chris Collins)
Date: Mon, 26 Feb 2007 14:57:10 -0600
Subject: [Mongrel] unsubscribe
In-Reply-To: <c75e5f320702261100i61491f94p1705067abcddcbcc@mail.gmail.com>
References: <45DFAFBB.7080503@railsmachine.com>
	<c75e5f320702261100i61491f94p1705067abcddcbcc@mail.gmail.com>
Message-ID: <55387338.20070226145710@fuse.net>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070226/0d7693bf/attachment.html 

From kylekochis at gmail.com  Mon Feb 26 16:31:43 2007
From: kylekochis at gmail.com (Kyle Kochis)
Date: Mon, 26 Feb 2007 14:31:43 -0700
Subject: [Mongrel] teeny mongrel_cluster hack
In-Reply-To: <c75e5f320702261111w7dba448em2a6efceccaffcde1@mail.gmail.com>
References: <c75e5f320702261111w7dba448em2a6efceccaffcde1@mail.gmail.com>
Message-ID: <6a7034b0702261331p4059aeb3i6ed4fa386007dfed@mail.gmail.com>

Hey that as nice. Thanks for the work...I'm sure it will save me some time.
Kyle

On 2/26/07, Corey Donohoe <atmos at atmos.org> wrote:
> I was playing around with merb over the weekend and whipped up a simple form
> that takes your mongrel_cluster.yml file and outputs monit files for you.
> Not exactly earth shattering info, but if you have a couple of pups it might
> save you some braindead typing.  It's using the new mongrel_cluster syntax,
> of --only and clean for each port in your system.  Hope it saves someone
> some time.
>
> Site is at http://monitr.atmos.org
>
> __
> Corey Donohoe
> http://www.atmos.org
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From stu at relevancellc.com  Mon Feb 26 18:10:20 2007
From: stu at relevancellc.com (Stuart Halloway)
Date: Mon, 26 Feb 2007 18:10:20 -0500
Subject: [Mongrel] Apache+mod_proxy_balancer+Mongrel+Mephisto,
	Apache kills CPU
Message-ID: <9BDB7DE6-C2C6-4F9A-B4D3-D1282CEEA07C@relevancellc.com>

Our Mephisto install kills Mongrels and causes Apache to pound the  
CPU. This started when we moved to Apache+mod_proxy_balancer+Mongrel.

Here's what we know:
The following things are working OK, except when used in the  
combination listed above: mongrel, mongrel_rails, MySQL, Apache,  
mod_proxy_balancer. We believe these are all OK because we moved five  
other Rails apps to this configuration on the same box, and they are  
working fine.

Here's what we have figured out:
Connecting directly to the mongrel instance works, sort of. It's S L  
O W. Clicking on a monthly blog archive link takes about 5 seconds,  
most of which is spent in the MySQL database. I turned the  
production.log up to debug, and found that Mephisto (0.7.3) makes  
dozens of round trips to build the monthly archive page.

Here's the weird part:
Mephisto is slow but OK until we put Apache in front of the Mongrels.  
Then things go sideways. The mongrels become unresponsive, and  
Apache's CPU usage spikes. A single unresponsive mongrel thread  
causes Apache's utilization to stay about 50% forever, and a few  
dozen of them peg the processor.

Here's some stuff we have explored:
* mod_proxy_balancer vs. ProxyPass to a single Mongrel. Same problem  
either way.
* Monit. Very cool tool for diagnosing the problem, and killing the  
runaway processes. The problem occurs too frequently to just let  
monit bounce everything.
* Apache server status. The trouble requests look like this:
               	    CPU 	                    Client	Request
0-1	4401	0/5/5	R 	30.88	348	0	0.0	0.06	0.06 	?	?	..reading..
Note CPU time is huge. These seem to hang around forever, but the CPU  
gets pegged long before we run out of threads.
* Mongrel -USR1 debugging. Sample thread entry at the bottom of this  
post, nothing out of the ordinary in the other logs.
* Shutdown portion of Mongrel's main log also shown below. Could this  
explain the problem?

The part that mystifies me:
* Why is Mongrel fine without Apache, but not with it?
* When the Mongrels start to suffer, why does Apache's CPU usage peg?  
I would expect Apache's threads to have about 0% CPU utilization  
while waiting on a struggling Mongrel.

I am happy to try other experiments anyone might suggest, or to  
provide more detail from other logs.

Thanks,
Stuart Halloway
www.relevancellc.com

[Environment]
Mac OS X
Mephisto 0.7.3
Most recent version of all gems (nothing on edge)

[Excerpt from threads.log]
Mon Feb 26 14:37:16 PST 2007 REQUEST /archives/2006/5
0.0.0.0:8111 -- THREADS: 3 -----
         KEYS:
                 -- #<Thread:0x35e4030>: [:__inspect_key__, :started_on]
                 -- #<Thread:0x36f8c78>: [:__inspect_key__, :started_on]
                 -- #<Thread:0x35e352c>: [:__inspect_key__, :started_on]

[Excerpt from mongrel.log when killing unresponsive mongrels]
** TERM signal received.
Mon Feb 26 14:37:06 PST 2007: Reaping 3 threads for slow workers  
because of 'shutdown'
Waiting for 3 requests to finish, could take 60 seconds.object.log  
ERROR: undefined method `class' for #<Liquid::Strainer:0x3132ba4>
object.log ERROR: undefined method `class' for #<Liquid::Strainer: 
0x3132ba4>
Mon Feb 26 14:37:13 PST 2007: Reaping 3 threads for slow workers  
because of 'shutdown'
Waiting for 3 requests to finish, could take 60 seconds.object.log  
ERROR: undefined method `class' for #<Liquid::Strainer:0x3132ba4>
Mon Feb 26 14:37:20 PST 2007: Reaping 3 threads for slow workers  
because of 'shutdown'
Waiting for 3 requests to finish, could take 60 seconds.Mon Feb 26  
14:37:30 PST 2007: Reaping 3 threads for slow workers because of  
'shutdown'
Waiting for 3 requests to finish, could take 60 seconds.Mon Feb 26  
14:37:36 PST 2007: Reaping 2 threads for slow workers because of  
'shutdown'




From roy.nicholson at usermail.com  Mon Feb 26 22:34:08 2007
From: roy.nicholson at usermail.com (Roy Nicholson)
Date: Mon, 26 Feb 2007 22:34:08 -0500
Subject: [Mongrel] Apache+mod_proxy_balancer+Mongrel+Mephisto,
 Apache kills CPU
In-Reply-To: <9BDB7DE6-C2C6-4F9A-B4D3-D1282CEEA07C@relevancellc.com>
References: <9BDB7DE6-C2C6-4F9A-B4D3-D1282CEEA07C@relevancellc.com>
Message-ID: <45E3A6B0.3050304@usermail.com>

Hi Stu,

What version of apache httpd is this? 2.2.x?

Is httpd serving static content with no issue?

Anything strange in your httpd errors log?

What does your proxy balancer config look like?

ie should be something like:

<Proxy balancer://my_mongrels>
  BalancerMember http://<some_ip>:<some_port>
  ...
</Proxy>

Got any rewrite rules defined?

What modules are compiled in? (httpd -l)

Is there a particular request that causes the issue? or is it the first
request with apache that causes everything to 'go sideways'?

If you're really out of options one other thing to try is to hook in a
traffic sniffer between apache and mongrel (like TCPmon) and look at the
requests/responses between the two. Perhaps mongrel is returning
something apache doesn't like? or vise versa...

-Roy

Stuart Halloway wrote:
> Our Mephisto install kills Mongrels and causes Apache to pound the  
> CPU. This started when we moved to Apache+mod_proxy_balancer+Mongrel.
>
> Here's what we know:
> The following things are working OK, except when used in the  
> combination listed above: mongrel, mongrel_rails, MySQL, Apache,  
> mod_proxy_balancer. We believe these are all OK because we moved five  
> other Rails apps to this configuration on the same box, and they are  
> working fine.
>
> Here's what we have figured out:
> Connecting directly to the mongrel instance works, sort of. It's S L  
> O W. Clicking on a monthly blog archive link takes about 5 seconds,  
> most of which is spent in the MySQL database. I turned the  
> production.log up to debug, and found that Mephisto (0.7.3) makes  
> dozens of round trips to build the monthly archive page.
>
> Here's the weird part:
> Mephisto is slow but OK until we put Apache in front of the Mongrels.  
> Then things go sideways. The mongrels become unresponsive, and  
> Apache's CPU usage spikes. A single unresponsive mongrel thread  
> causes Apache's utilization to stay about 50% forever, and a few  
> dozen of them peg the processor.
>
> Here's some stuff we have explored:
> * mod_proxy_balancer vs. ProxyPass to a single Mongrel. Same problem  
> either way.
> * Monit. Very cool tool for diagnosing the problem, and killing the  
> runaway processes. The problem occurs too frequently to just let  
> monit bounce everything.
> * Apache server status. The trouble requests look like this:
>                	    CPU 	                    Client	Request
> 0-1	4401	0/5/5	R 	30.88	348	0	0.0	0.06	0.06 	?	?	..reading..
> Note CPU time is huge. These seem to hang around forever, but the CPU  
> gets pegged long before we run out of threads.
> * Mongrel -USR1 debugging. Sample thread entry at the bottom of this  
> post, nothing out of the ordinary in the other logs.
> * Shutdown portion of Mongrel's main log also shown below. Could this  
> explain the problem?
>
> The part that mystifies me:
> * Why is Mongrel fine without Apache, but not with it?
> * When the Mongrels start to suffer, why does Apache's CPU usage peg?  
> I would expect Apache's threads to have about 0% CPU utilization  
> while waiting on a struggling Mongrel.
>
> I am happy to try other experiments anyone might suggest, or to  
> provide more detail from other logs.
>
> Thanks,
> Stuart Halloway
> www.relevancellc.com
>
> [Environment]
> Mac OS X
> Mephisto 0.7.3
> Most recent version of all gems (nothing on edge)
>
> [Excerpt from threads.log]
> Mon Feb 26 14:37:16 PST 2007 REQUEST /archives/2006/5
> 0.0.0.0:8111 -- THREADS: 3 -----
>          KEYS:
>                  -- #<Thread:0x35e4030>: [:__inspect_key__, :started_on]
>                  -- #<Thread:0x36f8c78>: [:__inspect_key__, :started_on]
>                  -- #<Thread:0x35e352c>: [:__inspect_key__, :started_on]
>
> [Excerpt from mongrel.log when killing unresponsive mongrels]
> ** TERM signal received.
> Mon Feb 26 14:37:06 PST 2007: Reaping 3 threads for slow workers  
> because of 'shutdown'
> Waiting for 3 requests to finish, could take 60 seconds.object.log  
> ERROR: undefined method `class' for #<Liquid::Strainer:0x3132ba4>
> object.log ERROR: undefined method `class' for #<Liquid::Strainer: 
> 0x3132ba4>
> Mon Feb 26 14:37:13 PST 2007: Reaping 3 threads for slow workers  
> because of 'shutdown'
> Waiting for 3 requests to finish, could take 60 seconds.object.log  
> ERROR: undefined method `class' for #<Liquid::Strainer:0x3132ba4>
> Mon Feb 26 14:37:20 PST 2007: Reaping 3 threads for slow workers  
> because of 'shutdown'
> Waiting for 3 requests to finish, could take 60 seconds.Mon Feb 26  
> 14:37:30 PST 2007: Reaping 3 threads for slow workers because of  
> 'shutdown'
> Waiting for 3 requests to finish, could take 60 seconds.Mon Feb 26  
> 14:37:36 PST 2007: Reaping 2 threads for slow workers because of  
> 'shutdown'
>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   


From tomawng at yahoo.fr  Tue Feb 27 00:48:21 2007
From: tomawng at yahoo.fr (tom wang)
Date: Tue, 27 Feb 2007 06:48:21 +0100 (CET)
Subject: [Mongrel] Deployement options
Message-ID: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>

After reading the digital shortcut and the
documentation on the web site I'm confused.
Which one should I use? pen, balance or nginx ?

I don't want to use a behemoth like appache and ssl is
not needed so it reduces my choice to those three
only....

What are the pros and cons of each? I don't have much
money, so the less ressources I use the better it is
for me....

As an additional question, how far would a one server
configuration get me? I'm going to be serving a lot of
pictures and have some simple treatment of photos
(resizing and such)


	

	
		
___________________________________________________________________________ 
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 abstractryan at gmail.com  Tue Feb 27 02:01:41 2007
From: abstractryan at gmail.com (Ryan)
Date: Tue, 27 Feb 2007 01:01:41 -0600
Subject: [Mongrel] Threshold of mongrel node processes
Message-ID: <45E3D755.60801@gmail.com>

Hi all:

New to the list. Im enjoying mongrel. Coming from a background of 
weblogic clusters this is a dream. However I have a few questions:

I have used HTTPerf to analyze metrics for an application ( rails ). My 
question pertains to the CPU utilization threshold:

1) Test with single mongrel server : sustained cpu util @ 98%

2) Test with 2 mongrel nodes in a mongrel cluster with apache and proxy 
balancer: Each node sustained cpu util @ app. 45%

3) Test with 3 mongrel nodes in a mongrel cluster with apache and proxy 
balancer: Each node sustained cpu util @ app 30%

As you can see it appears the the mongrel nodes on this server are going 
for max cpu utilization.

My questions are these:

1) Is this normal behavior for mongrel?
2) Is there way to configure mongrel to only go after a threshold or 
percentage of max cpu utilization?

thanks for any help!
Ryan

From niall at makalumedia.com  Tue Feb 27 04:05:49 2007
From: niall at makalumedia.com (Niall O Broin)
Date: Tue, 27 Feb 2007 09:05:49 +0000
Subject: [Mongrel] send_file and ZIP files
Message-ID: <39F6B447-FBF0-4CEA-813D-65089D6648D4@makalumedia.com>

I have an application which uses send_file to send a ZIP file to the  
client. This works nicely when it's run on our development OS-X  
boxes, using mongrel from script/server, but on our production  
server, using mongrel behind Apache 2.2. with mod_proxy_balancer, the  
client gets 1 byte delivered :-(

If I use wget -S to the URL in order to see the full headers I see  
this on production

HTTP request sent, awaiting response...
   HTTP/1.1 500 Internal Server Error
   Date: Tue, 27 Feb 2007 08:52:54 GMT
   Server: Mongrel 1.0.1
   Status: 500 Error
   Content-Transfer-Encoding: binary
   Cache-Control: private
   Content-Disposition: attachment; filename="somefile.zip"
   Content-Type: */*
   Content-Length: 1
   Set-Cookie: _my_session_id=a65e09ab923208a4404893f2d3709196; path=/
   Via: 1.0 www.myhost.com
   Connection: close
08:52:54 ERROR 500: Internal Server Error.

whereas on the development servers I see

HTTP request sent, awaiting response...
   HTTP/1.1 200 OK
   Connection: close
   Date: Tue, 27 Feb 2007 08:55:40 GMT
   Set-Cookie: _my_session_id=e8e877a3c0ae65386306e745df50b124; path=/
   Status: 200 OK
   Content-Transfer-Encoding: binary
   Cache-Control: private
   Content-Disposition: attachment; filename="somefile.zip"
   Server: Mongrel 1.0.1
   Content-Type: application/zip
   Content-Length: 3698448
Length: 3,698,448 (3.5M) [application/zip]

I rather suspect that the problem may be related to the  Content- 
Type:  header which is correctly set on the development box, but yet  
is set to */* for some reason on production.

The code which is called is this

send_file @tour.zip_files, :filename => "# 
{@tour.filename}.zip", :type => 'application/zip'

where @tour.zip_files is a method which writes the ZIP file, and  
returns a path to it. This is working on the production box, insofar  
as it does write the ZIP files.

A smaller problem, though it will be an issue in production, is that  
the filename saved was not the filename specified in the  Content- 
Disposition  but rather the filename in the URL which is something  
different.



Kindest regards,



Niall  O Broin



From zedshaw at zedshaw.com  Tue Feb 27 10:10:03 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 27 Feb 2007 07:10:03 -0800
Subject: [Mongrel] Deployement options
In-Reply-To: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
Message-ID: <20070227071003.a8d6957d.zedshaw@zedshaw.com>

On Tue, 27 Feb 2007 06:48:21 +0100 (CET)
tom wang <tomawng at yahoo.fr> wrote:

> After reading the digital shortcut and the
> documentation on the web site I'm confused.
> Which one should I use? pen, balance or nginx ?
> 
> I don't want to use a behemoth like appache and ssl is
> not needed so it reduces my choice to those three
> only....

I'd go with nginx since it's about as difficult to compile and install
as pen and balance, and isn't too hard to configure.
 
> What are the pros and cons of each? I don't have much
> money, so the less ressources I use the better it is
> for me....
> 
> As an additional question, how far would a one server
> configuration get me? I'm going to be serving a lot of
> pictures and have some simple treatment of photos
> (resizing and such)

You can't know until you try.  Just start off with one server, then add
as you need.

-- 
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.

From joost at spacebabies.nl  Tue Feb 27 07:58:17 2007
From: joost at spacebabies.nl (joost baaij)
Date: Tue, 27 Feb 2007 13:58:17 +0100
Subject: [Mongrel] send_file and ZIP files
In-Reply-To: <39F6B447-FBF0-4CEA-813D-65089D6648D4@makalumedia.com>
References: <39F6B447-FBF0-4CEA-813D-65089D6648D4@makalumedia.com>
Message-ID: <E2803D14-5426-4AA1-AA45-029A422DF171@spacebabies.nl>

Your production Mongrel is generating an error (500 Internal Server  
Error).
Check your log/production.log where the error will be printed.

Op 27-feb-2007, om 10:05 heeft Niall O Broin het volgende geschreven:

> I have an application which uses send_file to send a ZIP file to the
> client. This works nicely when it's run on our development OS-X
> boxes, using mongrel from script/server, but on our production
> server, using mongrel behind Apache 2.2. with mod_proxy_balancer, the
> client gets 1 byte delivered :-(
>
> If I use wget -S to the URL in order to see the full headers I see
> this on production
>
> HTTP request sent, awaiting response...
>    HTTP/1.1 500 Internal Server Error
>    Date: Tue, 27 Feb 2007 08:52:54 GMT
>    Server: Mongrel 1.0.1
>    Status: 500 Error
>    Content-Transfer-Encoding: binary
>    Cache-Control: private
>    Content-Disposition: attachment; filename="somefile.zip"
>    Content-Type: */*
>    Content-Length: 1
>    Set-Cookie: _my_session_id=a65e09ab923208a4404893f2d3709196; path=/
>    Via: 1.0 www.myhost.com
>    Connection: close
> 08:52:54 ERROR 500: Internal Server Error.
>
> whereas on the development servers I see
>
> HTTP request sent, awaiting response...
>    HTTP/1.1 200 OK
>    Connection: close
>    Date: Tue, 27 Feb 2007 08:55:40 GMT
>    Set-Cookie: _my_session_id=e8e877a3c0ae65386306e745df50b124; path=/
>    Status: 200 OK
>    Content-Transfer-Encoding: binary
>    Cache-Control: private
>    Content-Disposition: attachment; filename="somefile.zip"
>    Server: Mongrel 1.0.1
>    Content-Type: application/zip
>    Content-Length: 3698448
> Length: 3,698,448 (3.5M) [application/zip]
>
> I rather suspect that the problem may be related to the  Content-
> Type:  header which is correctly set on the development box, but yet
> is set to */* for some reason on production.
>
> The code which is called is this
>
> send_file @tour.zip_files, :filename => "#
> {@tour.filename}.zip", :type => 'application/zip'
>
> where @tour.zip_files is a method which writes the ZIP file, and
> returns a path to it. This is working on the production box, insofar
> as it does write the ZIP files.
>
> A smaller problem, though it will be an issue in production, is that
> the filename saved was not the filename specified in the  Content-
> Disposition  but rather the filename in the URL which is something
> different.
>
>
>
> Kindest regards,
>
>
>
> Niall  O Broin
>
>
> _______________________________________________
> 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/20070227/3635a6d5/attachment.bin 

From jeremy at bitsweat.net  Tue Feb 27 08:25:47 2007
From: jeremy at bitsweat.net (Jeremy Kemper)
Date: Tue, 27 Feb 2007 05:25:47 -0800
Subject: [Mongrel] send_file and ZIP files
In-Reply-To: <39F6B447-FBF0-4CEA-813D-65089D6648D4@makalumedia.com>
References: <39F6B447-FBF0-4CEA-813D-65089D6648D4@makalumedia.com>
Message-ID: <69a2885c0702270525o2b31203ax8d7c95e68a610265@mail.gmail.com>

On 2/27/07, Niall O Broin <niall at makalumedia.com> wrote:
>
> I have an application which uses send_file to send a ZIP file to the
> client. This works nicely when it's run on our development OS-X
> boxes, using mongrel from script/server, but on our production
> server, using mongrel behind Apache 2.2. with mod_proxy_balancer, the
> client gets 1 byte delivered :-(


Niall, what is the error logged when you get a 500 status in production?

In any case, your best bet is to use the X-Sendfile header to tell Apache
which file path to send. Streaming files from Rails means your Mongrel
process is tied up for the duration -- no good. See
http://wiki.rubyonrails.org/rails/pages/HowtoSendFilesFast for more on how
to use Apache's mod_xsendfile.

Best,
jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070227/9185da37/attachment-0001.html 

From alexey.verkhovsky at gmail.com  Tue Feb 27 08:45:29 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 27 Feb 2007 07:45:29 -0600
Subject: [Mongrel] Threshold of mongrel node processes
In-Reply-To: <45E3D755.60801@gmail.com>
References: <45E3D755.60801@gmail.com>
Message-ID: <3945c4270702270545k503fe81axe061ea6badcb94d2@mail.gmail.com>

> 1) Is this normal behavior for mongrel?
Not really.

First of all, it's hardly about Mongrel, which is rather light on CPU time.
More likely than not 95 out of those 98% CPU spends within your app code
(that runs on the same ruby process as Mongrel).

Normal CPU utilization profile includes significant amount of database work
(30 to 70%). Unless your Rails app uses SQLite (an in process database), or
doesn't use database at all, you should see some CPU (20 to 70%) utilized by
mysqld.

Make sure that you did change Rails environment to production with -e
production option.

> 2) Is there way to configure mongrel to only go after a threshold or
percentage of max cpu utilization?
No, not within Mongrel. You shouldn't need it.

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

From wyhaines at gmail.com  Tue Feb 27 09:25:55 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 27 Feb 2007 07:25:55 -0700
Subject: [Mongrel] Deployement options
In-Reply-To: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
Message-ID: <f4cd26df0702270625k1f2dc1cel99734ec37adfb114@mail.gmail.com>

On 2/26/07, tom wang <tomawng at yahoo.fr> wrote:

> As an additional question, how far would a one server
> configuration get me? I'm going to be serving a lot of
> pictures and have some simple treatment of photos
> (resizing and such)

I think that depends on a lot of unnamed factors.  What kind of
server?  What framework?

I serve 65 commercial sites and applications, with potential
throughputs on dynamic traffic as high as 350 requests/second on an
older dual AMD processor based Linux box with 2gb of RAM, and a number
of those sites are using Mongrel processes for their backend.  I don't
use Rails, though, so your mileage will probably vary quite a lot from
that if you do.


Kirk Haines

From bhjackson at gmail.com  Tue Feb 27 09:40:23 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Tue, 27 Feb 2007 11:40:23 -0300
Subject: [Mongrel] Mongrel upload progress not showing progress on
	production server
Message-ID: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>

Hi all,

Tried out the mongrel upload progress plugin with Drb and it works
great on my OSX development box, but when putting it into production
(Ubuntu Dapper), uploads complete but the app isn't returning any
values for upload progress, and uploads are not showing up in the
queue when running upload_client.rb. Before anyone asks, yes, I'm
running both the mongrel instances and the upload.rb script.

Below are the relevant log entries and code snippets. Thanks!

data_file.rb:

?

  def progress
    warn 'progress'
    render :update do |page|
      warn 'update'
      @status = Mongrel::Uploads.check(params[:upload_id])
      warn @status.inspect
      page.upload_progress.update(@status[:size], @status[:received]) if @status
    end
  end

?

mongrel.log:

...
progress
update
nil
progress
update
nil
progress
update
nil
?

production.log:

Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
22:16:29) [POST]
  Parameters: {"action"=>"progress", "controller"=>"data_files",
"upload_id"=>"1172268962"}
Completed in 0.00706 (141 reqs/sec) | Rendering: 0.00667 (94%) | 200
OK [http://central.incomumdesign.com/files/progress?upload_id=1172268962]


Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
22:16:29) [POST]
  Parameters: {"action"=>"progress", "controller"=>"data_files",
"upload_id"=>"1172268962"}
Completed in 0.00854 (117 reqs/sec) | Rendering: 0.00813 (95%) | DB:
0.00000 (0%) | 200 OK
[http://central.incomumdesign.com/files/progress?upload_id=1172268962]


Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
22:16:32) [POST]
  Parameters: {"action"=>"progress", "controller"=>"data_files",
"upload_id"=>"1172268962"}
Completed in 0.00670 (149 reqs/sec) | Rendering: 0.00635 (94%) | 200
OK [http://central.incomumdesign.com/files/progress?upload_id=1172268962]


Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
22:16:35) [POST]
  Parameters: {"action"=>"progress", "controller"=>"data_files",
"upload_id"=>"1172268962"}
Completed in 0.00759 (131 reqs/sec) | Rendering: 0.00719 (94%) | DB:
0.00000 (0%) | 200 OK
[http://central.incomumdesign.com/files/progress?upload_id=1172268962]


Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
22:16:38) [POST]
  Parameters: {"action"=>"progress", "controller"=>"data_files",
"upload_id"=>"1172268962"}
Completed in 0.00802 (124 reqs/sec) | Rendering: 0.00757 (94%) | 200
OK [http://central.incomumdesign.com/files/progress?upload_id=1172268962]


Processing DataFilesController#upload (for 201.17.52.1 at 2007-02-23
22:16:40) [POST]
  Session ID: 23b0c52d05a16439015cb313a05a7660
  Parameters: {"commit"=>"Upload", "xhr"=>"true", "action"=>"upload",
"controller"=>"data_files", "upload_id"=>"1172268962",
"data_file"=>{"description"=>""}, "data"=>#<File:/tmp/CGI12410.0>}
Completed in 0.26787 (3 reqs/sec) | Rendering: 0.00011 (0%) | DB:
0.25820 (96%) | 200 OK
[http://central.incomumdesign.com/files/upload?upload_id=1172268962&xhr=true]

From jbaty at fusionary.com  Tue Feb 27 09:56:49 2007
From: jbaty at fusionary.com (Jack Baty)
Date: Tue, 27 Feb 2007 09:56:49 -0500
Subject: [Mongrel] mongrel_cluster and Monit
Message-ID: <81350a250702270656x71cef428ge214876fe39793e@mail.gmail.com>

On one of my development servers mongrel dies when idle for any length
of time. Since I've not been able to solve that problem I thought I'd
route around it by using monit to kick things when necessary.

My monitrc contains the following...

--------------------------------------------------------------------------------
check process mongrel_8310 with pidfile
/home/valleyc/apps/cms/dev/current/log/mongrel.8310.pid
  group mongrel
  start program = "/usr/local/bin/mongrel_rails cluster::start -C
/home/valleyc/apps/cms/dev/current/config/mongrel_cluster.yml --clean
--only 8310"
  stop program = "/usr/local/bin/mongrel_rails cluster::stop -C
/home/valleyc/apps/cms/dev/current/config/mongrel_cluster.yml --clean
--only 8310"

  if failed host 127.0.0.1 port 8310 protocol http
    with timeout 10 seconds
    then restart

  if totalmem > 128 Mb then restart
  if cpu is greater than 60% for 2 cycles then alert
  #if cpu > 90% for 5 cycles then restart
  #if loadavg(5min) greater than 10 for 8 cycles then restart
  if 3 restarts within 5 cycles then timeout
--------------------------------------------------------------------------------

If I run the start command manually it works fine. When run via monit
however it seems unable to find mongrel_rails....

# monit validate
'mongrel_8310' process is not running
'mongrel_8310' trying to restart
'mongrel_8310' start: /usr/local/bin/mongrel_rails
'mongrel_8310' failed to start
starting port 8310
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:
command not found: mongrel_rails start -d -e production -a 127.0.0.1
-c /home/valleyc/apps/cms/dev/current --user valleyc --group valleyc
-p 8310 -P /home/valleyc/apps/cms/dev/current/log/mongrel.8310.pid -l
log/mongrel.8310.log

No amount of $PATH fiddling seemed to help, so for now I've patched
mongrel_cluster's init.rb by changing line 62 (of version 1.0.1.1)
from this...

argv = [ "mongrel_rails" ]

to this...

argv = [ "/usr/local/bin/mongrel_rails" ]

...which works, but seems less than ideal. Any suggestions for a
better way to fix this without messing with the mongrel_cluster code
would be appreciated.

Thanks,

Jack

-- 
--------------------------------------------------------------------------------
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 stu at relevancellc.com  Tue Feb 27 09:58:53 2007
From: stu at relevancellc.com (Stuart Halloway)
Date: Tue, 27 Feb 2007 09:58:53 -0500
Subject: [Mongrel] Apache+mod_proxy_balancer+Mongrel+Mephisto,
	Apache kills CPU
In-Reply-To: <45E3A6B0.3050304@usermail.com>
References: <9BDB7DE6-C2C6-4F9A-B4D3-D1282CEEA07C@relevancellc.com>
	<45E3A6B0.3050304@usermail.com>
Message-ID: <E8F15130-69E7-4DD7-BCAB-3775ECD55BA6@relevancellc.com>

Hi Roy,

Responses inline:

> What version of apache httpd is this? 2.2.x?
2.2.0

> Is httpd serving static content with no issue?
Yes. In fact the site is mostly static so I am leaving httpd up and  
the mongrels down (http://www.relevancellc.com)

> Anything strange in your httpd errors log?
Sometimes getting a batch of these on restart:
[Mon Feb 26 13:03:28 2007] [error] child process 6060 still did not  
exit, sending a SIGKILL

> What does your proxy balancer config look like?
My proxy balancer config looks just like that. I have also tried just  
ProxyPass. Note that there are two other Rails apps working just fine  
behind similar configurations on the same Apache instance.

> Got any rewrite rules defined?
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
# RewriteRule ^/(.*)$ balancer://mephisto_cluster%{REQUEST_URI}  
[P,QSA,L]
RewriteRule .* http://127.0.0.1:8110%{REQUEST_URI} [L,P,QSA]

Either of the balancer or the pass lead to the same problem.

> What modules are compiled in? (httpd -l)
What's the right answer to this question supposed to be? :-) I have
# bin/httpd -l
Compiled in modules:
   core.c
   worker.c
   http_core.c
   mod_so.c

> Is there a particular request that causes the issue? or is it the  
> first
> request with apache that causes everything to 'go sideways'?
It is not the first request, but it happens fairly quickly under  
modest load.

> If you're really out of options one other thing to try is to hook in a
> traffic sniffer between apache and mongrel (like TCPmon) and look  
> at the
> requests/responses between the two. Perhaps mongrel is returning
> something apache doesn't like? or vise versa...
Good idea. I'll have to do something console-based since I don't have  
GUI access to the server. I'll try this afternoon. Is there some way  
to turn on a promiscuous mode in either Apache or Mongrel that would  
just dump all the traffic? That might be easier.

>
> -Roy
>
> Stuart Halloway wrote:
>> Our Mephisto install kills Mongrels and causes Apache to pound the
>> CPU. This started when we moved to Apache+mod_proxy_balancer+Mongrel.
>>
>> Here's what we know:
>> The following things are working OK, except when used in the
>> combination listed above: mongrel, mongrel_rails, MySQL, Apache,
>> mod_proxy_balancer. We believe these are all OK because we moved five
>> other Rails apps to this configuration on the same box, and they are
>> working fine.
>>
>> Here's what we have figured out:
>> Connecting directly to the mongrel instance works, sort of. It's S L
>> O W. Clicking on a monthly blog archive link takes about 5 seconds,
>> most of which is spent in the MySQL database. I turned the
>> production.log up to debug, and found that Mephisto (0.7.3) makes
>> dozens of round trips to build the monthly archive page.
>>
>> Here's the weird part:
>> Mephisto is slow but OK until we put Apache in front of the Mongrels.
>> Then things go sideways. The mongrels become unresponsive, and
>> Apache's CPU usage spikes. A single unresponsive mongrel thread
>> causes Apache's utilization to stay about 50% forever, and a few
>> dozen of them peg the processor.
>>
>> Here's some stuff we have explored:
>> * mod_proxy_balancer vs. ProxyPass to a single Mongrel. Same problem
>> either way.
>> * Monit. Very cool tool for diagnosing the problem, and killing the
>> runaway processes. The problem occurs too frequently to just let
>> monit bounce everything.
>> * Apache server status. The trouble requests look like this:
>>                	    CPU 	                    Client	Request
>> 0-1	4401	0/5/5	R 	30.88	348	0	0.0	0.06	0.06 	?	?	..reading..
>> Note CPU time is huge. These seem to hang around forever, but the CPU
>> gets pegged long before we run out of threads.
>> * Mongrel -USR1 debugging. Sample thread entry at the bottom of this
>> post, nothing out of the ordinary in the other logs.
>> * Shutdown portion of Mongrel's main log also shown below. Could this
>> explain the problem?
>>
>> The part that mystifies me:
>> * Why is Mongrel fine without Apache, but not with it?
>> * When the Mongrels start to suffer, why does Apache's CPU usage peg?
>> I would expect Apache's threads to have about 0% CPU utilization
>> while waiting on a struggling Mongrel.
>>
>> I am happy to try other experiments anyone might suggest, or to
>> provide more detail from other logs.
>>
>> Thanks,
>> Stuart Halloway
>> www.relevancellc.com
>>
>> [Environment]
>> Mac OS X
>> Mephisto 0.7.3
>> Most recent version of all gems (nothing on edge)
>>
>> [Excerpt from threads.log]
>> Mon Feb 26 14:37:16 PST 2007 REQUEST /archives/2006/5
>> 0.0.0.0:8111 -- THREADS: 3 -----
>>          KEYS:
>>                  -- #<Thread:0x35e4030>:  
>> [:__inspect_key__, :started_on]
>>                  -- #<Thread:0x36f8c78>:  
>> [:__inspect_key__, :started_on]
>>                  -- #<Thread:0x35e352c>:  
>> [:__inspect_key__, :started_on]
>>
>> [Excerpt from mongrel.log when killing unresponsive mongrels]
>> ** TERM signal received.
>> Mon Feb 26 14:37:06 PST 2007: Reaping 3 threads for slow workers
>> because of 'shutdown'
>> Waiting for 3 requests to finish, could take 60 seconds.object.log
>> ERROR: undefined method `class' for #<Liquid::Strainer:0x3132ba4>
>> object.log ERROR: undefined method `class' for #<Liquid::Strainer:
>> 0x3132ba4>
>> Mon Feb 26 14:37:13 PST 2007: Reaping 3 threads for slow workers
>> because of 'shutdown'
>> Waiting for 3 requests to finish, could take 60 seconds.object.log
>> ERROR: undefined method `class' for #<Liquid::Strainer:0x3132ba4>
>> Mon Feb 26 14:37:20 PST 2007: Reaping 3 threads for slow workers
>> because of 'shutdown'
>> Waiting for 3 requests to finish, could take 60 seconds.Mon Feb 26
>> 14:37:30 PST 2007: Reaping 3 threads for slow workers because of
>> 'shutdown'
>> Waiting for 3 requests to finish, could take 60 seconds.Mon Feb 26
>> 14:37:36 PST 2007: Reaping 2 threads for slow workers because of
>> 'shutdown'
>>
>>





From zedshaw at zedshaw.com  Tue Feb 27 13:18:58 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 27 Feb 2007 10:18:58 -0800
Subject: [Mongrel] Threshold of mongrel node processes
In-Reply-To: <45E3D755.60801@gmail.com>
References: <45E3D755.60801@gmail.com>
Message-ID: <20070227101858.dd06b184.zedshaw@zedshaw.com>

On Tue, 27 Feb 2007 01:01:41 -0600
Ryan <abstractryan at gmail.com> wrote:

> Hi all:
> 
> New to the list. Im enjoying mongrel. Coming from a background of 
> weblogic clusters this is a dream. However I have a few questions:
<snip>
> As you can see it appears the the mongrel nodes on this server are going 
> for max cpu utilization.

Mongrel doesn't try to manage CPU utilization since that's the job of
the operating system.  If you want to reduce the load that Mongrel puts
on your servers, then look at the nice command and using your systems
firewall mechanism to control the throttling of requests.

There are a few parameters that can give you a bit of control, such as
-t for a timeout, but that option hasn't been used much and probably
doesn't work the way it's expected.


-- 
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.

From abstractryan at gmail.com  Tue Feb 27 11:10:08 2007
From: abstractryan at gmail.com (Ryan)
Date: Tue, 27 Feb 2007 10:10:08 -0600
Subject: [Mongrel] Threshold of mongrel node processes
In-Reply-To: <3945c4270702270545k503fe81axe061ea6badcb94d2@mail.gmail.com>
References: <45E3D755.60801@gmail.com>
	<3945c4270702270545k503fe81axe061ea6badcb94d2@mail.gmail.com>
Message-ID: <45E457E0.2060203@gmail.com>

Alexey:

thanks for the response. Actually we are using sqlite3 for these tests. 
Also we are simply hitting the index page of the application so no mysql 
or heavy application processing is taking place. Im sure the hardware 
specs of the server would play a role. Is there a guideline anywhere a 
typical performance metric can be compared?

thanks
Ryan

Alexey Verkhovsky wrote:
> > 1) Is this normal behavior for mongrel?
> Not really.
>
> First of all, it's hardly about Mongrel, which is rather light on CPU 
> time. More likely than not 95 out of those 98% CPU spends within your 
> app code (that runs on the same ruby process as Mongrel).
>
> Normal CPU utilization profile includes significant amount of database 
> work (30 to 70%). Unless your Rails app uses SQLite (an in process 
> database), or doesn't use database at all, you should see some CPU (20 
> to 70%) utilized by mysqld.
>
> Make sure that you did change Rails environment to production with -e 
> production option.
>
> > 2) Is there way to configure mongrel to only go after a threshold or 
> percentage of max cpu utilization?
> No, not within Mongrel. You shouldn't need it.
>
> Alex
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From zedshaw at zedshaw.com  Tue Feb 27 17:40:20 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 27 Feb 2007 14:40:20 -0800
Subject: [Mongrel] Mongrel upload progress not showing progress on
 production server
In-Reply-To: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
Message-ID: <20070227144020.e649667c.zedshaw@zedshaw.com>

On Tue, 27 Feb 2007 11:40:23 -0300
"Benjamin Jackson" <bhjackson at gmail.com> wrote:

> Hi all,
> 
> Tried out the mongrel upload progress plugin with Drb and it works
> great on my OSX development box, but when putting it into production
> (Ubuntu Dapper), uploads complete but the app isn't returning any
> values for upload progress, and uploads are not showing up in the
> queue when running upload_client.rb. Before anyone asks, yes, I'm
> running both the mongrel instances and the upload.rb script.

If it's behind nginx or other servers (apache?) sometimes they buffer
the request before sending the status back.  Otherwise, grab firebug
and use it to see what is going on.

-- 
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.

From wayneeseguin at gmail.com  Tue Feb 27 15:16:12 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 27 Feb 2007 15:16:12 -0500
Subject: [Mongrel] Mongrel upload progress not showing progress on
	production server
In-Reply-To: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
Message-ID: <5CA56EF3-1076-4E62-832E-ED545903E09F@gmail.com>

Ben,

Check a few things first:
  - Make sure the backgroundDRb server and worker processes are  
running on your production box
  - Make sure that both slave and daemons gems (required by  
backgroundDRb) are installed in the production environment.

   ~Wayne

On Feb 27, 2007, at 09:40 , Benjamin Jackson wrote:

> Hi all,
>
> Tried out the mongrel upload progress plugin with Drb and it works
> great on my OSX development box, but when putting it into production
> (Ubuntu Dapper), uploads complete but the app isn't returning any
> values for upload progress, and uploads are not showing up in the
> queue when running upload_client.rb. Before anyone asks, yes, I'm
> running both the mongrel instances and the upload.rb script.
>
> Below are the relevant log entries and code snippets. Thanks!
>
> data_file.rb:
>
> ?
>
>   def progress
>     warn 'progress'
>     render :update do |page|
>       warn 'update'
>       @status = Mongrel::Uploads.check(params[:upload_id])
>       warn @status.inspect
>       page.upload_progress.update(@status[:size], @status 
> [:received]) if @status
>     end
>   end
>
> ?
>
> mongrel.log:
>
> ...
> progress
> update
> nil
> progress
> update
> nil
> progress
> update
> nil
> ?
>
> production.log:
>
> Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
> 22:16:29) [POST]
>   Parameters: {"action"=>"progress", "controller"=>"data_files",
> "upload_id"=>"1172268962"}
> Completed in 0.00706 (141 reqs/sec) | Rendering: 0.00667 (94%) | 200
> OK [http://central.incomumdesign.com/files/progress? 
> upload_id=1172268962]
>
>
> Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
> 22:16:29) [POST]
>   Parameters: {"action"=>"progress", "controller"=>"data_files",
> "upload_id"=>"1172268962"}
> Completed in 0.00854 (117 reqs/sec) | Rendering: 0.00813 (95%) | DB:
> 0.00000 (0%) | 200 OK
> [http://central.incomumdesign.com/files/progress?upload_id=1172268962]
>
>
> Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
> 22:16:32) [POST]
>   Parameters: {"action"=>"progress", "controller"=>"data_files",
> "upload_id"=>"1172268962"}
> Completed in 0.00670 (149 reqs/sec) | Rendering: 0.00635 (94%) | 200
> OK [http://central.incomumdesign.com/files/progress? 
> upload_id=1172268962]
>
>
> Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
> 22:16:35) [POST]
>   Parameters: {"action"=>"progress", "controller"=>"data_files",
> "upload_id"=>"1172268962"}
> Completed in 0.00759 (131 reqs/sec) | Rendering: 0.00719 (94%) | DB:
> 0.00000 (0%) | 200 OK
> [http://central.incomumdesign.com/files/progress?upload_id=1172268962]
>
>
> Processing DataFilesController#progress (for 201.17.52.1 at 2007-02-23
> 22:16:38) [POST]
>   Parameters: {"action"=>"progress", "controller"=>"data_files",
> "upload_id"=>"1172268962"}
> Completed in 0.00802 (124 reqs/sec) | Rendering: 0.00757 (94%) | 200
> OK [http://central.incomumdesign.com/files/progress? 
> upload_id=1172268962]
>
>
> Processing DataFilesController#upload (for 201.17.52.1 at 2007-02-23
> 22:16:40) [POST]
>   Session ID: 23b0c52d05a16439015cb313a05a7660
>   Parameters: {"commit"=>"Upload", "xhr"=>"true", "action"=>"upload",
> "controller"=>"data_files", "upload_id"=>"1172268962",
> "data_file"=>{"description"=>""}, "data"=>#<File:/tmp/CGI12410.0>}
> Completed in 0.26787 (3 reqs/sec) | Rendering: 0.00011 (0%) | DB:
> 0.25820 (96%) | 200 OK
> [http://central.incomumdesign.com/files/upload? 
> upload_id=1172268962&xhr=true]
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From cronald at gmail.com  Tue Feb 27 16:01:20 2007
From: cronald at gmail.com (Paul King)
Date: Tue, 27 Feb 2007 21:01:20 +0000
Subject: [Mongrel] mongrel_cluster and Monit
In-Reply-To: <81350a250702270656x71cef428ge214876fe39793e@mail.gmail.com>
References: <81350a250702270656x71cef428ge214876fe39793e@mail.gmail.com>
Message-ID: <2939187c0702271301l1b9e2d53v89272cbc2bd5151a@mail.gmail.com>

Hi,

This is likely because monit nukes the majority of the environment
variables for security reasons (including the path)

See http://www.tildeslash.com/monit/doc/faq.php (Q6) for more info.
Easiest way around it is to call mongrel_rails from a shell script
that sets the environement beforehand.

- Paul

On 27/02/07, Jack Baty <jbaty at fusionary.com> wrote:
> On one of my development servers mongrel dies when idle for any length
> of time. Since I've not been able to solve that problem I thought I'd
> route around it by using monit to kick things when necessary.
>
> My monitrc contains the following...
>
> --------------------------------------------------------------------------------
> check process mongrel_8310 with pidfile
> /home/valleyc/apps/cms/dev/current/log/mongrel.8310.pid
>   group mongrel
>   start program = "/usr/local/bin/mongrel_rails cluster::start -C
> /home/valleyc/apps/cms/dev/current/config/mongrel_cluster.yml --clean
> --only 8310"
>   stop program = "/usr/local/bin/mongrel_rails cluster::stop -C
> /home/valleyc/apps/cms/dev/current/config/mongrel_cluster.yml --clean
> --only 8310"
>
>   if failed host 127.0.0.1 port 8310 protocol http
>     with timeout 10 seconds
>     then restart
>
>   if totalmem > 128 Mb then restart
>   if cpu is greater than 60% for 2 cycles then alert
>   #if cpu > 90% for 5 cycles then restart
>   #if loadavg(5min) greater than 10 for 8 cycles then restart
>   if 3 restarts within 5 cycles then timeout
> --------------------------------------------------------------------------------
>
> If I run the start command manually it works fine. When run via monit
> however it seems unable to find mongrel_rails....
>
> # monit validate
> 'mongrel_8310' process is not running
> 'mongrel_8310' trying to restart
> 'mongrel_8310' start: /usr/local/bin/mongrel_rails
> 'mongrel_8310' failed to start
> starting port 8310
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:
> command not found: mongrel_rails start -d -e production -a 127.0.0.1
> -c /home/valleyc/apps/cms/dev/current --user valleyc --group valleyc
> -p 8310 -P /home/valleyc/apps/cms/dev/current/log/mongrel.8310.pid -l
> log/mongrel.8310.log
>
> No amount of $PATH fiddling seemed to help, so for now I've patched
> mongrel_cluster's init.rb by changing line 62 (of version 1.0.1.1)
> from this...
>
> argv = [ "mongrel_rails" ]
>
> to this...
>
> argv = [ "/usr/local/bin/mongrel_rails" ]
>
> ...which works, but seems less than ideal. Any suggestions for a
> better way to fix this without messing with the mongrel_cluster code
> would be appreciated.
>
> Thanks,
>
> Jack
>
> --
> --------------------------------------------------------------------------------
> 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
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From pete at nextengine.com  Tue Feb 27 16:44:54 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Tue, 27 Feb 2007 13:44:54 -0800
Subject: [Mongrel] Deployement options
In-Reply-To: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
Message-ID: <FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>

Having multiple servers has been a must in my experience with  
Mongrel, mainly because if a task is database / IO bound then other  
users have to wait for it.

I'm using Lighttpd => Pound => 10 Mongrels right now.

Lighttpd just released a new version (1.5), which has the ability to  
directly contact multiple mongrels.

I'll likely upgrade to this later in the week.  Then I'll just have  
Lighttpd => 10 Mongrels

Hope this helps,
Pete

On Feb 26, 2007, at 9:48 PM, tom wang wrote:

> After reading the digital shortcut and the
> documentation on the web site I'm confused.
> Which one should I use? pen, balance or nginx ?
>
> I don't want to use a behemoth like appache and ssl is
> not needed so it reduces my choice to those three
> only....
>
> What are the pros and cons of each? I don't have much
> money, so the less ressources I use the better it is
> for me....
>
> As an additional question, how far would a one server
> configuration get me? I'm going to be serving a lot of
> pictures and have some simple treatment of photos
> (resizing and such)
>
>
> 	
>
> 	
> 		
> ______________________________________________________________________ 
> _____
> 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
> _______________________________________________
> 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/20070227/acb5e040/attachment.html 

From cronald at gmail.com  Tue Feb 27 17:26:19 2007
From: cronald at gmail.com (Paul King)
Date: Tue, 27 Feb 2007 22:26:19 +0000
Subject: [Mongrel] Deployement options
In-Reply-To: <FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
Message-ID: <2939187c0702271426l1e94a498k34133433badfb85b@mail.gmail.com>

Sorry if this is a little off-topic, but might I ask what your
hardware setup/config is for ten mongrels?

Thanks,
- Paul

On 27/02/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>
> Having multiple servers has been a must in my experience with Mongrel,
> mainly because if a task is database / IO bound then other users have to
> wait for it.
>
> I'm using Lighttpd => Pound => 10 Mongrels right now.
>
> Lighttpd just released a new version (1.5), which has the ability to
> directly contact multiple mongrels.
>
> I'll likely upgrade to this later in the week.  Then I'll just have Lighttpd
> => 10 Mongrels
>
>
> Hope this helps,
> Pete
>
>
> On Feb 26, 2007, at 9:48 PM, tom wang wrote:
>
> After reading the digital shortcut and the
> documentation on the web site I'm confused.
> Which one should I use? pen, balance or nginx ?
>
> I don't want to use a behemoth like appache and ssl is
> not needed so it reduces my choice to those three
> only....
>
> What are the pros and cons of each? I don't have much
> money, so the less ressources I use the better it is
> for me....
>
> As an additional question, how far would a one server
> configuration get me? I'm going to be serving a lot of
> pictures and have some simple treatment of photos
> (resizing and such)
>
>
>
>
>
>
>
>
>
>
>
>
> ___________________________________________________________________________
> 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
> _______________________________________________
> 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 atmos at atmos.org  Tue Feb 27 18:03:45 2007
From: atmos at atmos.org (Corey Donohoe)
Date: Tue, 27 Feb 2007 17:03:45 -0600
Subject: [Mongrel] mongrel_cluster and Monit
In-Reply-To: <2939187c0702271301l1b9e2d53v89272cbc2bd5151a@mail.gmail.com>
References: <81350a250702270656x71cef428ge214876fe39793e@mail.gmail.com>
	<2939187c0702271301l1b9e2d53v89272cbc2bd5151a@mail.gmail.com>
Message-ID: <c75e5f320702271503q5e3c8a5bld9e322099d9bd6a@mail.gmail.com>

>
>
> On 27/02/07, Jack Baty <jbaty at fusionary.com> wrote:
> >
> > # monit validate
> > 'mongrel_8310' process is not running
> > 'mongrel_8310' trying to restart
> > 'mongrel_8310' start: /usr/local/bin/mongrel_rails
> > 'mongrel_8310' failed to start
> > starting port 8310
>
>
fwiw I did this.

  start program = "/usr/bin/env PATH=/opt/local/bin:$PATH mongrel_rails
cluster:
:start -C ..."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070227/fc8a0ed4/attachment.html 

From atmos at atmos.org  Tue Feb 27 18:07:31 2007
From: atmos at atmos.org (Corey Donohoe)
Date: Tue, 27 Feb 2007 17:07:31 -0600
Subject: [Mongrel] Deployement options
In-Reply-To: <2939187c0702271426l1e94a498k34133433badfb85b@mail.gmail.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
	<2939187c0702271426l1e94a498k34133433badfb85b@mail.gmail.com>
Message-ID: <c75e5f320702271507g6d574bdv853c42c757dd6399@mail.gmail.com>

On 2/27/07, Paul King <cronald at gmail.com> wrote:
>
> Sorry if this is a little off-topic, but might I ask what your
> hardware setup/config is for ten mongrels?
>
> Thanks,
> - Paul
>
> On 27/02/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> >
> > Having multiple servers has been a must in my experience with Mongrel,
> > mainly because if a task is database / IO bound then other users have to
> > wait for it.
> >
> > I'm using Lighttpd => Pound => 10 Mongrels right now.
> >
> > Lighttpd just released a new version (1.5), which has the ability to
> > directly contact multiple mongrels.
> >
> > I'll likely upgrade to this later in the week.  Then I'll just have
> Lighttpd
> > => 10 Mongrels
> >
> >
> > Hope this helps,
> > Pete
> >
> >
> > On Feb 26, 2007, at 9:48 PM, tom wang wrote:
> >
> > After reading the digital shortcut and the
> > documentation on the web site I'm confused.
> > Which one should I use? pen, balance or nginx ?
> >
> > I don't want to use a behemoth like appache and ssl is
> > not needed so it reduces my choice to those three
> > only....
> >
> > What are the pros and cons of each? I don't have much
> > money, so the less ressources I use the better it is
> > for me....
> >
> > As an additional question, how far would a one server
> > configuration get me? I'm going to be serving a lot of
> > pictures and have some simple treatment of photos
> > (resizing and such)
> >


You really wanna consider nginx.  Check their wiki on mongrel+rails
http://wiki.codemongers.com/NginxRubyonRailsMongrel

It can do all yoru static images and you can add servers to your mongrel
cluster as needed.  It's gonna be a lot smaller than apache, and you can
easily do ssl with it if you want.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070227/63219d8f/attachment-0001.html 

From pete at nextengine.com  Tue Feb 27 18:07:29 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Tue, 27 Feb 2007 15:07:29 -0800
Subject: [Mongrel] Deployement options
In-Reply-To: <2939187c0702271426l1e94a498k34133433badfb85b@mail.gmail.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
	<2939187c0702271426l1e94a498k34133433badfb85b@mail.gmail.com>
Message-ID: <27E2AB59-FAF7-418E-B3ED-4DA0B3338334@nextengine.com>

Sure, they're running on a PowerEdge 1950 (Dual Core Xeon).  I have  
several of these boxes, each running multiple Mongrels.  There is a  
separate DB server running Mysql, and a load balancer (homemade) that  
routes to the different boxes.

Im doing quite a bit of file serving + heavy DB queries, so my  
application is very much IO bound.  I started with the standard 4  
mongrels, but found I could get a lot more out of each server with 10.

-Pete


On Feb 27, 2007, at 2:26 PM, Paul King wrote:

> Sorry if this is a little off-topic, but might I ask what your
> hardware setup/config is for ten mongrels?
>
> Thanks,
> - Paul
>
> On 27/02/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>>
>> Having multiple servers has been a must in my experience with  
>> Mongrel,
>> mainly because if a task is database / IO bound then other users  
>> have to
>> wait for it.
>>
>> I'm using Lighttpd => Pound => 10 Mongrels right now.
>>
>> Lighttpd just released a new version (1.5), which has the ability to
>> directly contact multiple mongrels.
>>
>> I'll likely upgrade to this later in the week.  Then I'll just  
>> have Lighttpd
>> => 10 Mongrels
>>
>>
>> Hope this helps,
>> Pete
>>
>>
>> On Feb 26, 2007, at 9:48 PM, tom wang wrote:
>>
>> After reading the digital shortcut and the
>> documentation on the web site I'm confused.
>> Which one should I use? pen, balance or nginx ?
>>
>> I don't want to use a behemoth like appache and ssl is
>> not needed so it reduces my choice to those three
>> only....
>>
>> What are the pros and cons of each? I don't have much
>> money, so the less ressources I use the better it is
>> for me....
>>
>> As an additional question, how far would a one server
>> configuration get me? I'm going to be serving a lot of
>> pictures and have some simple treatment of photos
>> (resizing and such)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _____________________________________________________________________ 
>> ______
>> 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
>> _______________________________________________
>> 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 chris at codeintensity.com  Tue Feb 27 18:40:30 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Tue, 27 Feb 2007 15:40:30 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
Message-ID: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>

I'm trying to do some initial benchmarking of our setup, mainly just to
establish baselines.  I'm essentially using the process Zed outlines in a
previous message:
http://rubyforge.org/pipermail/mongrel-users/2006-May/000200.html

What I'm running into is that Mongrel appears only half as fast as Apache
when serving a small static HTML file.  If I then add in Apache with
mod_proxy_balancer, going to a single Mongrel, it drops down to nearly about
a third of what pure static Apache will do.  This seems bogus to me, and I
suspect I have either some configuration problem, or something.  My
understanding from what I've read is that Mongrel should be fairly close to
Apache when serving static content (at least not only 50% as fast).  Is that
right as a generalization?

Here's some info to back this up.
- Server: HP DL360 dual 3.0GHz Xeons, 4GB RAM, 10k RPM SCSI disks
- OS: Fedora Core 6, up to date as of a few days ago, kernel 2.6.18 smp
- Apache 2.2.3, with mod_proxy_balancer (the RPM install)
- Mongrel 1.0.1, mongrel_cluster 0.2.1
- ruby 1.8.5 (2006-12-04 patchlevel 2)
- serving a static HTML file from the Rails app's public directory
- Testing using an identical server, that sits above this one in the rack,
connected to a switch (so it's one hop)
- Using httperf for testing, with the following command:
  httperf --server lab05 --port 80 --uri /mongrel_alive.html --num-conns
10000
The number of connections I vary to be near the 10 second mark...

Here's the results:

- Just Apache, num-conns=15000, ~1400 req/sec
- Direct to Mongrel on port 5000, num-conns=8000, ~740 req/sec
- Apache mod_proxy_balancer to a single Mongrel, num-conns=5000, ~475
req/sec

So, I'm incurring a massive penalty for the balancer/cluster setup.  In
production we will be using hardware load balancers, but even still, my
understanding was that instead of a drop from 1400 to 740, it should be
somewhat closer (say at least over 1000).

My configuration is what seems to be the usual thing documented say in Rails
Cookbook, on various blogs, and so on.  I can post the details if needed.

What would folks suggest, or what comments do you have?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070227/67e11a05/attachment.html 

From wyhaines at gmail.com  Tue Feb 27 19:18:25 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 27 Feb 2007 17:18:25 -0700
Subject: [Mongrel] Deployement options
In-Reply-To: <FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
Message-ID: <f4cd26df0702271618k538ecbd0nd81f3394cc6ff0f5@mail.gmail.com>

On 2/27/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>
> Having multiple servers has been a must in my experience with Mongrel,
> mainly because if a task is database / IO bound then other users have to
> wait for it.
>
> I'm using Lighttpd => Pound => 10 Mongrels right now.

No, it isn't a must for Mongrel.  It may be a must for Rails, but it
isn't a must for Mongrel.  There is a difference.  It's often blurred
in both questions and responses, but Mongrel is far more than just a
Rails platform.


Kirk Haines

From chris at codeintensity.com  Tue Feb 27 19:48:25 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Tue, 27 Feb 2007 16:48:25 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
Message-ID: <8c8513100702271648k71268c67i2603c43d9ef0669b@mail.gmail.com>

As additional info, I ran the same kind of tests with Pen and Nginx instead
of Apache+mod_proxy_balancer, just to get an idea on that aspect:

Pen with 1 Mongrel: ~671 req/sec
Nginx with 1 Mongrel: ~612 req/sec

So these at least show a smaller overhead for the load balancer aspect.
They also are more bare-minimum configured (I don't have much experience
with either of those, so just did the basic Pen setup where you tell it what
port to run on and the ports/domain+port it's proxying).

On 2/27/07, Christopher Bailey <chris at codeintensity.com> wrote:
>
> I'm trying to do some initial benchmarking of our setup, mainly just to
> establish baselines.  I'm essentially using the process Zed outlines in a
> previous message:
> http://rubyforge.org/pipermail/mongrel-users/2006-May/000200.html
>
> What I'm running into is that Mongrel appears only half as fast as Apache
> when serving a small static HTML file.  If I then add in Apache with
> mod_proxy_balancer, going to a single Mongrel, it drops down to nearly about
> a third of what pure static Apache will do.  This seems bogus to me, and I
> suspect I have either some configuration problem, or something.  My
> understanding from what I've read is that Mongrel should be fairly close to
> Apache when serving static content (at least not only 50% as fast).  Is that
> right as a generalization?
>
> Here's some info to back this up.
> - Server: HP DL360 dual 3.0GHz Xeons, 4GB RAM, 10k RPM SCSI disks
> - OS: Fedora Core 6, up to date as of a few days ago, kernel 2.6.18 smp
> - Apache 2.2.3, with mod_proxy_balancer (the RPM install)
> - Mongrel 1.0.1, mongrel_cluster 0.2.1
> - ruby 1.8.5 (2006-12-04 patchlevel 2)
> - serving a static HTML file from the Rails app's public directory
> - Testing using an identical server, that sits above this one in the rack,
> connected to a switch (so it's one hop)
> - Using httperf for testing, with the following command:
>   httperf --server lab05 --port 80 --uri /mongrel_alive.html --num-conns
> 10000
> The number of connections I vary to be near the 10 second mark...
>
> Here's the results:
>
> - Just Apache, num-conns=15000, ~1400 req/sec
> - Direct to Mongrel on port 5000, num-conns=8000, ~740 req/sec
> - Apache mod_proxy_balancer to a single Mongrel, num-conns=5000, ~475
> req/sec
>
> So, I'm incurring a massive penalty for the balancer/cluster setup.  In
> production we will be using hardware load balancers, but even still, my
> understanding was that instead of a drop from 1400 to 740, it should be
> somewhat closer (say at least over 1000).
>
> My configuration is what seems to be the usual thing documented say in
> Rails Cookbook, on various blogs, and so on.  I can post the details if
> needed.
>
> What would folks suggest, or what comments do you have?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070227/fe0e762c/attachment.html 

From wyhaines at gmail.com  Tue Feb 27 20:42:06 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 27 Feb 2007 18:42:06 -0700
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
Message-ID: <f4cd26df0702271742m444937f4yc0efb7b56a86a3b8@mail.gmail.com>

On 2/27/07, Christopher Bailey <chris at codeintensity.com> wrote:

> What I'm running into is that Mongrel appears only half as fast as Apache
> when serving a small static HTML file.  If I then add in Apache with
> mod_proxy_balancer, going to a single Mongrel, it drops down to nearly about
> a third of what pure static Apache will do.  This seems bogus to me, and I
> suspect I have either some configuration problem, or something.  My
> understanding from what I've read is that Mongrel should be fairly close to
> Apache when serving static content (at least not only 50% as fast).  Is that
> right as a generalization?

That may not be far off at all, and that difference between going
directly to Mongrel versus going through Apache with proxying that you
report is about what I have seen.

> - Just Apache, num-conns=15000, ~1400 req/sec

That actually seems really slow.  My box is a lot slower than yours
(dual 2ghz 32 bit AMD processors on 2gb RAM, older kernel, slower
disk), and I get twice that speed through Apache (2.0) to a small
static file.  About 2800/second.

> - Direct to Mongrel on port 5000, num-conns=8000, ~740 req/sec

This is close to what I have seen in my direct-to-mongrel tests,
though I get speeds that are a little bit higher.  In the 800+
req/second range.  I don't think anything is wrong with your tests.


Kirk Haines

From bhjackson at gmail.com  Tue Feb 27 21:32:13 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Tue, 27 Feb 2007 23:32:13 -0300
Subject: [Mongrel] Mongrel upload progress not showing progress on
	production server
In-Reply-To: <20070227144020.e649667c.zedshaw@zedshaw.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
	<20070227144020.e649667c.zedshaw@zedshaw.com>
Message-ID: <cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>

> If it's behind nginx or other servers (apache?) sometimes they buffer
> the request before sending the status back.  Otherwise, grab firebug
> and use it to see what is going on.

Thanks Zed. It is in fact behind nginx with gzip compression. How can
I work around this? By increasing/decreasing the buffer size? Here's
the relevant (I think) section of my nginx config:

    http {
      include       conf/mime.types;
      default_type  application/octet-stream;
      access_log  logs/access.log;
      sendfile     on;
      tcp_nopush     on;
      keepalive_timeout  65;
      tcp_nodelay        on;
      gzip  on;
      gzip_min_length  1100;
      gzip_buffers     4 8k;
      gzip_types       text/plain;
      ...

From christos at fetaphunk.com  Tue Feb 27 21:14:37 2007
From: christos at fetaphunk.com (Christos Zisopoulos)
Date: Wed, 28 Feb 2007 03:14:37 +0100
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <8c8513100702271648k71268c67i2603c43d9ef0669b@mail.gmail.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
	<8c8513100702271648k71268c67i2603c43d9ef0669b@mail.gmail.com>
Message-ID: <33D49741-EF05-4921-8234-F10F82F28643@fetaphunk.com>

Christopher,

Mongrel is not meant to serve static files. It is meant to replace  
the FCGI part of doing Apache->FCGI->Ruby. Or WhateverBalancer->FCGI- 
 >Ruby.

As Ezra put its here, http://f8p.com/96ktde , "...it is horribly  
ineficient to serve static files with mongrel..."

Most mongrel setups (ones with Apache) use mod_rewrite to server the  
static files through apache (including cached rails html files).

Try this vhost template ( http://f8p.com/6d6i0s ) that uses  
mod_rewrite to serve static HTML through Apache.

-christos

On 28 Feb 2007, at 01:48, Christopher Bailey wrote:

> As additional info, I ran the same kind of tests with Pen and Nginx  
> instead of Apache+mod_proxy_balancer, just to get an idea on that  
> aspect:
>
> Pen with 1 Mongrel: ~671 req/sec
> Nginx with 1 Mongrel: ~612 req/sec
>
> So these at least show a smaller overhead for the load balancer  
> aspect.  They also are more bare-minimum configured (I don't have  
> much experience with either of those, so just did the basic Pen  
> setup where you tell it what port to run on and the ports/domain 
> +port it's proxying).
>
> On 2/27/07, Christopher Bailey <chris at codeintensity.com> wrote: I'm  
> trying to do some initial benchmarking of our setup, mainly just to  
> establish baselines.  I'm essentially using the process Zed  
> outlines in a previous message:
> http://rubyforge.org/pipermail/mongrel-users/2006-May/000200.html
>
> What I'm running into is that Mongrel appears only half as fast as  
> Apache when serving a small static HTML file.  If I then add in  
> Apache with mod_proxy_balancer, going to a single Mongrel, it drops  
> down to nearly about a third of what pure static Apache will do.   
> This seems bogus to me, and I suspect I have either some  
> configuration problem, or something.  My understanding from what  
> I've read is that Mongrel should be fairly close to Apache when  
> serving static content (at least not only 50% as fast).  Is that  
> right as a generalization?
>
> Here's some info to back this up.
> - Server: HP DL360 dual 3.0GHz Xeons, 4GB RAM, 10k RPM SCSI disks
> - OS: Fedora Core 6, up to date as of a few days ago, kernel 2.6.18  
> smp
> - Apache 2.2.3, with mod_proxy_balancer (the RPM install)
> - Mongrel 1.0.1, mongrel_cluster 0.2.1
> - ruby 1.8.5 (2006-12-04 patchlevel 2)
> - serving a static HTML file from the Rails app's public directory
> - Testing using an identical server, that sits above this one in  
> the rack, connected to a switch (so it's one hop)
> - Using httperf for testing, with the following command:
>   httperf --server lab05 --port 80 --uri /mongrel_alive.html --num- 
> conns 10000
> The number of connections I vary to be near the 10 second mark...
>
> Here's the results:
>
> - Just Apache, num-conns=15000, ~1400 req/sec
> - Direct to Mongrel on port 5000, num-conns=8000, ~740 req/sec
> - Apache mod_proxy_balancer to a single Mongrel, num-conns=5000,  
> ~475 req/sec
>
> So, I'm incurring a massive penalty for the balancer/cluster  
> setup.  In production we will be using hardware load balancers, but  
> even still, my understanding was that instead of a drop from 1400  
> to 740, it should be somewhat closer (say at least over 1000).
>
> My configuration is what seems to be the usual thing documented say  
> in Rails Cookbook, on various blogs, and so on.  I can post the  
> details if needed.
>
> What would folks suggest, or what comments do you have?
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From chris at codeintensity.com  Tue Feb 27 22:39:21 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Tue, 27 Feb 2007 19:39:21 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <f4cd26df0702271742m444937f4yc0efb7b56a86a3b8@mail.gmail.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
	<f4cd26df0702271742m444937f4yc0efb7b56a86a3b8@mail.gmail.com>
Message-ID: <8c8513100702271939h78212753r59633489098b69e1@mail.gmail.com>

When you are testing Apache, is it configured exactly the same as when you
are using it to front Mongrel?  i.e. do you have the mod_proxy_balancer
module setup and configured, with Mongrel running, etc.?  I am doing that.
So, it's likely I could get it faster if I didn't have any of that.


On 2/27/07, Kirk Haines <wyhaines at gmail.com> wrote:
>
> On 2/27/07, Christopher Bailey <chris at codeintensity.com> wrote:
>
> > What I'm running into is that Mongrel appears only half as fast as
> Apache
> > when serving a small static HTML file.  If I then add in Apache with
> > mod_proxy_balancer, going to a single Mongrel, it drops down to nearly
> about
> > a third of what pure static Apache will do.  This seems bogus to me, and
> I
> > suspect I have either some configuration problem, or something.  My
> > understanding from what I've read is that Mongrel should be fairly close
> to
> > Apache when serving static content (at least not only 50% as fast).  Is
> that
> > right as a generalization?
>
> That may not be far off at all, and that difference between going
> directly to Mongrel versus going through Apache with proxying that you
> report is about what I have seen.
>
> > - Just Apache, num-conns=15000, ~1400 req/sec
>
> That actually seems really slow.  My box is a lot slower than yours
> (dual 2ghz 32 bit AMD processors on 2gb RAM, older kernel, slower
> disk), and I get twice that speed through Apache (2.0) to a small
> static file.  About 2800/second.
>
> > - Direct to Mongrel on port 5000, num-conns=8000, ~740 req/sec
>
> This is close to what I have seen in my direct-to-mongrel tests,
> though I get speeds that are a little bit higher.  In the 800+
> req/second range.  I don't think anything is wrong with your tests.
>
>
> Kirk Haines
> _______________________________________________
> 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/20070227/69ae50dd/attachment.html 

From wyhaines at gmail.com  Wed Feb 28 00:17:42 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 27 Feb 2007 22:17:42 -0700
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <8c8513100702271939h78212753r59633489098b69e1@mail.gmail.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
	<f4cd26df0702271742m444937f4yc0efb7b56a86a3b8@mail.gmail.com>
	<8c8513100702271939h78212753r59633489098b69e1@mail.gmail.com>
Message-ID: <f4cd26df0702272117g67ed2618te067a60007288e9e@mail.gmail.com>

On 2/27/07, Christopher Bailey <chris at codeintensity.com> wrote:
> When you are testing Apache, is it configured exactly the same as when you
> are using it to front Mongrel?  i.e. do you have the mod_proxy_balancer
> module setup and configured, with Mongrel running, etc.?  I am doing that.
> So, it's likely I could get it faster if I didn't have any of that.

The configuration is identical, and this server is, at any given
moment in time, handling about 65 sites/apps so there are always other
requests being handled by Apache, and many other backend processes,
some of which are mongrels, alive at the same time.  It's always
pretty consistently delivered around the same number of requests per
second.

In any event, though, when running a (non-rails) mongrel only static
file delivery test, I get speeds a bit higher than what you reported.
ab and httperf report about the same numbers, and they are around 900,
give or take 50.  I just ran a few hundered thousand requests to pull
some solid current timings, and some 10 second bursts were as high as
1000 requests/second or as low as 800/second, but most were centered
around 900.


Kirk Haines

From jbaty at fusionary.com  Wed Feb 28 00:34:45 2007
From: jbaty at fusionary.com (Jack Baty)
Date: Wed, 28 Feb 2007 00:34:45 -0500
Subject: [Mongrel] mongrel_cluster and Monit
In-Reply-To: <c75e5f320702271503q5e3c8a5bld9e322099d9bd6a@mail.gmail.com>
References: <81350a250702270656x71cef428ge214876fe39793e@mail.gmail.com>
	<2939187c0702271301l1b9e2d53v89272cbc2bd5151a@mail.gmail.com>
	<c75e5f320702271503q5e3c8a5bld9e322099d9bd6a@mail.gmail.com>
Message-ID: <81350a250702272134l2b98c032v25f428072f76aac5@mail.gmail.com>

>
> fwiw I did this.
>
>   start program = "/usr/bin/env PATH=/opt/local/bin:$PATH mongrel_rails
> cluster:
> :start -C ..."

Works lovely, thanks for that.


-- 
--------------------------------------------------------------------------------
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 chris at codeintensity.com  Wed Feb 28 01:02:58 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Tue, 27 Feb 2007 22:02:58 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <8c8513100702271939h78212753r59633489098b69e1@mail.gmail.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
	<f4cd26df0702271742m444937f4yc0efb7b56a86a3b8@mail.gmail.com>
	<8c8513100702271939h78212753r59633489098b69e1@mail.gmail.com>
Message-ID: <8c8513100702272202m3969b2f5je6c1070ae23adbba@mail.gmail.com>

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.

So, as per Zed's email, let's say you establish your baseline of what your
Apache and 1 Mongrel can do.  Let's say that's 450 req/sec and since it's
single, that's 450 conn/sec, as a result of this command:

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.

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

This doubles the rate, and doubles the number of connections, but since I
have a supposed double handling capacity, I should yield the same total time
(of 10 seconds).  Is that right?  Watching this in top I do see that both
Mongrels are grabbing CPU time.

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.


On 2/27/07, Christopher Bailey <chris at codeintensity.com> wrote:
>
> When you are testing Apache, is it configured exactly the same as when you
> are using it to front Mongrel?  i.e. do you have the mod_proxy_balancer
> module setup and configured, with Mongrel running, etc.?  I am doing that.
> So, it's likely I could get it faster if I didn't have any of that.
>
>
> On 2/27/07, Kirk Haines <wyhaines at gmail.com> wrote:
> >
> > On 2/27/07, Christopher Bailey <chris at codeintensity.com> wrote:
> >
> > > What I'm running into is that Mongrel appears only half as fast as
> > Apache
> > > when serving a small static HTML file.  If I then add in Apache with
> > > mod_proxy_balancer, going to a single Mongrel, it drops down to nearly
> > about
> > > a third of what pure static Apache will do.  This seems bogus to me,
> > and I
> > > suspect I have either some configuration problem, or something.  My
> > > understanding from what I've read is that Mongrel should be fairly
> > close to
> > > Apache when serving static content (at least not only 50% as
> > fast).  Is that
> > > right as a generalization?
> >
> > That may not be far off at all, and that difference between going
> > directly to Mongrel versus going through Apache with proxying that you
> > report is about what I have seen.
> >
> > > - Just Apache, num-conns=15000, ~1400 req/sec
> >
> > That actually seems really slow.  My box is a lot slower than yours
> > (dual 2ghz 32 bit AMD processors on 2gb RAM, older kernel, slower
> > disk), and I get twice that speed through Apache (2.0) to a small
> > static file.  About 2800/second.
> >
> > > - Direct to Mongrel on port 5000, num-conns=8000, ~740 req/sec
> >
> > This is close to what I have seen in my direct-to-mongrel tests,
> > though I get speeds that are a little bit higher.  In the 800+
> > req/second range.  I don't think anything is wrong with your tests.
> >
> >
> > Kirk Haines
> > _______________________________________________
> > 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/20070227/502b2de0/attachment.html 

From chris at codeintensity.com  Wed Feb 28 01:03:59 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Tue, 27 Feb 2007 22:03:59 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <f4cd26df0702272117g67ed2618te067a60007288e9e@mail.gmail.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
	<f4cd26df0702271742m444937f4yc0efb7b56a86a3b8@mail.gmail.com>
	<8c8513100702271939h78212753r59633489098b69e1@mail.gmail.com>
	<f4cd26df0702272117g67ed2618te067a60007288e9e@mail.gmail.com>
Message-ID: <8c8513100702272203w14dfc70dv715c610e031d3380@mail.gmail.com>

Would you mind sharing your specific httperf commands?

On 2/27/07, Kirk Haines <wyhaines at gmail.com> wrote:
>
> On 2/27/07, Christopher Bailey <chris at codeintensity.com> wrote:
> > When you are testing Apache, is it configured exactly the same as when
> you
> > are using it to front Mongrel?  i.e. do you have the mod_proxy_balancer
> > module setup and configured, with Mongrel running, etc.?  I am doing
> that.
> > So, it's likely I could get it faster if I didn't have any of that.
>
> The configuration is identical, and this server is, at any given
> moment in time, handling about 65 sites/apps so there are always other
> requests being handled by Apache, and many other backend processes,
> some of which are mongrels, alive at the same time.  It's always
> pretty consistently delivered around the same number of requests per
> second.
>
> In any event, though, when running a (non-rails) mongrel only static
> file delivery test, I get speeds a bit higher than what you reported.
> ab and httperf report about the same numbers, and they are around 900,
> give or take 50.  I just ran a few hundered thousand requests to pull
> some solid current timings, and some 10 second bursts were as high as
> 1000 requests/second or as low as 800/second, but most were centered
> around 900.
>
>
> Kirk Haines
> _______________________________________________
> 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/20070227/695fed05/attachment.html 

From chris at codeintensity.com  Wed Feb 28 03:01:21 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Wed, 28 Feb 2007 00:01:21 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <33D49741-EF05-4921-8234-F10F82F28643@fetaphunk.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
	<8c8513100702271648k71268c67i2603c43d9ef0669b@mail.gmail.com>
	<33D49741-EF05-4921-8234-F10F82F28643@fetaphunk.com>
Message-ID: <8c8513100702280001v47470f56sc6f500929dd3e89@mail.gmail.com>

I understand that, but what I was trying to do was establish some baseline
numbers so that I could ensure I was doing my testing properly.  We actually
already have Apache serving the static stuff.  But by trying a static file
with Mongrel, I had figured this could set a baseline and I could double
check scaling up the number of mongrels to make sure my test methodology was
correct, before going to Rails and complicating things.

My next step is replacing this with hitting a Rails view that has no DB
query in it.  So, essentially a static Rails view.  In doing this, the
performance is slower of course.  Just moreso than I'd hoped for and of
course by now we're way off from static Apache.  If I hit a single Mongrel
instance directly (no Apache), on a tiny page (almost empty actually), I
get:
~54 req/sec
~105 req/sec with disabled sessions (not surprising given that right now
it's set up to use the database for sessions (DB is running on same machine
as this for the tests))
~184 req/sec with disabled sessions and disabling AuthenticatedSystem.
~415 req/sec if the page is a cached page (basically the same speed as
hitting an actual static page)

So, I guess this is mostly a good lesson for me in the performance of the
system.  The only issue I'm really facing is that adding Mongrels doesn't
seem to scale much, even by just bumping it up to 2.  With the above test,
in the case where I was getting about ~184 req/sec, if I double the rate and
num-conns for httperf with now running 2 Mongrels, I can't get double the
results, in fact, I can't even get 300 req/sec without errors (and yielding
208req/sec).


On 2/27/07, Christos Zisopoulos <christos at fetaphunk.com> wrote:
>
> Christopher,
>
> Mongrel is not meant to serve static files. It is meant to replace
> the FCGI part of doing Apache->FCGI->Ruby. Or WhateverBalancer->FCGI-
> >Ruby.
>
> As Ezra put its here, http://f8p.com/96ktde , "...it is horribly
> ineficient to serve static files with mongrel..."
>
> Most mongrel setups (ones with Apache) use mod_rewrite to server the
> static files through apache (including cached rails html files).
>
> Try this vhost template ( http://f8p.com/6d6i0s ) that uses
> mod_rewrite to serve static HTML through Apache.
>
> -christos
>
> On 28 Feb 2007, at 01:48, Christopher Bailey wrote:
>
> > As additional info, I ran the same kind of tests with Pen and Nginx
> > instead of Apache+mod_proxy_balancer, just to get an idea on that
> > aspect:
> >
> > Pen with 1 Mongrel: ~671 req/sec
> > Nginx with 1 Mongrel: ~612 req/sec
> >
> > So these at least show a smaller overhead for the load balancer
> > aspect.  They also are more bare-minimum configured (I don't have
> > much experience with either of those, so just did the basic Pen
> > setup where you tell it what port to run on and the ports/domain
> > +port it's proxying).
> >
> > On 2/27/07, Christopher Bailey <chris at codeintensity.com> wrote: I'm
> > trying to do some initial benchmarking of our setup, mainly just to
> > establish baselines.  I'm essentially using the process Zed
> > outlines in a previous message:
> > http://rubyforge.org/pipermail/mongrel-users/2006-May/000200.html
> >
> > What I'm running into is that Mongrel appears only half as fast as
> > Apache when serving a small static HTML file.  If I then add in
> > Apache with mod_proxy_balancer, going to a single Mongrel, it drops
> > down to nearly about a third of what pure static Apache will do.
> > This seems bogus to me, and I suspect I have either some
> > configuration problem, or something.  My understanding from what
> > I've read is that Mongrel should be fairly close to Apache when
> > serving static content (at least not only 50% as fast).  Is that
> > right as a generalization?
> >
> > Here's some info to back this up.
> > - Server: HP DL360 dual 3.0GHz Xeons, 4GB RAM, 10k RPM SCSI disks
> > - OS: Fedora Core 6, up to date as of a few days ago, kernel 2.6.18
> > smp
> > - Apache 2.2.3, with mod_proxy_balancer (the RPM install)
> > - Mongrel 1.0.1, mongrel_cluster 0.2.1
> > - ruby 1.8.5 (2006-12-04 patchlevel 2)
> > - serving a static HTML file from the Rails app's public directory
> > - Testing using an identical server, that sits above this one in
> > the rack, connected to a switch (so it's one hop)
> > - Using httperf for testing, with the following command:
> >   httperf --server lab05 --port 80 --uri /mongrel_alive.html --num-
> > conns 10000
> > The number of connections I vary to be near the 10 second mark...
> >
> > Here's the results:
> >
> > - Just Apache, num-conns=15000, ~1400 req/sec
> > - Direct to Mongrel on port 5000, num-conns=8000, ~740 req/sec
> > - Apache mod_proxy_balancer to a single Mongrel, num-conns=5000,
> > ~475 req/sec
> >
> > So, I'm incurring a massive penalty for the balancer/cluster
> > setup.  In production we will be using hardware load balancers, but
> > even still, my understanding was that instead of a drop from 1400
> > to 740, it should be somewhat closer (say at least over 1000).
> >
> > My configuration is what seems to be the usual thing documented say
> > in Rails Cookbook, on various blogs, and so on.  I can post the
> > details if needed.
> >
> > What would folks suggest, or what comments do you have?
> >
> >
> > _______________________________________________
> > 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/20070228/27df05c8/attachment-0001.html 

From zedshaw at zedshaw.com  Wed Feb 28 11:58:23 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 28 Feb 2007 08:58:23 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
Message-ID: <20070228085823.d7cd749b.zedshaw@zedshaw.com>

On Tue, 27 Feb 2007 15:40:30 -0800
"Christopher Bailey" <chris at codeintensity.com> wrote:

> I'm trying to do some initial benchmarking of our setup, mainly just to
> establish baselines.  I'm essentially using the process Zed outlines in a
> previous message:
> http://rubyforge.org/pipermail/mongrel-users/2006-May/000200.html

Don't forget, this is also available which is pretty much the same
document/process:

http://mongrel.rubyforge.org/docs/how_many_mongrels.html

> - Using httperf for testing, with the following command:
>   httperf --server lab05 --port 80 --uri /mongrel_alive.html --num-conns
> 10000

That's fine for a httperf command.

> Here's the results:
> 
> - Just Apache, num-conns=15000, ~1400 req/sec
> - Direct to Mongrel on port 5000, num-conns=8000, ~740 req/sec
> - Apache mod_proxy_balancer to a single Mongrel, num-conns=5000, ~475
> req/sec

The apache numbers look way off.

> So, I'm incurring a massive penalty for the balancer/cluster setup.  In
> production we will be using hardware load balancers, but even still, my
> understanding was that instead of a drop from 1400 to 740, it should be
> somewhat closer (say at least over 1000).

Well, it's not "massive" but you should test other configurations and
validate that you have apache configured right.  My first thought is
that your apache configuration is slow to begin with, which might mean
that it's not tuned properly.  There's several different workers you
can use so try them out and see which is the best.  Also, try nginx and
your hardware load balancer.

Your next thing to do is see if you can get a very small sample RoR
application that just renders "test" to perform.  If RoR performs less
than 475/sec then there's no point in stressing over the drop in
performance because of apache.  You'll just have to know that you won't
be able to push it above that.

Finally, you may be worrying about this way too much in the beginning.
You've measured there's a potential problem, you should then try to
rule it out (apache is the hypothetical cause), but if you can't then
this just factors into your planning for the production deployment.
It's not the end of the world.

-- 
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.

From zedshaw at zedshaw.com  Wed Feb 28 12:05:39 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 28 Feb 2007 09:05:39 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <8c8513100702272202m3969b2f5je6c1070ae23adbba@mail.gmail.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
	<f4cd26df0702271742m444937f4yc0efb7b56a86a3b8@mail.gmail.com>
	<8c8513100702271939h78212753r59633489098b69e1@mail.gmail.com>
	<8c8513100702272202m3969b2f5je6c1070ae23adbba@mail.gmail.com>
Message-ID: <20070228090539.cc7f79b5.zedshaw@zedshaw.com>

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.

From zedshaw at zedshaw.com  Wed Feb 28 12:17:57 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 28 Feb 2007 09:17:57 -0800
Subject: [Mongrel] Mongrel upload progress not showing progress on
 production server
In-Reply-To: <cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
	<20070227144020.e649667c.zedshaw@zedshaw.com>
	<cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>
Message-ID: <20070228091757.5fae6cf9.zedshaw@zedshaw.com>

On Tue, 27 Feb 2007 23:32:13 -0300
"Benjamin Jackson" <bhjackson at gmail.com> wrote:

> > If it's behind nginx or other servers (apache?) sometimes they buffer
> > the request before sending the status back.  Otherwise, grab firebug
> > and use it to see what is going on.
> 
> Thanks Zed. It is in fact behind nginx with gzip compression. How can
> I work around this? By increasing/decreasing the buffer size? Here's
> the relevant (I think) section of my nginx config:

You can't.  Nginx's author is coming out with a version that fixes
this, but otherwise it's just inherent in the design.

Your best bet actually is to just do these uploads to a completely
offline standalone Mongrel server so you don't tie up rails.  It's about
the only compromise there is other than just not doing it in the first
place.

Even if nginx changes it's request dispatching method, you'll still
have a problem with locking up rails for each of the polling requests.

-- 
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.

From joost at spacebabies.nl  Wed Feb 28 09:24:26 2007
From: joost at spacebabies.nl (joost baaij)
Date: Wed, 28 Feb 2007 15:24:26 +0100
Subject: [Mongrel] Perceived problem... fixed
Message-ID: <1FC24B3E-F68A-4513-AE92-0ABC7C6D0C29@spacebabies.nl>

So I had my feet entirely covered in peanut butter and jelly


.. wait ...


Wrong mailing list.

Couple weeks ago I mailed the list with a perceived problem of  
Mongrels hanging. Luis and others were very kind in suggesting  
solutions. I suspected my application anyway and went on a quest. I  
was using RMagick at the time so felt that should be my first target.

Long story short: after days of uninstalling RMagick (which did NOT  
fix things!), switching web servers, tweaking code and disabling more  
and more of my app, the problem could be traced back to ....

yes, RMagick anyway. Turned out someone had left a source install on  
the server. i.e. not the gem. Ruby was able to find it and let it (as  
we all know: the cleanest image manipulation api on the planet)  
(sarcasm) run amok. Removing the source RMagick instantly fixed all  
problems.

Memory leaks you ask? Yes! Yes! Yes!

Apparently people have been able to get RMagick running fine on a  
busy site, but I am not one of them.

Happily running a Mongrel trio again (behind LiteSpeed).


The new lighttpd 1.5 architecture looks promising, maybe I'll switch  
back.


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



From jgeiger at gmail.com  Wed Feb 28 10:59:43 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Wed, 28 Feb 2007 09:59:43 -0600
Subject: [Mongrel] Mongrel upload progress not showing progress on
	production server
In-Reply-To: <20070228091757.5fae6cf9.zedshaw@zedshaw.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
	<20070227144020.e649667c.zedshaw@zedshaw.com>
	<cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>
	<20070228091757.5fae6cf9.zedshaw@zedshaw.com>
Message-ID: <466af3440702280759x1c5c6815mb34a57b3caa7619f@mail.gmail.com>

Is there a good tutorial for mongrel upload progress, which includes a
setup like the one you're describing? I looked at the one on the
mongrel site, and it got me only so far before I needed to abandon the
idea, since it was becoming a lot of work for little return. My main
issue was trying to use it for something other than strictly uploading
files with no other information.

Thanks

On 2/28/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> On Tue, 27 Feb 2007 23:32:13 -0300
> "Benjamin Jackson" <bhjackson at gmail.com> wrote:
>
> > > If it's behind nginx or other servers (apache?) sometimes they buffer
> > > the request before sending the status back.  Otherwise, grab firebug
> > > and use it to see what is going on.
> >
> > Thanks Zed. It is in fact behind nginx with gzip compression. How can
> > I work around this? By increasing/decreasing the buffer size? Here's
> > the relevant (I think) section of my nginx config:
>
> You can't.  Nginx's author is coming out with a version that fixes
> this, but otherwise it's just inherent in the design.
>
> Your best bet actually is to just do these uploads to a completely
> offline standalone Mongrel server so you don't tie up rails.  It's about
> the only compromise there is other than just not doing it in the first
> place.
>
> Even if nginx changes it's request dispatching method, you'll still
> have a problem with locking up rails for each of the polling requests.
>
> --
> 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
>

From pete at nextengine.com  Wed Feb 28 11:18:01 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 28 Feb 2007 08:18:01 -0800
Subject: [Mongrel] Deployement options
In-Reply-To: <f4cd26df0702271618k538ecbd0nd81f3394cc6ff0f5@mail.gmail.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
	<f4cd26df0702271618k538ecbd0nd81f3394cc6ff0f5@mail.gmail.com>
Message-ID: <B128DA7C-53E3-4C61-8D17-8441D9629CEB@nextengine.com>

Right on Kirk... I'm using Rails, and often forget there are other  
things Mongrel is being used with.

-Pete

On Feb 27, 2007, at 4:18 PM, Kirk Haines wrote:

> On 2/27/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>>
>> Having multiple servers has been a must in my experience with  
>> Mongrel,
>> mainly because if a task is database / IO bound then other users  
>> have to
>> wait for it.
>>
>> I'm using Lighttpd => Pound => 10 Mongrels right now.
>
> No, it isn't a must for Mongrel.  It may be a must for Rails, but it
> isn't a must for Mongrel.  There is a difference.  It's often blurred
> in both questions and responses, but Mongrel is far more than just a
> Rails platform.
>
>
> Kirk Haines
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From zedshaw at zedshaw.com  Wed Feb 28 17:46:37 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 28 Feb 2007 14:46:37 -0800
Subject: [Mongrel] Mongrel upload progress not showing progress on
 production server
In-Reply-To: <466af3440702280759x1c5c6815mb34a57b3caa7619f@mail.gmail.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
	<20070227144020.e649667c.zedshaw@zedshaw.com>
	<cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>
	<20070228091757.5fae6cf9.zedshaw@zedshaw.com>
	<466af3440702280759x1c5c6815mb34a57b3caa7619f@mail.gmail.com>
Message-ID: <20070228144637.5d46c106.zedshaw@zedshaw.com>

On Wed, 28 Feb 2007 09:59:43 -0600
"Joey Geiger" <jgeiger at gmail.com> wrote:

> Is there a good tutorial for mongrel upload progress, which includes a
> setup like the one you're describing? I looked at the one on the
> mongrel site, and it got me only so far before I needed to abandon the
> idea, since it was becoming a lot of work for little return. My main
> issue was trying to use it for something other than strictly uploading
> files with no other information.

Honestly, the idea of upload progress done this way (with polling http
requests) is a super bad idea in my book.  It's currently a hack to
work around a broken UI in the browser, so I try not to steer people in
this direction.

What you should do, if you're interested, is contact Ezra at
ez at engineyard.com as he does custom setups of this using Merb.  If you
want to do it yourself, http://merb.devjavu.com/ has example code in it
that you can use.

-- 
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.

From bhjackson at gmail.com  Wed Feb 28 15:41:56 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Wed, 28 Feb 2007 17:41:56 -0300
Subject: [Mongrel] Mongrel upload progress not showing progress on
	production server
In-Reply-To: <20070228091757.5fae6cf9.zedshaw@zedshaw.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
	<20070227144020.e649667c.zedshaw@zedshaw.com>
	<cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>
	<20070228091757.5fae6cf9.zedshaw@zedshaw.com>
Message-ID: <cb03bffe0702281241m3c6b84f8p5c56ce9e773f8d0c@mail.gmail.com>

Zed,

> > Thanks Zed. It is in fact behind nginx with gzip compression. How can
> > I work around this? By increasing/decreasing the buffer size? Here's
> > the relevant (I think) section of my nginx config:
>
> You can't.  Nginx's author is coming out with a version that fixes
> this, but otherwise it's just inherent in the design.
>
> Your best bet actually is to just do these uploads to a completely
> offline standalone Mongrel server so you don't tie up rails.  It's about
> the only compromise there is other than just not doing it in the first
> place.

By "offline" you mean not serving rails, right? This would require the
first of the two options presented on the site:

> This is fine and dandy, but not too many sites run on a single Mongrel. You'll quickly
> run into problems with multiple mongrels since only one Mongrel process knows about
> the upload. You'll either have to specify a specific mongrel port to communicate with,
> or set up a dedicated mongrel upload process. The third option, is use DRb.

Let me know if I'm on track, or if not please clarify. Thanks :)

From jeremy at bitsweat.net  Wed Feb 28 15:57:02 2007
From: jeremy at bitsweat.net (Jeremy Kemper)
Date: Wed, 28 Feb 2007 12:57:02 -0800
Subject: [Mongrel] Deployement options
In-Reply-To: <f4cd26df0702271618k538ecbd0nd81f3394cc6ff0f5@mail.gmail.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
	<f4cd26df0702271618k538ecbd0nd81f3394cc6ff0f5@mail.gmail.com>
Message-ID: <69a2885c0702281257l38bf34d9kcdc392dd836e3b36@mail.gmail.com>

On 2/27/07, Kirk Haines <wyhaines at gmail.com> wrote:
>
> On 2/27/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> >
> > Having multiple servers has been a must in my experience with Mongrel,
> > mainly because if a task is database / IO bound then other users have to
> > wait for it.
> >
> > I'm using Lighttpd => Pound => 10 Mongrels right now.
>
> No, it isn't a must for Mongrel.  It may be a must for Rails, but it
> isn't a must for Mongrel.  There is a difference.  It's often blurred
> in both questions and responses, but Mongrel is far more than just a
> Rails platform.


This is true. However, his assertion is valid: it's a must for any web app
that uses blocking API calls, like executing queries using the native mysql
and postgres clients. That's just life with Ruby threads.

jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070228/c91a2e6f/attachment-0001.html 

From zedshaw at zedshaw.com  Wed Feb 28 19:53:43 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 28 Feb 2007 16:53:43 -0800
Subject: [Mongrel] Mongrel upload progress not showing progress on
 production server
In-Reply-To: <cb03bffe0702281241m3c6b84f8p5c56ce9e773f8d0c@mail.gmail.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
	<20070227144020.e649667c.zedshaw@zedshaw.com>
	<cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>
	<20070228091757.5fae6cf9.zedshaw@zedshaw.com>
	<cb03bffe0702281241m3c6b84f8p5c56ce9e773f8d0c@mail.gmail.com>
Message-ID: <20070228165343.cdd50e09.zedshaw@zedshaw.com>

On Wed, 28 Feb 2007 17:41:56 -0300
"Benjamin Jackson" <bhjackson at gmail.com> wrote:

> Zed,
> 
> > > Thanks Zed. It is in fact behind nginx with gzip compression. How can
> > > I work around this? By increasing/decreasing the buffer size? Here's
> > > the relevant (I think) section of my nginx config:
> >
> > You can't.  Nginx's author is coming out with a version that fixes
> > this, but otherwise it's just inherent in the design.
> >
> > Your best bet actually is to just do these uploads to a completely
> > offline standalone Mongrel server so you don't tie up rails.  It's about
> > the only compromise there is other than just not doing it in the first
> > place.
> 
> By "offline" you mean not serving rails, right? This would require the
> first of the two options presented on the site:

No, by "offline" I mean a separate server that uses only Mongrel (not
rails) to handle all uploads and just the upload/status part.  Using
iframes, redirects, and the session cookies with data stored in the db
it's possible to pull this off and nobody will know.  I've done it a
few times, and Ezra's got quite a few under his belt.

> > This is fine and dandy, but not too many sites run on a single Mongrel. You'll quickly
> > run into problems with multiple mongrels since only one Mongrel process knows about
> > the upload. You'll either have to specify a specific mongrel port to communicate with,
> > or set up a dedicated mongrel upload process. The third option, is use DRb.

Many sites however run single Mongrel's for single purposes.  This is
the great thing about a small fast web server.  You don't *have* to use
rails for everything, and can distribute the work to specialized
servers that do stuff like this in a lightweight fashion.  Basically,
it's not an either/or proposition.

-- 
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.

From wyhaines at gmail.com  Wed Feb 28 17:02:42 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 28 Feb 2007 15:02:42 -0700
Subject: [Mongrel] Deployement options
In-Reply-To: <69a2885c0702281257l38bf34d9kcdc392dd836e3b36@mail.gmail.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
	<f4cd26df0702271618k538ecbd0nd81f3394cc6ff0f5@mail.gmail.com>
	<69a2885c0702281257l38bf34d9kcdc392dd836e3b36@mail.gmail.com>
Message-ID: <f4cd26df0702281402p3568a8a2w437474ef73495809@mail.gmail.com>

On 2/28/07, Jeremy Kemper <jeremy at bitsweat.net> wrote:

> This is true. However, his assertion is valid: it's a must for any web app
> that uses blocking API calls, like executing queries using the native mysql
> and postgres clients. That's just life with Ruby threads.

I have oodles of dynamic web sites and applications that make blocking
API calls yet can still sustain hit rates in the 50-200/second range
(depending on the site) under a single mongrel.  They bear up just
fine to bursty traffic when people are checking their fund prices in
the evenings.

There are situations where clustering multiple backends is necessary,
for sure, but it's possible to handle an exceptional amount of
dynamic, db-interactive traffic in a single ruby process.


Kirk Haines

From bhjackson at gmail.com  Wed Feb 28 17:04:25 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Wed, 28 Feb 2007 19:04:25 -0300
Subject: [Mongrel] Mongrel upload progress not showing progress on
	production server
In-Reply-To: <20070228144637.5d46c106.zedshaw@zedshaw.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
	<20070227144020.e649667c.zedshaw@zedshaw.com>
	<cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>
	<20070228091757.5fae6cf9.zedshaw@zedshaw.com>
	<466af3440702280759x1c5c6815mb34a57b3caa7619f@mail.gmail.com>
	<20070228144637.5d46c106.zedshaw@zedshaw.com>
Message-ID: <cb03bffe0702281404p70316a86p3fc4aed3ae9be0ce@mail.gmail.com>

Hey Zed,

> Honestly, the idea of upload progress done this way (with polling http
> requests) is a super bad idea in my book.  It's currently a hack to
> work around a broken UI in the browser, so I try not to steer people in
> this direction.
>
> What you should do, if you're interested, is contact Ezra at
> ez at engineyard.com as he does custom setups of this using Merb.  If you
> want to do it yourself, http://merb.devjavu.com/ has example code in it
> that you can use.

What would you suggest to someone who needs to allow clients to upload
files of more than a meg or two if not an upload progress script? It's
difficult to tell someone that they'll need to stare at their monitor
for a half hour to an hour while the upload churns on with no progress
:P

From zedshaw at zedshaw.com  Wed Feb 28 20:16:06 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 28 Feb 2007 17:16:06 -0800
Subject: [Mongrel] Deployement options
In-Reply-To: <69a2885c0702281257l38bf34d9kcdc392dd836e3b36@mail.gmail.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
	<f4cd26df0702271618k538ecbd0nd81f3394cc6ff0f5@mail.gmail.com>
	<69a2885c0702281257l38bf34d9kcdc392dd836e3b36@mail.gmail.com>
Message-ID: <20070228171606.5ce3b7a2.zedshaw@zedshaw.com>

On Wed, 28 Feb 2007 12:57:02 -0800
"Jeremy Kemper" <jeremy at bitsweat.net> wrote:

> On 2/27/07, Kirk Haines <wyhaines at gmail.com> wrote:
> >
> > On 2/27/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> > >
> > > Having multiple servers has been a must in my experience with Mongrel,
> > > mainly because if a task is database / IO bound then other users have to
> > > wait for it.
> > >
> > > I'm using Lighttpd => Pound => 10 Mongrels right now.
> >
> > No, it isn't a must for Mongrel.  It may be a must for Rails, but it
> > isn't a must for Mongrel.  There is a difference.  It's often blurred
> > in both questions and responses, but Mongrel is far more than just a
> > Rails platform.
> 
> 
> This is true. However, his assertion is valid: it's a must for any web app
> that uses blocking API calls, like executing queries using the native mysql
> and postgres clients. That's just life with Ruby threads.

... and eventually people will start asking why there's nearly 10 other
Ruby web frameworks that run fine in Mongrel without a big lock and do
nearly the same things as Rails or even use the same technologies as
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/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

From erik.hetzner at ucop.edu  Wed Feb 28 17:47:49 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Wed, 28 Feb 2007 14:47:49 -0800
Subject: [Mongrel] recv vs. read in HTTPRequest#read_socket
In-Reply-To: <87bqk8l06r.wl%erik.hetzner@ucop.edu>
References: <87bqk8l06r.wl%erik.hetzner@ucop.edu>
Message-ID: <87fy8pew6i.wl%erik.hetzner@ucop.edu>

At Mon, 05 Feb 2007 14:16:44 -0800,
Erik Hetzner wrote:
> Hello all,
>
> The following change to Mongrel::HttpRequest:

[?]

> seems to work for me, and vastly improves the speed of the body
> processing (quick tests reveal that using IO#read takes about 1 min 40
> secs. and using Socket#recv takes about 9 secs on an 8.5 mb file). I
> have been having trouble discovering the difference between read &
> recv (I am not a socket developer by any means). Can anybody tell me
> what sort of safety one loses by doing this with recv instead of read?
> Thanks.

As a followup, in case it wasn?t obvious, I was far off base here. I
should have realized that something was wrong with such horrible
transfer speeds. While it still seems using recv instead of read, and,
conversely, send instead of write gives you a very slight speedup,
most of my problem here was a runaway while loop in another thread
(while true do; end seems to take up a lot of time).

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

From jeremy at bitsweat.net  Wed Feb 28 19:28:45 2007
From: jeremy at bitsweat.net (Jeremy Kemper)
Date: Wed, 28 Feb 2007 16:28:45 -0800
Subject: [Mongrel] Deployement options
In-Reply-To: <f4cd26df0702281402p3568a8a2w437474ef73495809@mail.gmail.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
	<f4cd26df0702271618k538ecbd0nd81f3394cc6ff0f5@mail.gmail.com>
	<69a2885c0702281257l38bf34d9kcdc392dd836e3b36@mail.gmail.com>
	<f4cd26df0702281402p3568a8a2w437474ef73495809@mail.gmail.com>
Message-ID: <69a2885c0702281628x7d125195qc8296d59422de778@mail.gmail.com>

On 2/28/07, Kirk Haines <wyhaines at gmail.com> wrote:
>
> On 2/28/07, Jeremy Kemper <jeremy at bitsweat.net> wrote:
>
> > This is true. However, his assertion is valid: it's a must for any web
> app
> > that uses blocking API calls, like executing queries using the native
> mysql
> > and postgres clients. That's just life with Ruby threads.
>
> I have oodles of dynamic web sites and applications that make blocking
> API calls yet can still sustain hit rates in the 50-200/second range
> (depending on the site) under a single mongrel.  They bear up just
> fine to bursty traffic when people are checking their fund prices in
> the evenings.


Great anecdote. I've had similar experience with Mongrel.

There are situations where clustering multiple backends is necessary,
> for sure, but it's possible to handle an exceptional amount of
> dynamic, db-interactive traffic in a single ruby process.


"It's a must" is too strong. I meant to illuminate that it's not just a
"must for Rails." That's true for other reasons.

For example: you have an operation that obtains a write lock on a db row and
does some work. Concurrent requests ought to just wait on the lock and
proceed when available, but Ruby threads will deadlock on the API call since
waiting on the lock prevents the worker thread that obtained it from
finishing.

Whether this is an edge case or a common case is up to your application.

I think a preforking Mongrel would be the biggest positive change for Ruby
web app deployment since its introduction. Nearly zero config; just gem
install and go.

jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070228/9e4b72d5/attachment.html 

From jeremy at bitsweat.net  Wed Feb 28 19:36:44 2007
From: jeremy at bitsweat.net (Jeremy Kemper)
Date: Wed, 28 Feb 2007 16:36:44 -0800
Subject: [Mongrel] Deployement options
In-Reply-To: <20070228171606.5ce3b7a2.zedshaw@zedshaw.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
	<FE28BF69-D805-44AB-AC0E-AA499B9C7205@nextengine.com>
	<f4cd26df0702271618k538ecbd0nd81f3394cc6ff0f5@mail.gmail.com>
	<69a2885c0702281257l38bf34d9kcdc392dd836e3b36@mail.gmail.com>
	<20070228171606.5ce3b7a2.zedshaw@zedshaw.com>
Message-ID: <69a2885c0702281636w4b3dfa6drb725570953fef46@mail.gmail.com>

On 2/28/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> ... and eventually people will start asking why there's nearly 10 other
> Ruby web frameworks that run fine in Mongrel without a big lock and do
> nearly the same things as Rails or even use the same technologies as
> Rails.


Yep. I look forward to it, mostly. Often I'm too quick to write it off since
I'm more accustomed to being beaten with it as a FUD stick.

jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070228/92fc8ecd/attachment.html 

From ezmobius at gmail.com  Wed Feb 28 19:39:06 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Wed, 28 Feb 2007 16:39:06 -0800
Subject: [Mongrel] Mongrel upload progress not showing progress on
	production server
In-Reply-To: <cb03bffe0702281404p70316a86p3fc4aed3ae9be0ce@mail.gmail.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
	<20070227144020.e649667c.zedshaw@zedshaw.com>
	<cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>
	<20070228091757.5fae6cf9.zedshaw@zedshaw.com>
	<466af3440702280759x1c5c6815mb34a57b3caa7619f@mail.gmail.com>
	<20070228144637.5d46c106.zedshaw@zedshaw.com>
	<cb03bffe0702281404p70316a86p3fc4aed3ae9be0ce@mail.gmail.com>
Message-ID: <C5573CFE-BE52-4235-9969-15FD68114E6D@brainspl.at>


On Feb 28, 2007, at 2:04 PM, Benjamin Jackson wrote:

> Hey Zed,
>
>> Honestly, the idea of upload progress done this way (with polling  
>> http
>> requests) is a super bad idea in my book.  It's currently a hack to
>> work around a broken UI in the browser, so I try not to steer  
>> people in
>> this direction.
>>
>> What you should do, if you're interested, is contact Ezra at
>> ez at engineyard.com as he does custom setups of this using Merb.  If  
>> you
>> want to do it yourself, http://merb.devjavu.com/ has example code  
>> in it
>> that you can use.
>
> What would you suggest to someone who needs to allow clients to upload
> files of more than a meg or two if not an upload progress script? It's
> difficult to tell someone that they'll need to stare at their monitor
> for a half hour to an hour while the upload churns on with no progress
> :P


	Using a flash uploader widget is the best way you can do this  
currently. You can have a nice multiple uploads at a time flash  
widget  that does the progress bar on the client side like it should  
be. This means no polling *and* you get nice progress bars and can  
select multiple files at once.


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



From zedshaw at zedshaw.com  Wed Feb 28 23:29:53 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 28 Feb 2007 20:29:53 -0800
Subject: [Mongrel] Mongrel upload progress not showing progress on
 production server
In-Reply-To: <cb03bffe0702281404p70316a86p3fc4aed3ae9be0ce@mail.gmail.com>
References: <cb03bffe0702270640s77954a7ai85e07d0e283141be@mail.gmail.com>
	<20070227144020.e649667c.zedshaw@zedshaw.com>
	<cb03bffe0702271832r6924ac20l38b20ab03507ef1a@mail.gmail.com>
	<20070228091757.5fae6cf9.zedshaw@zedshaw.com>
	<466af3440702280759x1c5c6815mb34a57b3caa7619f@mail.gmail.com>
	<20070228144637.5d46c106.zedshaw@zedshaw.com>
	<cb03bffe0702281404p70316a86p3fc4aed3ae9be0ce@mail.gmail.com>
Message-ID: <20070228202953.97ebf162.zedshaw@zedshaw.com>

On Wed, 28 Feb 2007 19:04:25 -0300
"Benjamin Jackson" <bhjackson at gmail.com> wrote:

> Hey Zed,
> 
> > Honestly, the idea of upload progress done this way (with polling http
> > requests) is a super bad idea in my book.  It's currently a hack to
> > work around a broken UI in the browser, so I try not to steer people in
> > this direction.
> >
> > What you should do, if you're interested, is contact Ezra at
> > ez at engineyard.com as he does custom setups of this using Merb.  If you
> > want to do it yourself, http://merb.devjavu.com/ has example code in it
> > that you can use.
> 
> What would you suggest to someone who needs to allow clients to upload
> files of more than a meg or two if not an upload progress script? It's
> difficult to tell someone that they'll need to stare at their monitor
> for a half hour to an hour while the upload churns on with no progress
> :P

First off, an upload of 2-3 mb won't take so long that you have to
provide a second-by-second byte accurate feedback mechanism to them.  A
simple spinner graphic saying "just a moment" is most more than
enough.

If your application is such that you need absolute accuracy on
progress, resumable uploads, validation of the upload, etc. then don't
use HTTP.  It doesn't do any of this and your app will have a mountain
to climb over.

If you need to simply provide a nice way to show progress of really
large files (and again, HTTP wasn't designed for this so you're
basically fixing a browser usability issue) then you should use flash.
There's a few rather nice upload progress meters that don't use this
stupid 2-second HTTP poll mechanism and just do what the rest of the
world does:  keep track of what's been sent over the socket.

In other words, using repeated HTTP requests to ask the server what the
browser has sent in a blow-by-blow accurate way so that you can show
someone what's effectively a spinner for a few seconds or minutes is a
dumb way to use HTTP.  There's other much better tools, especially if
you need to have the upload be reliable in any way.

-- 
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.

From zedshaw at zedshaw.com  Wed Feb 28 23:34:56 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 28 Feb 2007 20:34:56 -0800
Subject: [Mongrel] recv vs. read in HTTPRequest#read_socket
In-Reply-To: <87fy8pew6i.wl%erik.hetzner@ucop.edu>
References: <87bqk8l06r.wl%erik.hetzner@ucop.edu>
	<87fy8pew6i.wl%erik.hetzner@ucop.edu>
Message-ID: <20070228203456.50b5d616.zedshaw@zedshaw.com>

On Wed, 28 Feb 2007 14:47:49 -0800
Erik Hetzner <erik.hetzner at ucop.edu> wrote:

> At Mon, 05 Feb 2007 14:16:44 -0800,
> Erik Hetzner wrote:
> > Hello all,
> >
> > The following change to Mongrel::HttpRequest:
> 
> [?]
> 
> > seems to work for me, and vastly improves the speed of the body
> > processing (quick tests reveal that using IO#read takes about 1 min 40
> > secs. and using Socket#recv takes about 9 secs on an 8.5 mb file). I
> > have been having trouble discovering the difference between read &
> > recv (I am not a socket developer by any means). Can anybody tell me
> > what sort of safety one loses by doing this with recv instead of read?
> > Thanks.
> 
> As a followup, in case it wasn?t obvious, I was far off base here. I
> should have realized that something was wrong with such horrible
> transfer speeds. While it still seems using recv instead of read, and,
> conversely, send instead of write gives you a very slight speedup,
> most of my problem here was a runaway while loop in another thread
> (while true do; end seems to take up a lot of time).

It is interesting, but I believe that I originally used recv and it had
some problems when it came time to actually cooperate with other
threads doing read.  Could be totally bogus fantasy memory though, but
I also know there's only a few places where recv is faster, as you
found.

-- 
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.

From craigkuhns at gmail.com  Wed Feb 28 22:58:15 2007
From: craigkuhns at gmail.com (Craig Kuhns)
Date: Wed, 28 Feb 2007 21:58:15 -0600
Subject: [Mongrel] Deployement options
In-Reply-To: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
References: <20070227054821.39516.qmail@web23402.mail.ird.yahoo.com>
Message-ID: <14adac440702281958p2752125bpb75c0adf64790024@mail.gmail.com>

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