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