From ry at tinyclouds.org  Mon Apr  2 06:34:06 2007
From: ry at tinyclouds.org (Ry Dahl)
Date: Mon, 2 Apr 2007 12:34:06 +0200
Subject: [Mongrel] a new upload progress bar
Message-ID: <21ee31950704020334x28eb96b2t2c6f2458d7823ed9@mail.gmail.com>

I'm modifying techno weenie's progress bar plug-in. Currently it works
by making the browser poll the server, via AJAX, for updates on amount
received. My plug-in provides a handler which will stream updates on
the amount received, thus only one request needs to be made. Also, the
progress can be updated at faster rates since the client doesn't need
to poll. This should reduce loads on both server and client.

It's a work in progress but check it out:
http://four.livejournal.com/747302.html

ry

From blindance at gmail.com  Mon Apr  2 07:43:16 2007
From: blindance at gmail.com (blindance at gmail.com)
Date: Mon, 2 Apr 2007 20:43:16 +0900
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
Message-ID: <474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>

Thank you,


> This is actually a "cross-platform" issue, between Win32 and WOW64 :-P
> Could you test the attached file?

XPSP2 x64
 this process (PID, name): 2192, proc_info.exe
 parent process (PID, name): 3592, <unknown>
 Couldn't create Snapshot
 parent process by thunk (PID, name): 3592, <unknown>


2003SP1 x64
 this process (PID, name): 420, proc_info.exe
 parent process (PID, name): 648, <unknown>
 Couldn't create Snapshot
 parent process by thunk (PID, name): 648, <unknown>


mmm... I guess nothing is changed from the previous proc_info...

From luislavena at gmail.com  Mon Apr  2 12:48:08 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 2 Apr 2007 13:48:08 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
Message-ID: <71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>

On 4/2/07, blindance at gmail.com <blindance at gmail.com> wrote:
> Thank you,
>
>
> > This is actually a "cross-platform" issue, between Win32 and WOW64 :-P
> > Could you test the attached file?
>
> XPSP2 x64
>  this process (PID, name): 2192, proc_info.exe
>  parent process (PID, name): 3592, <unknown>
>  Couldn't create Snapshot
>  parent process by thunk (PID, name): 3592, <unknown>
>
>
> 2003SP1 x64
>  this process (PID, name): 420, proc_info.exe
>  parent process (PID, name): 648, <unknown>
>  Couldn't create Snapshot
>  parent process by thunk (PID, name): 648, <unknown>
>
>
> mmm... I guess nothing is changed from the previous proc_info...

Guess it didn't...

Third round, hope this time we get it right, expected output:

*** CURRENT PROCESS ***
EnumProcessModules (PID, name): 3128      proc_info.exe
Module32First (PID, name): 3128           proc_info.exe
GetProcessImageFileName (PID, name): 3128 \Device\HarddiskVolume5\Programming\So
urces\_sandbox\proc_info.exe

*** PARENT PROCESS ***
EnumProcessModules (PID, name): 4084      cmd.exe
Module32First (PID, name): 4084           cmd.exe
GetProcessImageFileName (PID, name): 4084 \Device\HarddiskVolume2\WINDOWS\system
32\cmd.exe

WinAPI documentation is too confusing about 32-bits process listing
64-bits modules or process... also there is a lot of functions that do
the same from different approaches that aren't compatibles with
previous version of windows.

(i.e. QueryFullProcessImageName is only available in Vista and Windows
Server "Longhorn")...

Maybe I could code some dynamic loading (like psapi in proc_info) to
workaround this case scenario.

Please let me know the results.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_info_3.7z
Type: application/octet-stream
Size: 12719 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070402/ace1f5f3/attachment-0001.obj 

From Daniel.Berger at qwest.com  Mon Apr  2 15:12:01 2007
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Mon, 2 Apr 2007 14:12:01 -0500
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
Message-ID: <7524A45A1A5B264FA4809E2156496CFB0D0F47@ITOMAE2KM01.AD.QINTRA.COM>

<snip>
 
> Maybe I could code some dynamic loading (like psapi in 
> proc_info) to workaround this case scenario.
> 
> Please let me know the results.

Are you just trying to get process information? The sys-proctable
package works on MS Windows. I dropped the psapi approach a long time
ago in favor of OLE + WMI. So long as the WMI service is running, it
should work on any Windows platform.

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 luislavena at gmail.com  Mon Apr  2 15:25:51 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 2 Apr 2007 16:25:51 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0F47@ITOMAE2KM01.AD.QINTRA.COM>
References: <71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB0D0F47@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <71166b3b0704021225v4a794d62rc0792b96a0ecca66@mail.gmail.com>

On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> <snip>
>
> > Maybe I could code some dynamic loading (like psapi in
> > proc_info) to workaround this case scenario.
> >
> > Please let me know the results.
>
> Are you just trying to get process information? The sys-proctable
> package works on MS Windows. I dropped the psapi approach a long time
> ago in favor of OLE + WMI. So long as the WMI service is running, it
> should work on any Windows platform.
>

Thanks Dan for the information, but OLE + WMI is overkill for the
task. Since I support XP, 2003 and Vista on 32bits platforms, using
psapi way is what I wanted.

The dynamic loading of functions under x64 platforms is though, but
could work around it (also, waiting for my OEM Vista to arrive... damn
postal parcels!)

The funny thing is "So long as the WMI service is running" ;-)

Also, I dropped win32-service support on previous releases for a
native, compiled implementation that don't hook or crash the RubyVM
used by Mongrel. Which worked better, until users start jumping to x64
platforms ;-)

Guess that my platform upgrade will be sooner than expected.

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 Daniel.Berger at qwest.com  Mon Apr  2 18:01:53 2007
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Mon, 2 Apr 2007 17:01:53 -0500
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0704021225v4a794d62rc0792b96a0ecca66@mail.gmail.com>
Message-ID: <7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>

> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org 
> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis Lavena
> Sent: Monday, April 02, 2007 1:26 PM
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] mongrel_service fails to get 
> "service.exe" from ppid?
> 
> 
> On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> > <snip>
> >
> > > Maybe I could code some dynamic loading (like psapi in
> > > proc_info) to workaround this case scenario.
> > >
> > > Please let me know the results.
> >
> > Are you just trying to get process information? The sys-proctable 
> > package works on MS Windows. I dropped the psapi approach a 
> long time 
> > ago in favor of OLE + WMI. So long as the WMI service is 
> running, it 
> > should work on any Windows platform.
> >
> 
> Thanks Dan for the information, but OLE + WMI is overkill for 
> the task. Since I support XP, 2003 and Vista on 32bits 
> platforms, using psapi way is what I wanted.

Overkill? It's abstracted away for you:

require 'sys/proctable'
include Sys

ProcTable.ps{ |process| p process.ppid }
 
> The dynamic loading of functions under x64 platforms is 
> though, but could work around it (also, waiting for my OEM 
> Vista to arrive... damn postal parcels!)

With sys-proctable, you needn't worry about such things.

> The funny thing is "So long as the WMI service is running" ;-)

Well, it's enabled by default. So, unless someone goes in and turns it
off, it's running.
 
> Also, I dropped win32-service support on previous releases 
> for a native, compiled implementation that don't hook or 
> crash the RubyVM used by Mongrel. Which worked better, until 
> users start jumping to x64 platforms ;-)

Hm, I really need to revisit win32-service. The whole VC 6 vs VC 8 issue
has proven to be annoying.

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 luislavena at gmail.com  Mon Apr  2 18:50:43 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 2 Apr 2007 19:50:43 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>
References: <71166b3b0704021225v4a794d62rc0792b96a0ecca66@mail.gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <71166b3b0704021550v27bb7094l9c93b553c39fc21c@mail.gmail.com>

On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> > -----Original Message-----
> > From: mongrel-users-bounces at rubyforge.org
> > [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis Lavena
> > Sent: Monday, April 02, 2007 1:26 PM
> > To: mongrel-users at rubyforge.org
> > Subject: Re: [Mongrel] mongrel_service fails to get
> > "service.exe" from ppid?
> >
> >
> > On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> > > <snip>
> > >
> > > > Maybe I could code some dynamic loading (like psapi in
> > > > proc_info) to workaround this case scenario.
> > > >
> > > > Please let me know the results.
> > >
> > > Are you just trying to get process information? The sys-proctable
> > > package works on MS Windows. I dropped the psapi approach a
> > long time
> > > ago in favor of OLE + WMI. So long as the WMI service is
> > running, it
> > > should work on any Windows platform.
> > >
> >
> > Thanks Dan for the information, but OLE + WMI is overkill for
> > the task. Since I support XP, 2003 and Vista on 32bits
> > platforms, using psapi way is what I wanted.
>
> Overkill? It's abstracted away for you:
>
> require 'sys/proctable'
> include Sys
>
> ProcTable.ps{ |process| p process.ppid }
>

Overkill since I no longer use win32-service nor a ruby process as
service, but a stub native service utility that spawn the ruby process
with mongrel.

>[...]
>
> > Also, I dropped win32-service support on previous releases
> > for a native, compiled implementation that don't hook or
> > crash the RubyVM used by Mongrel. Which worked better, until
> > users start jumping to x64 platforms ;-)
>
> Hm, I really need to revisit win32-service. The whole VC 6 vs VC 8 issue
> has proven to be annoying.
>

As I said previously and a few months back, ruby + green_threads +
sockets + rails + win32 != stable solution.

The most stable and gracefully stoppable I got was using a compiled
service and leave ruby just for mongrel.

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

From luislavena at gmail.com  Mon Apr  2 18:56:00 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 2 Apr 2007 19:56:00 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>
References: <71166b3b0704021225v4a794d62rc0792b96a0ecca66@mail.gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <71166b3b0704021556l2022387aoa25acf2e4352ef6f@mail.gmail.com>

On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> [...]
>
> > Also, I dropped win32-service support on previous releases
> > for a native, compiled implementation that don't hook or
> > crash the RubyVM used by Mongrel. Which worked better, until
> > users start jumping to x64 platforms ;-)
>
> Hm, I really need to revisit win32-service. The whole VC 6 vs VC 8 issue
> has proven to be annoying.

I have started using Windows SDK Update for Vista [1] which sport VC8
sp1, Platform SDK headers + MSDN help, using just 500MB of HDD. This
is the same compiler used by Visual Studio, and most important is
*free*

I'm trying to get everything setup and drop VC6 for good sake, even if
I have to recompile every extension available.

Maybe we could talk about this off the list if you're interested?

[1] http://www.microsoft.com/downloads/details.aspx?FamilyID=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en

-- 
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 blindance at gmail.com  Tue Apr  3 06:49:21 2007
From: blindance at gmail.com (blindance at gmail.com)
Date: Tue, 3 Apr 2007 19:49:21 +0900
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
	<71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
Message-ID: <474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>

> Maybe I could code some dynamic loading (like psapi in proc_info) to
> workaround this case scenario.
>
> Please let me know the results.

WinXP x64
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 2020      proc_info.exe
 Module32First (PID, name): 2020           proc_info.exe
 GetProcessImageFileName (PID, name): 2020
\Device\HarddiskVolume1\Documents and
Settings\Administrator\desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 2416      <unknown>
 Module32First (PID, name): 2416           Error Creating Snap (SNAPMODULE)
 GetLastError: 299Only part of a ReadProcessMemory or
WriteProcessMemory request was completed.
 <unknown>
 GetProcessImageFileName (PID, name): 2416
\Device\HarddiskVolume1\WINDOWS\system32\cmd.exe



Win2003 x64
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 1856      proc_info.exe
 Module32First (PID, name): 1856           proc_info.exe
 GetProcessImageFileName (PID, name): 1856
\Device\HarddiskVolume2\Documents and
Settings\VMWServ\desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 1584      <unknown>
 Module32First (PID, name): 1584           Error Creating Snap (SNAPMODULE)
 GetLastError: 299Only part of a ReadProcessMemory or
WriteProcessMemory request was completed.
 <unknown>
 GetProcessImageFileName (PID, name): 1584
\Device\HarddiskVolume2\WINDOWS\system32\cmd.exe



Woot!

I'm happy if this would help even a little.

From cremes.devlist at mac.com  Tue Apr  3 08:30:16 2007
From: cremes.devlist at mac.com (cremes.devlist at mac.com)
Date: Tue, 3 Apr 2007 07:30:16 -0500
Subject: [Mongrel] [OT] Ragel and FSM tutorials
Message-ID: <D6347FBF-8FF9-4C9C-907D-7371434D39B2@mac.com>

This is off-topic.

I'm hoping someone on this list can point me towards more general  
information on finite state machines, their definition, how to build  
them, determining when to apply them, etc. I read Zed's blog entry  
from way back when covering Ragel [1] but he hasn't followed it up  
and there aren't many pointers to external information.

I've googled around and found a reasonable amount of information on  
Ragel, but I'm not so interested in knowing how to use that  
particular tool as I am in learning about finite state machines *in  
general*.

Thanks to anyone who has good pointers on docs, tutorials or good  
source code examples (any language). I'd also appreciate any  
suggestions on books (college texts or whatever) that cover this  
subject.

cr

From serdar at kilic.net  Tue Apr  3 09:12:13 2007
From: serdar at kilic.net (Serdar Kilic)
Date: Tue, 3 Apr 2007 23:12:13 +1000
Subject: [Mongrel] MediaTemple Image upload
Message-ID: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>

Hi All,
I'm hosting with MediaTemple who are currently using 0.3.3 of mongrel  
on their GridServer. My rails app has an image upload facility  
whereby if you upload a large image (e.g. 5Mb) mongrel crashes. I've  
requested an upgrade to the latest version of mongrel but don't  
believe that's going to happen too soon. I'm not getting too much  
information in the log files too pass on, other than what appears to  
be a memory allocation error (my container is 64Mb). Any ideas?

Regards,
Serdar

From craigkuhns at gmail.com  Tue Apr  3 10:17:10 2007
From: craigkuhns at gmail.com (Craig Kuhns)
Date: Tue, 3 Apr 2007 10:17:10 -0400
Subject: [Mongrel] MediaTemple Image upload
In-Reply-To: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
References: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
Message-ID: <14adac440704030717t2cae9bf5r6fff2f3a50265259@mail.gmail.com>

>From my understanding its not good practice to use rails for large
file uploads because it locks the thread up.  Maybe look into
integrating merb into your app to handle the file uploads.  I don't
know if that will fix your problem or not, but it will improve your
performance.

Craig

On 4/3/07, Serdar Kilic <serdar at kilic.net> wrote:
> Hi All,
> I'm hosting with MediaTemple who are currently using 0.3.3 of mongrel
> on their GridServer. My rails app has an image upload facility
> whereby if you upload a large image (e.g. 5Mb) mongrel crashes. I've
> requested an upgrade to the latest version of mongrel but don't
> believe that's going to happen too soon. I'm not getting too much
> information in the log files too pass on, other than what appears to
> be a memory allocation error (my container is 64Mb). Any ideas?
>
> Regards,
> Serdar
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From zedshaw at zedshaw.com  Tue Apr  3 11:14:01 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 3 Apr 2007 11:14:01 -0400
Subject: [Mongrel] MediaTemple Image upload
In-Reply-To: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
References: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
Message-ID: <20070403111401.646f977e.zedshaw@zedshaw.com>

On Tue, 3 Apr 2007 23:12:13 +1000
Serdar Kilic <serdar at kilic.net> wrote:

> Hi All,
> I'm hosting with MediaTemple who are currently using 0.3.3 of mongrel  
> on their GridServer. My rails app has an image upload facility  
> whereby if you upload a large image (e.g. 5Mb) mongrel crashes. I've  
> requested an upgrade to the latest version of mongrel but don't  
> believe that's going to happen too soon. I'm not getting too much  
> information in the log files too pass on, other than what appears to  
> be a memory allocation error (my container is 64Mb). Any ideas?

Mongrel isn't crashing, most likely you have too little RAM and the
linux oomkiller is killing Mongrel off when it gets too big.  Take your
app, put it on a computer with lots of ram, and then try a bunch of
giant uploads to make sure.  Then, if it still works simply go buy more
RAM from MT.

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

From luislavena at gmail.com  Tue Apr  3 12:13:52 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 3 Apr 2007 13:13:52 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
	<71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
	<474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>
Message-ID: <71166b3b0704030913k233ca8cy6c6f026ab5ebcf41@mail.gmail.com>

On 4/3/07, blindance at gmail.com <blindance at gmail.com> wrote:
> > Maybe I could code some dynamic loading (like psapi in proc_info) to
> > workaround this case scenario.
> >
> > Please let me know the results.
>
> WinXP x64
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 2020      proc_info.exe
>  Module32First (PID, name): 2020           proc_info.exe
>  GetProcessImageFileName (PID, name): 2020
> \Device\HarddiskVolume1\Documents and
> Settings\Administrator\desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 2416      <unknown>
>  Module32First (PID, name): 2416           Error Creating Snap (SNAPMODULE)
>  GetLastError: 299Only part of a ReadProcessMemory or
> WriteProcessMemory request was completed.
>  <unknown>
>  GetProcessImageFileName (PID, name): 2416
> \Device\HarddiskVolume1\WINDOWS\system32\cmd.exe
>
>
>
> Win2003 x64
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 1856      proc_info.exe
>  Module32First (PID, name): 1856           proc_info.exe
>  GetProcessImageFileName (PID, name): 1856
> \Device\HarddiskVolume2\Documents and
> Settings\VMWServ\desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 1584      <unknown>
>  Module32First (PID, name): 1584           Error Creating Snap (SNAPMODULE)
>  GetLastError: 299Only part of a ReadProcessMemory or
> WriteProcessMemory request was completed.
>  <unknown>
>  GetProcessImageFileName (PID, name): 1584
> \Device\HarddiskVolume2\WINDOWS\system32\cmd.exe
>
>
>
> Woot!
>
> I'm happy if this would help even a little.


Yeah, I'm happy too!

It seems that ReadProcessMemory (which is called from Module32First
API), fail to get information from 64-bits parent process.

I'll like to know from Vista users that hang on the list about their
results too, since WinAPI is always a pain to get working on different
platforms.

Anyway, based on these results I'll patch ServiceFB and prepare a
pre-release of mongrel_service with logging capabilities too (which is
waiting in my out-box to be commited).

Thanks for your help and feedback.

Later,

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

From mikeisgreat at gmail.com  Tue Apr  3 12:23:43 2007
From: mikeisgreat at gmail.com (Michael Steinfeld)
Date: Tue, 3 Apr 2007 12:23:43 -0400
Subject: [Mongrel] mongrel cluster restart with capistrano fails but
	manually works
Message-ID: <3d5db09e0704030923m563fcbcdiede0e36f668b8c20@mail.gmail.com>

Hi all,

I am out of my head here...

I have a 3 node cluster with 10 mongrels running on each. When I
deploy, I break all the mongrels every time. I have tried just about
everything. I can restart my mongrels without a hitch manually, it's
only when I use cap deploy. Maybe I am missing something here... so if
I can get some help it would be appreciated. The errors are the
typical mongrel pid errors, I can paste them if need be.

I have mongrel_cluster.yml sym linked from
/{current_path}/config/mongrel_cluster.yml to
/etc/mongrel_cluster/mongrel_cluster.yml

cwd: /home/app/current
port: "8000"
address: 127.0.0.1
pid_file: log/mongrel.pid
environment: production
servers: 10



here is a snippet of  my deploy.rb

<snip>

require 'mongrel_cluster/recipes'
require 'capistrano'

# below snipped for brevity
role :web
role :app

...


# restart mongrel with /etc/init.d/mongrel_cluster restart
desc "Restart the web server"
task :restart, :roles => :app do
  begin
    run "sudo /etc/init.d/mongrel_cluster stop"
    run "sleep 5"
    run "sudo /etc/init.d/mongrel_cluster start"
end

...
# couple of tasks to chown some files and directories
desc "Only app servers get this applied to them post-deployment"
task :after_app_deploy, :roles=>:app do
  sudo "chown -PRf foo:foo       #{deploy_to}/current/"
  sudo "chown -PRf foo:foo       #{deploy_to}/releases/"
  sudo "chmod -Rf 755                     #{deploy_to}/releases/"
  sudo "chmod -Rf 750                     #{deploy_to}/current/public/"
end

desc "Apache restarter"
task :kick_apache, :roles=>:web do
  sudo "/usr/local/apache/bin/apachectl restart"
end


Now, mongrel gets restarted even if I don't use the above when I
restart when I run deploy.. but I don't see where I can change that or
if that is in fact causing the problem.

for whatever reason, mongrels never start on 8000 - 8004, but do start
from 8005 - 8009, so I am thinking something in the cap script. I did
migrate recently from lighty+fastcgi to apache+mongrel
and I have 10 mongrels per machine on ports 8000 - 8009. I was
thinking that dispatch was screwing up ports 8000-04 somehow.. (
totally guessing )

I was thinking about writing a task similar to below... but I think it
is overkill.

desc "Kill all the pids in case there are some zombies and remove the
.pid files"
task :before_before_deploy, roles => :app do
  begin
    run "sudo kill -9 `ps -ef | grep mongrel | egrep -v grep | awk
'{print $2}'`"
    run "cd /home/user/app/log && sudo rm -rf *.pid"
  end

task :after_after_deploy, roles => :app do
  begin
    " sudo /etc/init.d/mongrel_cluster start"
  end

</snip>


Hopefully someone can see something that I don't.
Thanks for your time

-- 
-mike

From jjhogue at sbcglobal.net  Tue Apr  3 12:26:13 2007
From: jjhogue at sbcglobal.net (Jim Hogue)
Date: Tue, 3 Apr 2007 12:26:13 -0400
Subject: [Mongrel] [OT] Ragel and FSM tutorials
References: <D6347FBF-8FF9-4C9C-907D-7371434D39B2@mac.com>
Message-ID: <004501c7760c$cc9c02d0$0400a8c0@DEN2>

(Off topic, but just in case others are interested :-).

You should probably take a look at some computer science college level 
theory books.  Look for "Automata Theory", "Turing machines", 
"deterministic finite automation", and "non-deterministic finite 
automation".  The turning machine is the classic example.

I have 2 classic texts on my shelf with good coverage - "Introduction 
to Automata Theory, Languages and Computation" and "The design and 
Analysis of Computer Algorithms" (Aho, Hopcroft, and Ullman authors). 
Note that any text used for a comp sci theory course should have 
coverage of this stuff (I am guessing that the 2 I mentioned are out 
of print since it has been a zillion years since I got my comp sci 
degree :-).  Putting "Hopcroft" in the search pane at Amazon brings up 
a number of texts.

In college we had an implementation of a Turing machine using macros 
in vi.  It was a classic.

I would guess that there are other implementations of Turing machines 
out there.

    - Jim

----- Original Message ----- 
From: <cremes.devlist at mac.com>
To: <mongrel-users at rubyforge.org>
Sent: Tuesday, April 03, 2007 8:30 AM
Subject: [Mongrel] [OT] Ragel and FSM tutorials


> This is off-topic.
>
> I'm hoping someone on this list can point me towards more general
> information on finite state machines, their definition, how to build
> them, determining when to apply them, etc. I read Zed's blog entry
> from way back when covering Ragel [1] but he hasn't followed it up
> and there aren't many pointers to external information.
>
> I've googled around and found a reasonable amount of information on
> Ragel, but I'm not so interested in knowing how to use that
> particular tool as I am in learning about finite state machines *in
> general*.
>
> Thanks to anyone who has good pointers on docs, tutorials or good
> source code examples (any language). I'd also appreciate any
> suggestions on books (college texts or whatever) that cover this
> subject.
>
> cr
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 



From subimage at gmail.com  Tue Apr  3 14:05:50 2007
From: subimage at gmail.com (subimage interactive)
Date: Tue, 3 Apr 2007 11:05:50 -0700
Subject: [Mongrel] Mongrels dying on FreeBSD 5.5-STABLE......why why why?
Message-ID: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>

Yo Zed and everyone else, I'm having a major problem I'm hoping someone can
help with.

I've been running mongrel clusters for a few months with no problems on a
couple of my boxes. They both run Debian...

I recently moved one of my older Rails apps on a FreeBSD 5.5 box to mongrel
as well. Everything runs quickly and wonderfully - when it's running! My
problem is that over time each one of my 5 mongrel processes die. There's
nothing in the mongrel.log telling me why they die. They just die.

My question then is two-fold

1: Why are my mongrel processes dying? Where's the log information?
2: Can these guys be automatically restarted somehow???

I'm on mongrel 1.0.1 and mongrel_cluster 1.0.1.1

HELP! My clients are going apeshit and want to cut my throat :p


--------------------
seth at subimage interactive
-----
http://www.subimage.com
http://sublog.subimage.com
-----
http://www.getcashboard.com
http://dev.subimage.com/projects/substruct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070403/f8f32bdb/attachment.html 

From zedshaw at zedshaw.com  Tue Apr  3 15:05:08 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 3 Apr 2007 15:05:08 -0400
Subject: [Mongrel] Mongrels dying on FreeBSD 5.5-STABLE......why why why?
In-Reply-To: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>
References: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>
Message-ID: <20070403150508.5350bf33.zedshaw@zedshaw.com>

On Tue, 3 Apr 2007 11:05:50 -0700
"subimage interactive" <subimage at gmail.com> wrote:

> Yo Zed and everyone else, I'm having a major problem I'm hoping someone can
> help with.
> 
> I've been running mongrel clusters for a few months with no problems on a
> couple of my boxes. They both run Debian...
> 
> I recently moved one of my older Rails apps on a FreeBSD 5.5 box to mongrel
> as well. Everything runs quickly and wonderfully - when it's running! My
> problem is that over time each one of my 5 mongrel processes die. There's
> nothing in the mongrel.log telling me why they die. They just die.

You'll have to be more specific than that.  "Die" could mean they crash
and the process goes away, or that the process stops responding to
requests.  For the first kind you'll need to turn on core dumps and do
a gdb inspect after.  With the second one you've gotta list out the
various gems you're using and when you find a dead mongrel then attach
to it with strace or gdb to find out where it's blocked.

> My question then is two-fold
> 
> 1: Why are my mongrel processes dying? Where's the log information?
> 2: Can these guys be automatically restarted somehow???

Yes, monit works great, other folks like runit.  There's a bunch of
tutorials for both.

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

From subimage at gmail.com  Tue Apr  3 15:18:01 2007
From: subimage at gmail.com (subimage interactive)
Date: Tue, 3 Apr 2007 12:18:01 -0700
Subject: [Mongrel] Mongrels dying on FreeBSD 5.5-STABLE......why why why?
In-Reply-To: <20070403150508.5350bf33.zedshaw@zedshaw.com>
References: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>
	<20070403150508.5350bf33.zedshaw@zedshaw.com>
Message-ID: <7aff9b4c0704031218n4c752f7fw448666f0e7fa677@mail.gmail.com>

> > I recently moved one of my older Rails apps on a FreeBSD 5.5 box to
> mongrel
> > as well. Everything runs quickly and wonderfully - when it's running! My
> > problem is that over time each one of my 5 mongrel processes die.
> There's
> > nothing in the mongrel.log telling me why they die. They just die.
>
> You'll have to be more specific than that.  "Die" could mean they crash
> and the process goes away, or that the process stops responding to
> requests.  For the first kind you'll need to turn on core dumps and do
> a gdb inspect after.  With the second one you've gotta list out the
> various gems you're using and when you find a dead mongrel then attach
> to it with strace or gdb to find out where it's blocked.


Die meaning, dead...process is crashed and gone. How do I turn on core
dumps? This a mongrel switch?


> My question then is two-fold
> >
> > 1: Why are my mongrel processes dying? Where's the log information?
> > 2: Can these guys be automatically restarted somehow???
>
> Yes, monit works great, other folks like runit.  There's a bunch of
> tutorials for both.
>
>
Got a good starting point (besides google) for running either with a
mongrel_cluster?

Thanks for the quick response.

--------------------
seth at subimage interactive
-----
http://www.subimage.com
http://sublog.subimage.com
-----
http://www.getcashboard.com
http://dev.subimage.com/projects/substruct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070403/e427a80e/attachment.html 

From jgeiger at gmail.com  Tue Apr  3 16:19:23 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 3 Apr 2007 15:19:23 -0500
Subject: [Mongrel] Mongrels dying on FreeBSD 5.5-STABLE......why why why?
In-Reply-To: <7aff9b4c0704031218n4c752f7fw448666f0e7fa677@mail.gmail.com>
References: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>
	<20070403150508.5350bf33.zedshaw@zedshaw.com>
	<7aff9b4c0704031218n4c752f7fw448666f0e7fa677@mail.gmail.com>
Message-ID: <466af3440704031319t63bbf8b4j3ed82d10581015fb@mail.gmail.com>

You should able to do a search for monit and mongrel on this list or
google and get more than enough.

http://www.tildeslash.com/monit/


On 4/3/07, subimage interactive <subimage at gmail.com> wrote:
>
>
> > > I recently moved one of my older Rails apps on a FreeBSD 5.5 box to
> mongrel
> > > as well. Everything runs quickly and wonderfully - when it's running! My
> > > problem is that over time each one of my 5 mongrel processes die.
> There's
> > > nothing in the mongrel.log telling me why they die. They just die.
> >
> > You'll have to be more specific than that.  "Die" could mean they crash
> > and the process goes away, or that the process stops responding to
> > requests.  For the first kind you'll need to turn on core dumps and do
> > a gdb inspect after.  With the second one you've gotta list out the
> > various gems you're using and when you find a dead mongrel then attach
> > to it with strace or gdb to find out where it's blocked.
>
>
> Die meaning, dead...process is crashed and gone. How do I turn on core
> dumps? This a mongrel switch?
>
>
> > > My question then is two-fold
> > >
> > > 1: Why are my mongrel processes dying? Where's the log information?
> > > 2: Can these guys be automatically restarted somehow???
> >
> > Yes, monit works great, other folks like runit.  There's a bunch of
> > tutorials for both.
> >
> >
>
> Got a good starting point (besides google) for running either with a
> mongrel_cluster?
>
> Thanks for the quick response.
>
>
> --------------------
> seth at subimage interactive
> -----
> http://www.subimage.com
> http://sublog.subimage.com
> -----
> http://www.getcashboard.com
> http://dev.subimage.com/projects/substruct
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From bhjackson at gmail.com  Tue Apr  3 16:33:59 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Tue, 3 Apr 2007 17:33:59 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I doing
	wrong?
Message-ID: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>

I tried benchmarking the same site behind an NGINX proxy with both
fastcgi and mongrel, and for some reason mongrel is performing pretty
poorly in comparison.

Any idea what I might be doing wrong?

Here's my benchmarks for 1 fcgi:

Server Software:        nginx/0.4.0
Server Hostname:        eship.com.br
Server Port:            80

Document Path:          /
Document Length:        95 bytes

Concurrency Level:      100
Time taken for tests:   10.437 seconds
Complete requests:      1000
Failed requests:        0
Broken pipe errors:     0
Non-2xx responses:      1000
Total transferred:      366000 bytes
HTML transferred:       95000 bytes
Requests per second:    95.81 [#/sec] (mean)
Time per request:       1043.70 [ms] (mean)
Time per request:       10.44 [ms] (mean, across all concurrent requests)
Transfer rate:          35.07 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:      182   435  294.5    430  3428
Processing:   371   569  296.5    505  2674
Waiting:      189   569  296.5    505  2674
Total:        371  1004  418.8    938  3963




And for 2 mongrels:

Server Software:        nginx/0.4.0
Server Hostname:        eship.com.br
Server Port:            80

Document Path:          /
Document Length:        95 bytes

Concurrency Level:      100
Time taken for tests:   13.041 seconds
Complete requests:      1000
Failed requests:        0
Broken pipe errors:     0
Non-2xx responses:      1000
Total transferred:      417000 bytes
HTML transferred:       95000 bytes
Requests per second:    76.68 [#/sec] (mean)
Time per request:       1304.10 [ms] (mean)
Time per request:       13.04 [ms] (mean, across all concurrent requests)
Transfer rate:          31.98 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:      175   234  292.9    187  3099
Processing:   204   897  806.4    611  5619
Waiting:      187   897  806.5    611  5619
Total:        365  1132  840.6    842  5804

From snacktime at gmail.com  Tue Apr  3 16:39:28 2007
From: snacktime at gmail.com (snacktime)
Date: Tue, 3 Apr 2007 13:39:28 -0700
Subject: [Mongrel] monit vs mongrel cluster
Message-ID: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>

Is there anything mongrel cluster gives you that monit doesn't?  I'll
be using monit to monitor a number of other services anyways, so it
seems logical to just use it for everything including mongrel.

Chris

From jason at joyent.com  Tue Apr  3 16:39:52 2007
From: jason at joyent.com (Jason A. Hoffman)
Date: Tue, 3 Apr 2007 13:39:52 -0700
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
Message-ID: <6D595D32-7B83-49D7-9BCC-84F4E8C48E45@joyent.com>

Looking even at your standard deviations, I don't see much of a  
difference between these. What's your SD on the req/sec?

Regards, Jason

On Apr 3, 2007, at 1:33 PM, Benjamin Jackson wrote:

> I tried benchmarking the same site behind an NGINX proxy with both
> fastcgi and mongrel, and for some reason mongrel is performing pretty
> poorly in comparison.
>
> Any idea what I might be doing wrong?
>
> Here's my benchmarks for 1 fcgi:
>
> Server Software:        nginx/0.4.0
> Server Hostname:        eship.com.br
> Server Port:            80
>
> Document Path:          /
> Document Length:        95 bytes
>
> Concurrency Level:      100
> Time taken for tests:   10.437 seconds
> Complete requests:      1000
> Failed requests:        0
> Broken pipe errors:     0
> Non-2xx responses:      1000
> Total transferred:      366000 bytes
> HTML transferred:       95000 bytes
> Requests per second:    95.81 [#/sec] (mean)
> Time per request:       1043.70 [ms] (mean)
> Time per request:       10.44 [ms] (mean, across all concurrent  
> requests)
> Transfer rate:          35.07 [Kbytes/sec] received
>
> Connnection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:      182   435  294.5    430  3428
> Processing:   371   569  296.5    505  2674
> Waiting:      189   569  296.5    505  2674
> Total:        371  1004  418.8    938  3963
>
>
>
>
> And for 2 mongrels:
>
> Server Software:        nginx/0.4.0
> Server Hostname:        eship.com.br
> Server Port:            80
>
> Document Path:          /
> Document Length:        95 bytes
>
> Concurrency Level:      100
> Time taken for tests:   13.041 seconds
> Complete requests:      1000
> Failed requests:        0
> Broken pipe errors:     0
> Non-2xx responses:      1000
> Total transferred:      417000 bytes
> HTML transferred:       95000 bytes
> Requests per second:    76.68 [#/sec] (mean)
> Time per request:       1304.10 [ms] (mean)
> Time per request:       13.04 [ms] (mean, across all concurrent  
> requests)
> Transfer rate:          31.98 [Kbytes/sec] received
>
> Connnection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:      175   234  292.9    187  3099
> Processing:   204   897  806.4    611  5619
> Waiting:      187   897  806.5    611  5619
> Total:        365  1132  840.6    842  5804
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 223 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070403/885eef57/attachment.bin 

From ezmobius at gmail.com  Tue Apr  3 17:32:50 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 3 Apr 2007 14:32:50 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
Message-ID: <6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>


On Apr 3, 2007, at 1:39 PM, snacktime wrote:

> Is there anything mongrel cluster gives you that monit doesn't?  I'll
> be using monit to monitor a number of other services anyways, so it
> seems logical to just use it for everything including mongrel.
>
> Chris
>

Chris-

	WHen you use monit you can still use mongrel_cluster to manage it.  
You need the latest pre release of mongrel_cluster. This is the best  
configuration I've been able to come up with for 64Bit systems. If  
your on 32bit system then you can lower the memory limits by about  
20-30%

check process mongrel_<%= @username %>_5000
   with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/<% 
= @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=  
@username %>/current/config/mongrel_cluster.yml --clean --only 5000"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_<%= @username %>_5001
   with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/<% 
= @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=  
@username %>/current/config/mongrel_cluster.yml --clean --only 5001"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_<%= @username %>_5002
   with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/<% 
= @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=  
@username %>/current/config/mongrel_cluster.yml --clean --only 5002"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel


	I wen't for a while using my own scripts to start and stop mongrel  
without using mongrel_cluster. But it works more reliably when I use  
mongrel_cluster and monit together.

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



From njvack at wisc.edu  Tue Apr  3 17:34:09 2007
From: njvack at wisc.edu (Nathan Vack)
Date: Tue, 3 Apr 2007 16:34:09 -0500
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
Message-ID: <CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>

Are you running these tests cold? You probably want to throw out the  
first bunch of requests (say, 1000) to better simulate real-world  
running conditions.

Also, what's up with the non-2xx responses? Are you benchmarking an  
error page or something?

-Nate

On Apr 3, 2007, at 3:33 PM, Benjamin Jackson wrote:

> I tried benchmarking the same site behind an NGINX proxy with both
> fastcgi and mongrel, and for some reason mongrel is performing pretty
> poorly in comparison.
>
> Any idea what I might be doing wrong?
>
> Here's my benchmarks for 1 fcgi:
>
> Server Software:        nginx/0.4.0
> Server Hostname:        eship.com.br
> Server Port:            80
>
> Document Path:          /
> Document Length:        95 bytes
>
> Concurrency Level:      100
> Time taken for tests:   10.437 seconds
> Complete requests:      1000
> Failed requests:        0
> Broken pipe errors:     0
> Non-2xx responses:      1000
> Total transferred:      366000 bytes
> HTML transferred:       95000 bytes
> Requests per second:    95.81 [#/sec] (mean)
> Time per request:       1043.70 [ms] (mean)
> Time per request:       10.44 [ms] (mean, across all concurrent  
> requests)
> Transfer rate:          35.07 [Kbytes/sec] received
>
> Connnection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:      182   435  294.5    430  3428
> Processing:   371   569  296.5    505  2674
> Waiting:      189   569  296.5    505  2674
> Total:        371  1004  418.8    938  3963
>
>
>
>
> And for 2 mongrels:
>
> Server Software:        nginx/0.4.0
> Server Hostname:        eship.com.br
> Server Port:            80
>
> Document Path:          /
> Document Length:        95 bytes
>
> Concurrency Level:      100
> Time taken for tests:   13.041 seconds
> Complete requests:      1000
> Failed requests:        0
> Broken pipe errors:     0
> Non-2xx responses:      1000
> Total transferred:      417000 bytes
> HTML transferred:       95000 bytes
> Requests per second:    76.68 [#/sec] (mean)
> Time per request:       1304.10 [ms] (mean)
> Time per request:       13.04 [ms] (mean, across all concurrent  
> requests)
> Transfer rate:          31.98 [Kbytes/sec] received
>
> Connnection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:      175   234  292.9    187  3099
> Processing:   204   897  806.4    611  5619
> Waiting:      187   897  806.5    611  5619
> Total:        365  1132  840.6    842  5804
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


From kevwil at gmail.com  Tue Apr  3 17:55:04 2007
From: kevwil at gmail.com (Kevin Williams)
Date: Tue, 3 Apr 2007 15:55:04 -0600
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
Message-ID: <683a886f0704031455k3d7c2195x47ff65a44651b98e@mail.gmail.com>

I do pretty much the same thing with monit, except I don't use
mongrel_cluster. Because monit needs to handle each instance of
mongrel separately, I didn't see the point in using a clustering tool
to handle single instances. It's a minor difference, really -
specifying the mongrel_rails options in the monitrc file vs. the
config/mongrel_cluster.yml file. Either way, I use monit to restart a
mongrel cluster (or "group" as monit calls it).

I'd say monit offers _more_ than mongrel_cluster, but I'm no expert.


On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
>
> > Is there anything mongrel cluster gives you that monit doesn't?  I'll
> > be using monit to monitor a number of other services anyways, so it
> > seems logical to just use it for everything including mongrel.
> >
> > Chris
> >
>
> Chris-
>
>         WHen you use monit you can still use mongrel_cluster to manage it.
> You need the latest pre release of mongrel_cluster. This is the best
> configuration I've been able to come up with for 64Bit systems. If
> your on 32bit system then you can lower the memory limits by about
> 20-30%
>
> check process mongrel_<%= @username %>_5000
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_<%= @username %>_5001
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_<%= @username %>_5002
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
>
>         I wen't for a while using my own scripts to start and stop mongrel
> without using mongrel_cluster. But it works more reliably when I use
> mongrel_cluster and monit together.
>
> Cheers-
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
Cheers,

Kevin Williams
http://www.almostserio.us/

"Any sufficiently advanced technology is indistinguishable from
Magic." - Arthur C. Clarke

From kevwil at gmail.com  Tue Apr  3 17:58:36 2007
From: kevwil at gmail.com (Kevin Williams)
Date: Tue, 3 Apr 2007 15:58:36 -0600
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
Message-ID: <683a886f0704031458v722f6373o4c7a1b31dfbfe9b0@mail.gmail.com>

You might try a more current version of Nginx and see if the proxying
performance has improved compared to the FastCGI support. You're using
a fairly old version.

http://nginx.net/CHANGES


On 4/3/07, Nathan Vack <njvack at wisc.edu> wrote:
> Are you running these tests cold? You probably want to throw out the
> first bunch of requests (say, 1000) to better simulate real-world
> running conditions.
>
> Also, what's up with the non-2xx responses? Are you benchmarking an
> error page or something?
>
> -Nate
>
> On Apr 3, 2007, at 3:33 PM, Benjamin Jackson wrote:
>
> > I tried benchmarking the same site behind an NGINX proxy with both
> > fastcgi and mongrel, and for some reason mongrel is performing pretty
> > poorly in comparison.
> >
> > Any idea what I might be doing wrong?
> >
> > Here's my benchmarks for 1 fcgi:
> >
> > Server Software:        nginx/0.4.0
> > Server Hostname:        eship.com.br
> > Server Port:            80
> >
> > Document Path:          /
> > Document Length:        95 bytes
> >
> > Concurrency Level:      100
> > Time taken for tests:   10.437 seconds
> > Complete requests:      1000
> > Failed requests:        0
> > Broken pipe errors:     0
> > Non-2xx responses:      1000
> > Total transferred:      366000 bytes
> > HTML transferred:       95000 bytes
> > Requests per second:    95.81 [#/sec] (mean)
> > Time per request:       1043.70 [ms] (mean)
> > Time per request:       10.44 [ms] (mean, across all concurrent
> > requests)
> > Transfer rate:          35.07 [Kbytes/sec] received
> >
> > Connnection Times (ms)
> >               min  mean[+/-sd] median   max
> > Connect:      182   435  294.5    430  3428
> > Processing:   371   569  296.5    505  2674
> > Waiting:      189   569  296.5    505  2674
> > Total:        371  1004  418.8    938  3963
> >
> >
> >
> >
> > And for 2 mongrels:
> >
> > Server Software:        nginx/0.4.0
> > Server Hostname:        eship.com.br
> > Server Port:            80
> >
> > Document Path:          /
> > Document Length:        95 bytes
> >
> > Concurrency Level:      100
> > Time taken for tests:   13.041 seconds
> > Complete requests:      1000
> > Failed requests:        0
> > Broken pipe errors:     0
> > Non-2xx responses:      1000
> > Total transferred:      417000 bytes
> > HTML transferred:       95000 bytes
> > Requests per second:    76.68 [#/sec] (mean)
> > Time per request:       1304.10 [ms] (mean)
> > Time per request:       13.04 [ms] (mean, across all concurrent
> > requests)
> > Transfer rate:          31.98 [Kbytes/sec] received
> >
> > Connnection Times (ms)
> >               min  mean[+/-sd] median   max
> > Connect:      175   234  292.9    187  3099
> > Processing:   204   897  806.4    611  5619
> > Waiting:      187   897  806.5    611  5619
> > Total:        365  1132  840.6    842  5804
> > _______________________________________________
> > 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
>


-- 
Cheers,

Kevin Williams
http://www.almostserio.us/

"Any sufficiently advanced technology is indistinguishable from
Magic." - Arthur C. Clarke

From snacktime at gmail.com  Tue Apr  3 18:00:00 2007
From: snacktime at gmail.com (snacktime)
Date: Tue, 3 Apr 2007 15:00:00 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
Message-ID: <1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>

Makes sense that mongrel_cluster would handle a lot of edge cases
better then monit.  Is it mainly the pid file handling that has been
the main issue so far?

Have you tried daemontools?  Seems to me like it would be more
reliable since you wouldn't have to deal with pid files and
backgrounding mongrel.

Chris

On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
>
> > Is there anything mongrel cluster gives you that monit doesn't?  I'll
> > be using monit to monitor a number of other services anyways, so it
> > seems logical to just use it for everything including mongrel.
> >
> > Chris
> >
>
> Chris-
>
>         WHen you use monit you can still use mongrel_cluster to manage it.
> You need the latest pre release of mongrel_cluster. This is the best
> configuration I've been able to come up with for 64Bit systems. If
> your on 32bit system then you can lower the memory limits by about
> 20-30%
>
> check process mongrel_<%= @username %>_5000
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_<%= @username %>_5001
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_<%= @username %>_5002
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
>
>         I wen't for a while using my own scripts to start and stop mongrel
> without using mongrel_cluster. But it works more reliably when I use
> mongrel_cluster and monit together.
>
> Cheers-
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From bhjackson at gmail.com  Tue Apr  3 18:02:46 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Tue, 3 Apr 2007 19:02:46 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <6D595D32-7B83-49D7-9BCC-84F4E8C48E45@joyent.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<6D595D32-7B83-49D7-9BCC-84F4E8C48E45@joyent.com>
Message-ID: <cb03bffe0704031502l2459742raa4e569c2df03698@mail.gmail.com>

> Looking even at your standard deviations, I don't see much of a
> difference between these. What's your SD on the req/sec?

Thanks for the heads-up Jason.

ab doesn't have a SD on the req/sec AFAIK, tried doing (I think)
equivalent benchmarks with httperf, this time from the server, and I
got the following results. It seems like FastCGI is marginally faster
than Mongrel for my site when both are run with 2 dispatchers.

Does this sound like an accurate test, or did I miss something
essential in the benchmarking process? Thanks,

Ben

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

FastCGI (1 proc):

$ httperf --server=eship.com.br --rate=100 --num-conns=1000
httperf --client=0/1 --server=eship.com.br --port=80 --uri=/
--rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000
--num-calls=1
Maximum connect burst length: 7

Total: connections 1000 requests 1000 replies 1000 test-duration 16.141 s

Connection rate: 62.0 conn/s (16.1 ms/conn, <=257 concurrent connections)
Connection time [ms]: min 10.2 avg 1741.3 max 9040.8 median 1614.5 stddev 1737.0
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 62.0 req/s (16.1 ms/req)
Request size [B]: 63.0

Reply rate [replies/s]: min 48.2 avg 65.7 max 75.0 stddev 15.1 (3 samples)
Reply time [ms]: response 1741.3 transfer 0.0
Reply size [B]: header 304.0 content 95.0 footer 2.0 (total 401.0)
Reply status: 1xx=0 2xx=0 3xx=1000 4xx=0 5xx=0

CPU time [s]: user 1.31 system 13.72 (user 8.1% system 85.0% total 93.1%)
Net I/O: 28.0 KB/s (0.2*10^6 bps)

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

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

FastCGI (2 procs):

$ httperf --server=eship.com.br --rate=100 --num-conns=1000
httperf --client=0/1 --server=eship.com.br --port=80 --uri=/
--rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000
--num-calls=1
Maximum connect burst length: 8

Total: connections 1000 requests 1000 replies 1000 test-duration 11.993 s

Connection rate: 83.4 conn/s (12.0 ms/conn, <=169 concurrent connections)
Connection time [ms]: min 10.7 avg 837.5 max 2047.6 median 831.5 stddev 662.5
Connection time [ms]: connect 0.3
Connection length [replies/conn]: 1.000

Request rate: 83.4 req/s (12.0 ms/req)
Request size [B]: 63.0

Reply rate [replies/s]: min 82.4 avg 83.8 max 85.2 stddev 2.0 (2 samples)
Reply time [ms]: response 837.2 transfer 0.0
Reply size [B]: header 304.0 content 95.0 footer 2.0 (total 401.0)
Reply status: 1xx=0 2xx=0 3xx=1000 4xx=0 5xx=0

CPU time [s]: user 1.23 system 8.75 (user 10.3% system 73.0% total 83.2%)
Net I/O: 37.6 KB/s (0.3*10^6 bps)

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

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

Mongrel:


$ httperf --server=eship.com.br --rate=100 --num-conns=1000
httperf --client=0/1 --server=eship.com.br --port=80 --uri=/
--rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000
--num-calls=1
Maximum connect burst length: 4

Total: connections 1000 requests 1000 replies 1000 test-duration 13.000 s

Connection rate: 76.9 conn/s (13.0 ms/conn, <=212 concurrent connections)
Connection time [ms]: min 19.5 avg 1117.1 max 4115.2 median 1036.5 stddev 936.0
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 76.9 req/s (13.0 ms/req)
Request size [B]: 63.0

Reply rate [replies/s]: min 74.4 avg 78.9 max 83.4 stddev 6.4 (2 samples)
Reply time [ms]: response 1117.1 transfer 0.0
Reply size [B]: header 304.0 content 95.0 footer 2.0 (total 401.0)
Reply status: 1xx=0 2xx=0 3xx=1000 4xx=0 5xx=0

CPU time [s]: user 1.02 system 11.22 (user 7.8% system 86.3% total 94.2%)
Net I/O: 34.7 KB/s (0.3*10^6 bps)

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

From nclark at mosso.com  Tue Apr  3 17:52:59 2007
From: nclark at mosso.com (Nathan Clark)
Date: Tue, 3 Apr 2007 16:52:59 -0500
Subject: [Mongrel] are memory limits on mongrel possible?
Message-ID: <2C8EF109-B46F-4E30-A347-D437230EC3C0@mosso.com>

Is there any documentation I can look at that might talk about how to  
put
memory limits on mongrel? For instants, I might want to limit mongrel to
100 megs of ram.  I know that I can monitor mongrel with monit and  
restart it
automatically if it becomes a ram piggy. 

From ezmobius at gmail.com  Tue Apr  3 18:28:06 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 3 Apr 2007 15:28:06 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
Message-ID: <28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>


	Yes mongrel_cluster handles the pid files. Also it does a better job  
of stopping mongrels. The problem I had when I used monit and  
mongrel_rails without mongrel_cluster was that if a mongrel used too  
much memory monit woudl not be able to stop it sometimes and so  
execution woudl fail and timeout.

	Using mongrel_clutser avoids this problem completely. Trust me I've  
tried it all different ways. I did monit without mongrel_cluster for  
a about a full month on close to 200 servers and then switched them  
all to monit and mongrel_cluster and get much better results.

-Ezra

On Apr 3, 2007, at 3:00 PM, snacktime wrote:

> Makes sense that mongrel_cluster would handle a lot of edge cases
> better then monit.  Is it mainly the pid file handling that has been
> the main issue so far?
>
> Have you tried daemontools?  Seems to me like it would be more
> reliable since you wouldn't have to deal with pid files and
> backgrounding mongrel.
>
> Chris
>
> On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>>
>> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
>>
>>> Is there anything mongrel cluster gives you that monit doesn't?   
>>> I'll
>>> be using monit to monitor a number of other services anyways, so it
>>> seems logical to just use it for everything including mongrel.
>>>
>>> Chris
>>>
>>
>> Chris-
>>
>>         WHen you use monit you can still use mongrel_cluster to  
>> manage it.
>> You need the latest pre release of mongrel_cluster. This is the best
>> configuration I've been able to come up with for 64Bit systems. If
>> your on 32bit system then you can lower the memory limits by about
>> 20-30%
>>
>> check process mongrel_<%= @username %>_5000
>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
>>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
>> = @username %>/current/config/mongrel_cluster.yml --clean --only  
>> 5000"
>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
>> @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>>    if totalmem is greater than 110.0 MB for 4 cycles then
>> restart       # eating up memory?
>>    if cpu is greater than 50% for 2 cycles then
>> alert                  # send an email to admin
>>    if cpu is greater than 80% for 3 cycles then
>> restart                # hung process?
>>    if loadavg(5min) greater than 10 for 8 cycles then
>> restart          # bad, bad, bad
>>    if 20 restarts within 20 cycles then
>> timeout                         # something is wrong, call the sys- 
>> admin
>>    group mongrel
>>
>> check process mongrel_<%= @username %>_5001
>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
>>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
>> = @username %>/current/config/mongrel_cluster.yml --clean --only  
>> 5001"
>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
>> @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>>    if totalmem is greater than 110.0 MB for 4 cycles then
>> restart       # eating up memory?
>>    if cpu is greater than 50% for 2 cycles then
>> alert                  # send an email to admin
>>    if cpu is greater than 80% for 3 cycles then
>> restart                # hung process?
>>    if loadavg(5min) greater than 10 for 8 cycles then
>> restart          # bad, bad, bad
>>    if 20 restarts within 20 cycles then
>> timeout                         # something is wrong, call the sys- 
>> admin
>>    group mongrel
>>
>> check process mongrel_<%= @username %>_5002
>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
>>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
>> = @username %>/current/config/mongrel_cluster.yml --clean --only  
>> 5002"
>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
>> @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>>    if totalmem is greater than 110.0 MB for 4 cycles then
>> restart       # eating up memory?
>>    if cpu is greater than 50% for 2 cycles then
>> alert                  # send an email to admin
>>    if cpu is greater than 80% for 3 cycles then
>> restart                # hung process?
>>    if loadavg(5min) greater than 10 for 8 cycles then
>> restart          # bad, bad, bad
>>    if 20 restarts within 20 cycles then
>> timeout                         # something is wrong, call the sys- 
>> admin
>>    group mongrel
>>
>>
>>         I wen't for a while using my own scripts to start and stop  
>> mongrel
>> without using mongrel_cluster. But it works more reliably when I use
>> mongrel_cluster and monit together.
>>
>> Cheers-
>> -- Ezra Zygmuntowicz
>> -- Lead Rails Evangelist
>> -- ez at engineyard.com
>> -- Engine Yard, Serious Rails Hosting
>> -- (866) 518-YARD (9273)
>>
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

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



From zackchandler at gmail.com  Tue Apr  3 19:19:39 2007
From: zackchandler at gmail.com (Zack Chandler)
Date: Tue, 3 Apr 2007 16:19:39 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
Message-ID: <33841ac70704031619y7d90c6c1n448e887151da246a@mail.gmail.com>

Ezra,

The --clean option is only available in 1.0.1.1 beta I believe?  Are
you finding it stable enough for production environments (EY)?

I've been bitten by orphaned pids many times - I'm looking forward to
putting this into production...

--
Zack Chandler
http://depixelate.com

On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
>         Yes mongrel_cluster handles the pid files. Also it does a better job
> of stopping mongrels. The problem I had when I used monit and
> mongrel_rails without mongrel_cluster was that if a mongrel used too
> much memory monit woudl not be able to stop it sometimes and so
> execution woudl fail and timeout.
>
>         Using mongrel_clutser avoids this problem completely. Trust me I've
> tried it all different ways. I did monit without mongrel_cluster for
> a about a full month on close to 200 servers and then switched them
> all to monit and mongrel_cluster and get much better results.
>
> -Ezra
>
> On Apr 3, 2007, at 3:00 PM, snacktime wrote:
>
> > Makes sense that mongrel_cluster would handle a lot of edge cases
> > better then monit.  Is it mainly the pid file handling that has been
> > the main issue so far?
> >
> > Have you tried daemontools?  Seems to me like it would be more
> > reliable since you wouldn't have to deal with pid files and
> > backgrounding mongrel.
> >
> > Chris
> >
> > On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> >>
> >> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
> >>
> >>> Is there anything mongrel cluster gives you that monit doesn't?
> >>> I'll
> >>> be using monit to monitor a number of other services anyways, so it
> >>> seems logical to just use it for everything including mongrel.
> >>>
> >>> Chris
> >>>
> >>
> >> Chris-
> >>
> >>         WHen you use monit you can still use mongrel_cluster to
> >> manage it.
> >> You need the latest pre release of mongrel_cluster. This is the best
> >> configuration I've been able to come up with for 64Bit systems. If
> >> your on 32bit system then you can lower the memory limits by about
> >> 20-30%
> >>
> >> check process mongrel_<%= @username %>_5000
> >>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
> >>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> >> = @username %>/current/config/mongrel_cluster.yml --clean --only
> >> 5000"
> >>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> >> @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
> >>    if totalmem is greater than 110.0 MB for 4 cycles then
> >> restart       # eating up memory?
> >>    if cpu is greater than 50% for 2 cycles then
> >> alert                  # send an email to admin
> >>    if cpu is greater than 80% for 3 cycles then
> >> restart                # hung process?
> >>    if loadavg(5min) greater than 10 for 8 cycles then
> >> restart          # bad, bad, bad
> >>    if 20 restarts within 20 cycles then
> >> timeout                         # something is wrong, call the sys-
> >> admin
> >>    group mongrel
> >>
> >> check process mongrel_<%= @username %>_5001
> >>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
> >>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> >> = @username %>/current/config/mongrel_cluster.yml --clean --only
> >> 5001"
> >>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> >> @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
> >>    if totalmem is greater than 110.0 MB for 4 cycles then
> >> restart       # eating up memory?
> >>    if cpu is greater than 50% for 2 cycles then
> >> alert                  # send an email to admin
> >>    if cpu is greater than 80% for 3 cycles then
> >> restart                # hung process?
> >>    if loadavg(5min) greater than 10 for 8 cycles then
> >> restart          # bad, bad, bad
> >>    if 20 restarts within 20 cycles then
> >> timeout                         # something is wrong, call the sys-
> >> admin
> >>    group mongrel
> >>
> >> check process mongrel_<%= @username %>_5002
> >>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
> >>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> >> = @username %>/current/config/mongrel_cluster.yml --clean --only
> >> 5002"
> >>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> >> @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
> >>    if totalmem is greater than 110.0 MB for 4 cycles then
> >> restart       # eating up memory?
> >>    if cpu is greater than 50% for 2 cycles then
> >> alert                  # send an email to admin
> >>    if cpu is greater than 80% for 3 cycles then
> >> restart                # hung process?
> >>    if loadavg(5min) greater than 10 for 8 cycles then
> >> restart          # bad, bad, bad
> >>    if 20 restarts within 20 cycles then
> >> timeout                         # something is wrong, call the sys-
> >> admin
> >>    group mongrel
> >>
> >>
> >>         I wen't for a while using my own scripts to start and stop
> >> mongrel
> >> without using mongrel_cluster. But it works more reliably when I use
> >> mongrel_cluster and monit together.
> >>
> >> Cheers-
> >> -- Ezra Zygmuntowicz
> >> -- Lead Rails Evangelist
> >> -- ez at engineyard.com
> >> -- Engine Yard, Serious Rails Hosting
> >> -- (866) 518-YARD (9273)
> >>
> >>
> >> _______________________________________________
> >> Mongrel-users mailing list
> >> Mongrel-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/mongrel-users
> >>
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From alexey.verkhovsky at gmail.com  Tue Apr  3 19:32:39 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 3 Apr 2007 17:32:39 -0600
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
Message-ID: <3945c4270704031632v737dba34veafb9ca4a17fbfa2@mail.gmail.com>

On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> mongrel_cluster handles the pid files. Also it does a better job
> of stopping mongrels.

Is there some fundamental reason why Mongrel itself cannot handle
these issues well, or does it just need more work in this area?

Alex

From ezmobius at gmail.com  Tue Apr  3 19:44:53 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 3 Apr 2007 16:44:53 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <33841ac70704031619y7d90c6c1n448e887151da246a@mail.gmail.com>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
	<33841ac70704031619y7d90c6c1n448e887151da246a@mail.gmail.com>
Message-ID: <8DFCE75B-2BCC-4963-BFF0-6ED51403A720@brainspl.at>


On Apr 3, 2007, at 4:19 PM, Zack Chandler wrote:

> Ezra,
>
> The --clean option is only available in 1.0.1.1 beta I believe?  Are
> you finding it stable enough for production environments (EY)?
>
> I've been bitten by orphaned pids many times - I'm looking forward to
> putting this into production...
>

Zack-

	Yes the prerelease is production worthy on linux, it still may have  
an issue on FreeBSD. If you are on linux then I highly recommend the  
upgrade. It is running fine on hundreds of servers no and works much  
better then any other way I've had this stuff setup.


On Apr 3, 2007, at 4:32 PM, Alexey Verkhovsky wrote:
> On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>> mongrel_cluster handles the pid files. Also it does a better job
>> of stopping mongrels.
>
> Is there some fundamental reason why Mongrel itself cannot handle
> these issues well, or does it just need more work in this area?
>
> Alex

	The reason it's not in mongrel is because bradley made the  
mongrel_cluster gem and so Zed saw no reason to add the same stuff in  
mongrel.

	I have asked for a --clean option for the mongel_rails command that  
would cleanup PID"s but I haven't had time to make a patch,  
especially since mongrel_cluster does a great job managing this stuff.


Cheers-

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



From skilic at gmail.com  Tue Apr  3 21:48:56 2007
From: skilic at gmail.com (=?ISO-8859-9?Q?Serdar_K=FDl=FD=E7?=)
Date: Wed, 4 Apr 2007 11:48:56 +1000
Subject: [Mongrel] MediaTemple Image upload
In-Reply-To: <20070403111401.646f977e.zedshaw@zedshaw.com>
References: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
	<20070403111401.646f977e.zedshaw@zedshaw.com>
Message-ID: <9bff27860704031848r487ecbe2x66b51a99929dd15@mail.gmail.com>

Thanks Guys for the thoughts and ideas - I'll have a look at merb as Craig
suggested as I'm currently running the default setup of 64mb for rails (only
1 app running) and if a single file upload is causing me to run out of
memory then that is troublesome. FWIW, I replaced my own file upload code
with that of recipe 57 if you have the Rails Recipe book, but the issue is
there as well, so it possibly could be a rails related issue.


On 04/04/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
>
> Mongrel isn't crashing, most likely you have too little RAM and the
> linux oomkiller is killing Mongrel off when it gets too big.  Take your
> app, put it on a computer with lots of ram, and then try a bunch of
> giant uploads to make sure.  Then, if it still works simply go buy more
> RAM from MT.
>
> --
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
>
> --
> Cheers,
> Serdar K?l??
> http://weblog.kilic.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070404/902c89d0/attachment-0001.html 

From wayneeseguin at gmail.com  Tue Apr  3 21:52:36 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 3 Apr 2007 21:52:36 -0400
Subject: [Mongrel] are memory limits on mongrel possible?
In-Reply-To: <2C8EF109-B46F-4E30-A347-D437230EC3C0@mosso.com>
References: <2C8EF109-B46F-4E30-A347-D437230EC3C0@mosso.com>
Message-ID: <6EC4D520-18CC-4BE8-9D96-0D56F46291BC@gmail.com>

Nathan,

Monit is what you are looking for.

http://www.tildeslash.com/monit/

On Apr 03, 2007, at 17:52 , Nathan Clark wrote:

> Is there any documentation I can look at that might talk about how to
> put
> memory limits on mongrel? For instants, I might want to limit  
> mongrel to
> 100 megs of ram.  I know that I can monitor mongrel with monit and
> restart it
> automatically if it becomes a ram piggy.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From pete at nextengine.com  Wed Apr  4 08:43:54 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 05:43:54 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
Message-ID: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>

Hi guys,

I've been running mongrel for a while now with Ruby 1.8.4, and last  
week upgraded to 1.8.6.

Since upgrading, each morning when I wake up there's a big problem:

1. Accessing the site returns a "500 Internal Server Error"
2. All the mongrel_rails processes are still running, but none of  
them are active (when I run top)
3. Lighttpd and pound are still running nicely
4. There's plenty of free RAM
5. There's plenty of free HD
6. When I restart mongrel, it all starts working again

I haven't seen anything like this before.  Does this sound familiar  
to anyone?

Thanks for the help,
Pete

From eden at mojiti.com  Wed Apr  4 09:01:48 2007
From: eden at mojiti.com (Eden Li)
Date: Wed, 4 Apr 2007 18:31:48 +0530
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
Message-ID: <1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>

Standard questions come to mind:
 - What do your logs say?
 - Are you running anything semi-dangerous like rmagick or older
versions of acts_as_ferret?
 - Are you using Ruby based log rotation?

BTW, maybe we could put up solutions to common issues into a page on
mongrel.rubyforge.org? I don't see one on
http://mongrel.rubyforge.org/docs/index.html...

On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Hi guys,
>
> I've been running mongrel for a while now with Ruby 1.8.4, and last
> week upgraded to 1.8.6.
>
> Since upgrading, each morning when I wake up there's a big problem:
>
> 1. Accessing the site returns a "500 Internal Server Error"
> 2. All the mongrel_rails processes are still running, but none of
> them are active (when I run top)
> 3. Lighttpd and pound are still running nicely
> 4. There's plenty of free RAM
> 5. There's plenty of free HD
> 6. When I restart mongrel, it all starts working again
>
> I haven't seen anything like this before.  Does this sound familiar
> to anyone?
>
> Thanks for the help,
> Pete
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From pete at nextengine.com  Wed Apr  4 09:15:06 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 06:15:06 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
Message-ID: <0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>

Hi Eden,

I agree: a common issues page is a great idea.  Unfortunately, this  
issue doesn't seem to be one of the usual suspects.

1. The logs just have normal chatter for my app ... nothing unusual
2. No rmagick or ferret, but I believe it is related to Ruby 1.8.6,  
since that's when ti started dying.
3. I'm not using log rotation, but the files aren't that big after a  
day.. and there's plenty of free space on disk

Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?

Thanks,
Pete



On Apr 4, 2007, at 6:01 AM, Eden Li wrote:

> Standard questions come to mind:
>  - What do your logs say?
>  - Are you running anything semi-dangerous like rmagick or older
> versions of acts_as_ferret?
>  - Are you using Ruby based log rotation?
>
> BTW, maybe we could put up solutions to common issues into a page on
> mongrel.rubyforge.org? I don't see one on
> http://mongrel.rubyforge.org/docs/index.html...
>
> On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>> Hi guys,
>>
>> I've been running mongrel for a while now with Ruby 1.8.4, and last
>> week upgraded to 1.8.6.
>>
>> Since upgrading, each morning when I wake up there's a big problem:
>>
>> 1. Accessing the site returns a "500 Internal Server Error"
>> 2. All the mongrel_rails processes are still running, but none of
>> them are active (when I run top)
>> 3. Lighttpd and pound are still running nicely
>> 4. There's plenty of free RAM
>> 5. There's plenty of free HD
>> 6. When I restart mongrel, it all starts working again
>>
>> I haven't seen anything like this before.  Does this sound familiar
>> to anyone?
>>
>> Thanks for the help,
>> Pete
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From jackc at hylesanderson.edu  Wed Apr  4 09:50:03 2007
From: jackc at hylesanderson.edu (Jack Christensen)
Date: Wed, 04 Apr 2007 08:50:03 -0500
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>	<1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
	<0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
Message-ID: <4613AD0B.7090308@hylesanderson.edu>

Pete DeLaurentis wrote:
>
> Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?
>   
Yes. In fact, my problems with mongrels dying went away when I went to 
ruby 1.8.6. Of course, I changed a number of other things at the same 
time so I can't say conclusively that the ruby upgrade was the solution. 
But I haven't had any mongrels die since I deployed my new setup last 5 
days ago, and prior to that I was having a mongrel die (as in crash not 
just stop responding) every few hours or so.

-- 
Jack Christensen
jackc at hylesanderson.edu


From eden at mojiti.com  Wed Apr  4 10:11:23 2007
From: eden at mojiti.com (Eden Li)
Date: Wed, 4 Apr 2007 19:41:23 +0530
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
	<0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
Message-ID: <1dd361e10704040711o3a22d282iac0064b51cdc6f85@mail.gmail.com>

Which version of rails are you using?  Version prior to 1.2.3 have a
few issues...  Also, what version of mongrel are you running?

On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Hi Eden,
>
> I agree: a common issues page is a great idea.  Unfortunately, this
> issue doesn't seem to be one of the usual suspects.
>
> 1. The logs just have normal chatter for my app ... nothing unusual
> 2. No rmagick or ferret, but I believe it is related to Ruby 1.8.6,
> since that's when ti started dying.
> 3. I'm not using log rotation, but the files aren't that big after a
> day.. and there's plenty of free space on disk
>
> Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?
>
> Thanks,
> Pete
>
>
>
> On Apr 4, 2007, at 6:01 AM, Eden Li wrote:
>
> > Standard questions come to mind:
> >  - What do your logs say?
> >  - Are you running anything semi-dangerous like rmagick or older
> > versions of acts_as_ferret?
> >  - Are you using Ruby based log rotation?
> >
> > BTW, maybe we could put up solutions to common issues into a page on
> > mongrel.rubyforge.org? I don't see one on
> > http://mongrel.rubyforge.org/docs/index.html...
> >
> > On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> >> Hi guys,
> >>
> >> I've been running mongrel for a while now with Ruby 1.8.4, and last
> >> week upgraded to 1.8.6.
> >>
> >> Since upgrading, each morning when I wake up there's a big problem:
> >>
> >> 1. Accessing the site returns a "500 Internal Server Error"
> >> 2. All the mongrel_rails processes are still running, but none of
> >> them are active (when I run top)
> >> 3. Lighttpd and pound are still running nicely
> >> 4. There's plenty of free RAM
> >> 5. There's plenty of free HD
> >> 6. When I restart mongrel, it all starts working again
> >>
> >> I haven't seen anything like this before.  Does this sound familiar
> >> to anyone?
> >>
> >> Thanks for the help,
> >> Pete
> >> _______________________________________________
> >> Mongrel-users mailing list
> >> Mongrel-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/mongrel-users
> >>
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From pete at nextengine.com  Wed Apr  4 10:27:27 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 07:27:27 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <1dd361e10704040711o3a22d282iac0064b51cdc6f85@mail.gmail.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
	<0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
	<1dd361e10704040711o3a22d282iac0064b51cdc6f85@mail.gmail.com>
Message-ID: <2875AC20-A690-4ED0-BFFC-C304E4A4F72B@nextengine.com>

Hi Eden,

I'm running mongrel1.0.1, mongrel cluster 0.2.1, rails 1.2.3, and  
fastthread 1.0.

I just cleaned up all old gems (since I had some back versions) and  
re-updated all of these gems just to be sure.  Tomorrow morning, I'll  
get to see if this helped :-)

-Pete

On Apr 4, 2007, at 7:11 AM, Eden Li wrote:

> Which version of rails are you using?  Version prior to 1.2.3 have a
> few issues...  Also, what version of mongrel are you running?
>
> On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>> Hi Eden,
>>
>> I agree: a common issues page is a great idea.  Unfortunately, this
>> issue doesn't seem to be one of the usual suspects.
>>
>> 1. The logs just have normal chatter for my app ... nothing unusual
>> 2. No rmagick or ferret, but I believe it is related to Ruby 1.8.6,
>> since that's when ti started dying.
>> 3. I'm not using log rotation, but the files aren't that big after a
>> day.. and there's plenty of free space on disk
>>
>> Here's a question: Is anyone running ruby1.8.6 succesfully with  
>> mongrel?
>>
>> Thanks,
>> Pete
>>
>>
>>
>> On Apr 4, 2007, at 6:01 AM, Eden Li wrote:
>>
>>> Standard questions come to mind:
>>>  - What do your logs say?
>>>  - Are you running anything semi-dangerous like rmagick or older
>>> versions of acts_as_ferret?
>>>  - Are you using Ruby based log rotation?
>>>
>>> BTW, maybe we could put up solutions to common issues into a page on
>>> mongrel.rubyforge.org? I don't see one on
>>> http://mongrel.rubyforge.org/docs/index.html...
>>>
>>> On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>>>> Hi guys,
>>>>
>>>> I've been running mongrel for a while now with Ruby 1.8.4, and last
>>>> week upgraded to 1.8.6.
>>>>
>>>> Since upgrading, each morning when I wake up there's a big problem:
>>>>
>>>> 1. Accessing the site returns a "500 Internal Server Error"
>>>> 2. All the mongrel_rails processes are still running, but none of
>>>> them are active (when I run top)
>>>> 3. Lighttpd and pound are still running nicely
>>>> 4. There's plenty of free RAM
>>>> 5. There's plenty of free HD
>>>> 6. When I restart mongrel, it all starts working again
>>>>
>>>> I haven't seen anything like this before.  Does this sound familiar
>>>> to anyone?
>>>>
>>>> Thanks for the help,
>>>> Pete
>>>> _______________________________________________
>>>> Mongrel-users mailing list
>>>> Mongrel-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From zedshaw at zedshaw.com  Wed Apr  4 10:37:37 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 4 Apr 2007 10:37:37 -0400
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
Message-ID: <20070404103737.81c8e0a9.zedshaw@zedshaw.com>

On Wed, 4 Apr 2007 05:43:54 -0700
Pete DeLaurentis <pete at nextengine.com> wrote:

> Hi guys,
> 
> I've been running mongrel for a while now with Ruby 1.8.4, and last  
> week upgraded to 1.8.6.

First, NEVER upgrade a production server to new versions before you
test the living hell out of it.  This always leads to disaster.

Second, I haven't tested Mongrel on 1.8.6 and there's apparently a
small bug in the new thread implementation that's included.  You'll
want to try out fastthread very latest even if you're running 1.8.6.

Third, whenever you do an upgrade you have to recompile ALL of your
gems.  Every last one.  No matter what.  Best way to do this is
uninstall all of your gems then reinstall the ones you need.  It's good
spring cleaning, but it also makes sure that the compiled extensions
work with the new ruby interpreter.

Lastly, I only deploy 1.8.5 with fastthread, not 1.8.6.  I'm sure
there's bugs lurking in 1.8.6 that haven't been tested out on both
Rails and Mongrel.

Let me know what you find.

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

From mzukowski at urbacon.net  Wed Apr  4 10:54:41 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Wed, 04 Apr 2007 10:54:41 -0400
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
Message-ID: <4613BC31.5060803@urbacon.net>

Are you sure this isn't being caused by something unrelated to mongrel
or ruby 1.8.6? We were having a similar problem a while ago and traced
it down mysql closing its connection after 8 hours of inactivity
(ActiveRecord, somewhat stupidly, does not attempt to reconnect the
closed connection).

Pete DeLaurentis wrote:
> Hi guys,
> 
> I've been running mongrel for a while now with Ruby 1.8.4, and last  
> week upgraded to 1.8.6.
> 
> Since upgrading, each morning when I wake up there's a big problem:
> 
> 1. Accessing the site returns a "500 Internal Server Error"
> 2. All the mongrel_rails processes are still running, but none of  
> them are active (when I run top)
> 3. Lighttpd and pound are still running nicely
> 4. There's plenty of free RAM
> 5. There's plenty of free HD
> 6. When I restart mongrel, it all starts working again
> 
> I haven't seen anything like this before.  Does this sound familiar  
> to anyone?
> 
> Thanks for the help,
> Pete
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users



This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.



From pete at nextengine.com  Wed Apr  4 11:27:56 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 08:27:56 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <20070404103737.81c8e0a9.zedshaw@zedshaw.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<20070404103737.81c8e0a9.zedshaw@zedshaw.com>
Message-ID: <4B2F7C8A-C16D-4447-982F-BD0FB0892B56@nextengine.com>

Thanks for the tips Zed, I will uninstall + reinstall all of the  
gems.  There is also a new version of fastthread, which I just  
installed.  In the words of the author:

"Well, just when I thought I was done with fastthread, it turns out  
that the version of fastthread merged into Ruby 1.8.6?s thread  
library had a couple serious bugs. So, here?s a new version of  
fastthread which can serve as a hotfix until the next Ruby release."
- MenTaLguY, http://moonbase.rydia.net/

We made the switch to 1.8.6 for the reputed 10% speed boost.  We're  
using it on our in-house server that runs our beta app, and we're not  
upgrading the customer servers until this is stable.

Thanks for the help,
Pete




On Apr 4, 2007, at 7:37 AM, Zed A. Shaw wrote:

> On Wed, 4 Apr 2007 05:43:54 -0700
> Pete DeLaurentis <pete at nextengine.com> wrote:
>
>> Hi guys,
>>
>> I've been running mongrel for a while now with Ruby 1.8.4, and last
>> week upgraded to 1.8.6.
>
> First, NEVER upgrade a production server to new versions before you
> test the living hell out of it.  This always leads to disaster.
>
> Second, I haven't tested Mongrel on 1.8.6 and there's apparently a
> small bug in the new thread implementation that's included.  You'll
> want to try out fastthread very latest even if you're running 1.8.6.
>
> Third, whenever you do an upgrade you have to recompile ALL of your
> gems.  Every last one.  No matter what.  Best way to do this is
> uninstall all of your gems then reinstall the ones you need.  It's  
> good
> spring cleaning, but it also makes sure that the compiled extensions
> work with the new ruby interpreter.
>
> Lastly, I only deploy 1.8.5 with fastthread, not 1.8.6.  I'm sure
> there's bugs lurking in 1.8.6 that haven't been tested out on both
> Rails and Mongrel.
>
> Let me know what you find.
>
> -- 
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> http://mongrel.rubyforge.org/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070404/6105b407/attachment-0001.html 

From kaushik.ghose at gmail.com  Wed Apr  4 11:44:58 2007
From: kaushik.ghose at gmail.com (kaushik.ghose)
Date: Wed, 04 Apr 2007 11:44:58 -0400
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <mailman.48.1175700493.19662.mongrel-users@rubyforge.org>
References: <mailman.48.1175700493.19662.mongrel-users@rubyforge.org>
Message-ID: <4613C7FA.1050106@gmail.com>

Pete DeLaurentis wrote:

> Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?
On Windows Vista I'm running Mongrel with Ruby 1.8.6, rails 1.2.3 as a 
service. I have no problems with the service shutting down or becoming 
unresponsive. I run this on a laptop, (with hibernation) uptime upto 50 
hrs hasn't been a problem.

The "500 Internal Server Error" rings a bell, but I can't remember what 
was causing it and the issue has been resolved for me.

-Kaushik



From rsanheim at gmail.com  Wed Apr  4 11:56:56 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 4 Apr 2007 10:56:56 -0500
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <20070404103737.81c8e0a9.zedshaw@zedshaw.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<20070404103737.81c8e0a9.zedshaw@zedshaw.com>
Message-ID: <fc113d400704040856k1c6d1f07l623ef2b8d0e561b7@mail.gmail.com>

On 4/4/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> Third, whenever you do an upgrade you have to recompile ALL of your
> gems.  Every last one.  No matter what.  Best way to do this is
> uninstall all of your gems then reinstall the ones you need.  It's good
> spring cleaning, but it also makes sure that the compiled extensions
> work with the new ruby interpreter.

You are referring here to *only* when you do an upgrade of the ruby
intrepreter, right?

- Rob

From pete at nextengine.com  Wed Apr  4 12:29:35 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 09:29:35 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <4613BC31.5060803@urbacon.net>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<4613BC31.5060803@urbacon.net>
Message-ID: <F843192F-E26A-4F68-BB25-0F529FDC8FE8@nextengine.com>

Yeah, I've been bitten by this one before too... in one of the  
background processes I run.  Now that background process bites  
ActiveRecord every hour to keep it alive.

I've never had any trouble with activerecord losing it's connection  
in the mongrel processes, but it sounds like it's possible.  Maybe I  
should have that background process contact each of the mongrels.  Or  
better yet, maybe I should look into how hard it would be to get  
ActiveRecord to restore the connection.

Thanks,
Pete


On Apr 4, 2007, at 7:54 AM, Matt Zukowski wrote:

> Are you sure this isn't being caused by something unrelated to mongrel
> or ruby 1.8.6? We were having a similar problem a while ago and traced
> it down mysql closing its connection after 8 hours of inactivity
> (ActiveRecord, somewhat stupidly, does not attempt to reconnect the
> closed connection).
>
> Pete DeLaurentis wrote:
>> Hi guys,
>>
>> I've been running mongrel for a while now with Ruby 1.8.4, and last
>> week upgraded to 1.8.6.
>>
>> Since upgrading, each morning when I wake up there's a big problem:
>>
>> 1. Accessing the site returns a "500 Internal Server Error"
>> 2. All the mongrel_rails processes are still running, but none of
>> them are active (when I run top)
>> 3. Lighttpd and pound are still running nicely
>> 4. There's plenty of free RAM
>> 5. There's plenty of free HD
>> 6. When I restart mongrel, it all starts working again
>>
>> I haven't seen anything like this before.  Does this sound familiar
>> to anyone?
>>
>> Thanks for the help,
>> Pete
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>
> This e-mail message is privileged, confidential and subject to  
> copyright. Any unauthorized use or disclosure is prohibited.
> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et  
> soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de  
> le divulguer sans autorisation.
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From luislavena at gmail.com  Wed Apr  4 12:38:08 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 4 Apr 2007 13:38:08 -0300
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <4613C7FA.1050106@gmail.com>
References: <mailman.48.1175700493.19662.mongrel-users@rubyforge.org>
	<4613C7FA.1050106@gmail.com>
Message-ID: <71166b3b0704040938s589d3d5ar3cb40431a471050b@mail.gmail.com>

On 4/4/07, kaushik.ghose <kaushik.ghose at gmail.com> wrote:
> Pete DeLaurentis wrote:
>
> > Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?
> On Windows Vista I'm running Mongrel with Ruby 1.8.6, rails 1.2.3 as a
> service. I have no problems with the service shutting down or becoming
> unresponsive. I run this on a laptop, (with hibernation) uptime upto 50
> hrs hasn't been a problem.
>

Hehehe, is good to know that you are up and running Kaus ;-)

> The "500 Internal Server Error" rings a bell, but I can't remember what
> was causing it and the issue has been resolved for me.
>

Maybe MySql timeout? from mongrel faq [1]

Q. Mongrel stops working if it's left alone for a long time.

If you find that Mongrel stops working after a long idle time and
you're using MySQL then you're hitting a bug in the MySQL driver that
doesn't properly timeout connections. What happens is the MySQL server
side of the connection times out and closes, but the MySQL client
doesn't detect this and just sits there.

What you have to do is set:

ActiveRecord::Base.verification_timeout = 14400

Or to any value that is lower than the MySQL server's
interactive_timeout setting. This will make sure that ActiveRecord
checks the connection often enough to reset the connection.


[1] http://mongrel.rubyforge.org/faq.html

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

From alexey.verkhovsky at gmail.com  Wed Apr  4 13:03:14 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 4 Apr 2007 11:03:14 -0600
Subject: [Mongrel] are memory limits on mongrel possible?
In-Reply-To: <6EC4D520-18CC-4BE8-9D96-0D56F46291BC@gmail.com>
References: <2C8EF109-B46F-4E30-A347-D437230EC3C0@mosso.com>
	<6EC4D520-18CC-4BE8-9D96-0D56F46291BC@gmail.com>
Message-ID: <3945c4270704041003o694848a8m4c7fa222f17d2834@mail.gmail.com>

On 4/3/07, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:
> >  memory limits on mongrel?
> Monit is what you are looking for.

There is also Process.rlimit.
The upside of rlimit, compared to monit, is that it will kill Mongrel
BEFORE it exceeds its allocation quota. The downside is that it will
not start another.

So, if you need to defend against normal memory leaks, monit is a must
have (for restarts), while Process.rlimit can be an extra precaution
against those cases when something is trying to allocate a lot of RAM
at once, and runs the box into swapping hell before monit has a chance
to kill the offending process.

Alex

From alexey.verkhovsky at gmail.com  Wed Apr  4 13:15:20 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 4 Apr 2007 11:15:20 -0600
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <8DFCE75B-2BCC-4963-BFF0-6ED51403A720@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
	<33841ac70704031619y7d90c6c1n448e887151da246a@mail.gmail.com>
	<8DFCE75B-2BCC-4963-BFF0-6ED51403A720@brainspl.at>
Message-ID: <3945c4270704041015u3ffe88fenfab607235b70ceea@mail.gmail.com>

On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>         The reason it's not in mongrel is because bradley made the
> mongrel_cluster gem and so Zed saw no reason to add the same stuff in
> mongrel.
>
>         I have asked for a --clean option for the mongel_rails command that
> would cleanup PID"s but I haven't had time to make a patch,

Same story here. I keep meaning to sit down and write that patch for
the last 10 days or so. If you get there first, please ping me
off-list.

Another daemonization problem to look at is this: when there is no pid
file, but the port is bound to some other process, 'mongrel_rails
start' silently exits with exit code zero. Meantime, the .pid file is
created a few seconds AFTER 'mongrel_rails start' is done. This is not
as important as above, but kind of not right, and in the same area.

Alex

From pete at nextengine.com  Wed Apr  4 13:37:50 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 10:37:50 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <71166b3b0704040938s589d3d5ar3cb40431a471050b@mail.gmail.com>
References: <mailman.48.1175700493.19662.mongrel-users@rubyforge.org>
	<4613C7FA.1050106@gmail.com>
	<71166b3b0704040938s589d3d5ar3cb40431a471050b@mail.gmail.com>
Message-ID: <1E2F9449-9971-4AE2-9AB7-A2FE6CBB7170@nextengine.com>

> What you have to do is set:
>
> ActiveRecord::Base.verification_timeout = 14400
>
> Or to any value that is lower than the MySQL server's
> interactive_timeout setting. This will make sure that ActiveRecord
> checks the connection often enough to reset the connection.

Sweet.  Thanks Luis.  This is exactly what I'm looking for.

-Pete




On Apr 4, 2007, at 9:38 AM, Luis Lavena wrote:

> On 4/4/07, kaushik.ghose <kaushik.ghose at gmail.com> wrote:
>> Pete DeLaurentis wrote:
>>
>>> Here's a question: Is anyone running ruby1.8.6 succesfully with  
>>> mongrel?
>> On Windows Vista I'm running Mongrel with Ruby 1.8.6, rails 1.2.3  
>> as a
>> service. I have no problems with the service shutting down or  
>> becoming
>> unresponsive. I run this on a laptop, (with hibernation) uptime  
>> upto 50
>> hrs hasn't been a problem.
>>
>
> Hehehe, is good to know that you are up and running Kaus ;-)
>
>> The "500 Internal Server Error" rings a bell, but I can't remember  
>> what
>> was causing it and the issue has been resolved for me.
>>
>
> Maybe MySql timeout? from mongrel faq [1]
>
> Q. Mongrel stops working if it's left alone for a long time.
>
> If you find that Mongrel stops working after a long idle time and
> you're using MySQL then you're hitting a bug in the MySQL driver that
> doesn't properly timeout connections. What happens is the MySQL server
> side of the connection times out and closes, but the MySQL client
> doesn't detect this and just sits there.
>
> What you have to do is set:
>
> ActiveRecord::Base.verification_timeout = 14400
>
> Or to any value that is lower than the MySQL server's
> interactive_timeout setting. This will make sure that ActiveRecord
> checks the connection often enough to reset the connection.
>
>
> [1] http://mongrel.rubyforge.org/faq.html
>
> -- 
> Luis Lavena
> Multimedia systems
> -
> Leaders are made, they are not born. They are made by hard effort,
> which is the price which all of us must pay to achieve any goal that
> is worthwhile.
> Vince Lombardi
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From ctmailinglists at googlemail.com  Wed Apr  4 18:50:14 2007
From: ctmailinglists at googlemail.com (Chris T)
Date: Wed, 04 Apr 2007 23:50:14 +0100
Subject: [Mongrel] Monit / mongel_cluster 0.2.2 / mongrel 1.0.1
Message-ID: <46142BA6.1020001@googlemail.com>

Paul
Did you ever get to the bottom of this. I'm having a similar (though possibly different) problem with a Rails app failing occasionally and on just one mongrel instance, which from the trace and behaviour seems to be ImageSceince/RubyInline related.
See my post on Rails deployment group: http://groups.google.co.uk/group/rubyonrails-deployment/browse_thread/thread/8ffd04de15bfb7a4?hl=en

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


From blindance at gmail.com  Thu Apr  5 03:55:36 2007
From: blindance at gmail.com (blindance at gmail.com)
Date: Thu, 5 Apr 2007 16:55:36 +0900
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0704030913k233ca8cy6c6f026ab5ebcf41@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
	<71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
	<474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>
	<71166b3b0704030913k233ca8cy6c6f026ab5ebcf41@mail.gmail.com>
Message-ID: <474e0f150704050055s2d67deb8tdbf7669e0beb994f@mail.gmail.com>

>I'll like to know from Vista users that hang on the list about their
>results too, since WinAPI is always a pain to get working on different
>platforms.

okay, results are;


Vista64:
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 1844      proc_info.exe
 Module32First (PID, name): 1844           proc_info.exe
 GetProcessImageFileName (PID, name): 1844
\Device\HarddiskVolume1\Users\fukuoka\Desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 1968      <unknown>
 Module32First (PID, name): 1968           Error Creating Snap (SNAPMODULE)
 GetLastError: 299Only part of a ReadProcessMemory or
WriteProcessMemory request was completed.
 <unknown>
 GetProcessImageFileName (PID, name): 1968
\Device\HarddiskVolume1\Windows\System32\cmd.exe



Vista32:
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 1468      proc_info.exe
 Module32First (PID, name): 1468           proc_info.exe
 GetProcessImageFileName (PID, name): 1468
\Device\HarddiskVolume1\Users\test\Desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 3944      cmd.exe
 Module32First (PID, name): 3944           cmd.exe
 GetProcessImageFileName (PID, name): 3944
\Device\HarddiskVolume1\Windows\System32\cmd.exe

From luislavena at gmail.com  Thu Apr  5 06:58:03 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 5 Apr 2007 07:58:03 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <474e0f150704050055s2d67deb8tdbf7669e0beb994f@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
	<71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
	<474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>
	<71166b3b0704030913k233ca8cy6c6f026ab5ebcf41@mail.gmail.com>
	<474e0f150704050055s2d67deb8tdbf7669e0beb994f@mail.gmail.com>
Message-ID: <71166b3b0704050358s5270bb1dxbee0cf6113d7a426@mail.gmail.com>

On 4/5/07, blindance at gmail.com <blindance at gmail.com> wrote:
> >I'll like to know from Vista users that hang on the list about their
> >results too, since WinAPI is always a pain to get working on different
> >platforms.
>
> okay, results are;
>
>
> Vista64:
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 1844      proc_info.exe
>  Module32First (PID, name): 1844           proc_info.exe
>  GetProcessImageFileName (PID, name): 1844
> \Device\HarddiskVolume1\Users\fukuoka\Desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 1968      <unknown>
>  Module32First (PID, name): 1968           Error Creating Snap (SNAPMODULE)
>  GetLastError: 299Only part of a ReadProcessMemory or
> WriteProcessMemory request was completed.
>  <unknown>
>  GetProcessImageFileName (PID, name): 1968
> \Device\HarddiskVolume1\Windows\System32\cmd.exe
>
>
>
> Vista32:
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 1468      proc_info.exe
>  Module32First (PID, name): 1468           proc_info.exe
>  GetProcessImageFileName (PID, name): 1468
> \Device\HarddiskVolume1\Users\test\Desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 3944      cmd.exe
>  Module32First (PID, name): 3944           cmd.exe
>  GetProcessImageFileName (PID, name): 3944
> \Device\HarddiskVolume1\Windows\System32\cmd.exe


Perfect!, that means the API is forward compatible.

Ok, will patch mongrel tonight and do a pre-release tomorrow morning.

Thank you guys for testing and providing feedback.

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 bhjackson at gmail.com  Fri Apr  6 01:00:02 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Fri, 6 Apr 2007 02:00:02 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
Message-ID: <cb03bffe0704052200u6226fc9cwa70c4fe8c6e6c5ac@mail.gmail.com>

> Are you running these tests cold? You probably want to throw out the
> first bunch of requests (say, 1000) to better simulate real-world
> running conditions.

You mean disregard them in the stats? Would you mind explaining this a
little more?

> Also, what's up with the non-2xx responses? Are you benchmarking an
> error page or something?

No, maybe because I'm hitting eship.com.br and not www.eship.com.br
it's throwing a 301? Will have to double-check my setup.

From bhjackson at gmail.com  Fri Apr  6 01:00:30 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Fri, 6 Apr 2007 02:00:30 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <683a886f0704031458v722f6373o4c7a1b31dfbfe9b0@mail.gmail.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
	<683a886f0704031458v722f6373o4c7a1b31dfbfe9b0@mail.gmail.com>
Message-ID: <cb03bffe0704052200p597f0cf6v98aaa9c8d05c9430@mail.gmail.com>

> You might try a more current version of Nginx and see if the proxying
> performance has improved compared to the FastCGI support. You're using
> a fairly old version.
>
> http://nginx.net/CHANGES

Will check this out and report the results. Thanks :)

From njvack at wisc.edu  Fri Apr  6 09:52:49 2007
From: njvack at wisc.edu (Nathan Vack)
Date: Fri, 6 Apr 2007 08:52:49 -0500
Subject: [Mongrel] FastCGI performing better than Mongrel - what am
	I	doing wrong?
In-Reply-To: <cb03bffe0704052200u6226fc9cwa70c4fe8c6e6c5ac@mail.gmail.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
	<cb03bffe0704052200u6226fc9cwa70c4fe8c6e6c5ac@mail.gmail.com>
Message-ID: <27EF4F88-D36D-4E03-8274-E8AB41CF3337@wisc.edu>

On Apr 6, 2007, at 12:00 AM, Benjamin Jackson wrote:

>> Are you running these tests cold? You probably want to throw out the
>> first bunch of requests (say, 1000) to better simulate real-world
>> running conditions.
>
> You mean disregard them in the stats? Would you mind explaining this a
> little more?

Right after you start a lot of processes, there's a bunch of  
optimization that takes place -- frequently used files are read into  
cache, database connections are set up, necessary parts of the  
operating system are paged into memory, perhaps your VM is setting  
itself up, maybe Rails is generating caches...

All of this stuff takes time, and can make requests really slow.  
Fortunately, you almost never run Rails immediately after startup  
(unless you're using rmagick or something ;-) so throwing out the  
data with that startup hit will give you a better idea of how your  
site will perform in the real world.

In your case, it looked to me like Mongrel's median times were faster  
-- your totals were longer because of a very large max time.

-Nate


From francois.beausoleil at gmail.com  Fri Apr  6 11:30:01 2007
From: francois.beausoleil at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Beausoleil?=)
Date: Fri, 6 Apr 2007 11:30:01 -0400
Subject: [Mongrel] Problem using a configuration file
Message-ID: <41d5fadf0704060830g60b81edbuef5baacb1018c6b8@mail.gmail.com>

Hi all,

I'm trying to start Mongrel using a configuration file, but Mongrel complains:
$ sudo mongrel_rails start --config
/usr/local/www/xltester.com/config/mongrel.yml
!!! Path to log file not valid: log/mongrel.log
mongrel::start reported an error. Use mongrel_rails mongrel::start -h
to get help.

I'm using sudo above to replicate monit, not because I run Mongrel as
root.  Here's Mongrel's config file:

$ cat /usr/local/www/xltester.com/config/mongrel.yml
---
:environment: production
:host: 127.0.0.1
:config_file:
:group: xltester
:num_processors: 1024
:docroot: /usr/local/www/xltester.com/public
:port: "4785"
:prefix:
:mime_map:
:cwd: /usr/local/www/xltester.com
:debug: false
:daemon: true
:log_file: /usr/local/www/xltester.com/log/mongrel.log
:includes:
- mongrel
:user: xltester
:pid_file: /usr/local/www/xltester.com/log/mongrel.4785.pid
:timeout: 0
:config_script:

The permissions are:
$ ls -ld /usr/local/www/xltester.com/config
drwx------ 5 xltester xltester 4096 2007-04-06 13:35
/usr/local/www/xltester.com/config
$ ls -ld /usr/local/www/xltester.com/config/mongrel.yml
-rw------- 1 xltester xltester 426 2007-04-06 13:34
/usr/local/www/xltester.com/config/mongrel.yml

Mongrel's log files stay empty, and the PID file is obviously not generated.

At first, I had specified the log_file, pid_file and docroot options
as relative paths to cwd, but Mongrel complained with the same message
as above.

Anyway, what am I doing wrong here ?

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

From bhjackson at gmail.com  Fri Apr  6 12:53:38 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Fri, 6 Apr 2007 13:53:38 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <27EF4F88-D36D-4E03-8274-E8AB41CF3337@wisc.edu>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
	<cb03bffe0704052200u6226fc9cwa70c4fe8c6e6c5ac@mail.gmail.com>
	<27EF4F88-D36D-4E03-8274-E8AB41CF3337@wisc.edu>
Message-ID: <cb03bffe0704060953vc305e7fmcfa6a6445360d6b8@mail.gmail.com>

> Right after you start a lot of processes, there's a bunch of
> optimization that takes place -- frequently used files are read into
> cache, database connections are set up, necessary parts of the
> operating system are paged into memory, perhaps your VM is setting
> itself up, maybe Rails is generating caches...
>
> All of this stuff takes time, and can make requests really slow.
> Fortunately, you almost never run Rails immediately after startup
> (unless you're using rmagick or something ;-) so throwing out the
> data with that startup hit will give you a better idea of how your
> site will perform in the real world.
>
> In your case, it looked to me like Mongrel's median times were faster
> -- your totals were longer because of a very large max time.

I understand the startup overhead, but was under the impression that
it only affected the first request, not the first thousand. I assume
you're under the impression that I'm running these immediately after
starting up the server without hitting the page once. While I'm pretty
sure I hit all the pages before testing, I'll run some more tests,
this time making sure that the page requested has been hit once in the
browser beforehand.

Looking back at the results, yeah, the median connection time for two
mongrels is indeed faster than for one FCGI, but two FCGIs still comes
in considerably faster than two mongrels. Is there any RAM advantage
gained by using two mongrels instead of two FCGI procs, or any other
compelling reason for me to use mongrel instead if my connection times
remain significantly faster for FCGI when the server is warmed up and
ready?

Ben

From hpoydar at gmail.com  Sat Apr  7 10:54:11 2007
From: hpoydar at gmail.com (Henry)
Date: Sat, 7 Apr 2007 10:54:11 -0400
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
Message-ID: <8493AF6A-0C12-4F3C-B54D-7C875D9C499D@gmail.com>

Ezra,

Would you mind sharing the portion of your monit.conf that handles  
the cluster?

Many thanks,
Henry


On Apr 3, 2007, at 6:28 PM, Ezra Zygmuntowicz wrote:

>
> 	Yes mongrel_cluster handles the pid files. Also it does a better job
> of stopping mongrels. The problem I had when I used monit and
> mongrel_rails without mongrel_cluster was that if a mongrel used too
> much memory monit woudl not be able to stop it sometimes and so
> execution woudl fail and timeout.
>
> 	Using mongrel_clutser avoids this problem completely. Trust me I've
> tried it all different ways. I did monit without mongrel_cluster for
> a about a full month on close to 200 servers and then switched them
> all to monit and mongrel_cluster and get much better results.
>
> -Ezra
>
> On Apr 3, 2007, at 3:00 PM, snacktime wrote:
>
>> Makes sense that mongrel_cluster would handle a lot of edge cases
>> better then monit.  Is it mainly the pid file handling that has been
>> the main issue so far?
>>
>> Have you tried daemontools?  Seems to me like it would be more
>> reliable since you wouldn't have to deal with pid files and
>> backgrounding mongrel.
>>
>> Chris
>>
>> On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>>>
>>> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
>>>
>>>> Is there anything mongrel cluster gives you that monit doesn't?
>>>> I'll
>>>> be using monit to monitor a number of other services anyways, so it
>>>> seems logical to just use it for everything including mongrel.
>>>>
>>>> Chris
>>>>
>>>
>>> Chris-
>>>
>>>         WHen you use monit you can still use mongrel_cluster to
>>> manage it.
>>> You need the latest pre release of mongrel_cluster. This is the best
>>> configuration I've been able to come up with for 64Bit systems. If
>>> your on 32bit system then you can lower the memory limits by about
>>> 20-30%
>>>
>>> check process mongrel_<%= @username %>_5000
>>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
>>>    start program = "/usr/bin/mongrel_rails cluster::start -C / 
>>> data/<%
>>> = @username %>/current/config/mongrel_cluster.yml --clean --only
>>> 5000"
>>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
>>> @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>>>    if totalmem is greater than 110.0 MB for 4 cycles then
>>> restart       # eating up memory?
>>>    if cpu is greater than 50% for 2 cycles then
>>> alert                  # send an email to admin
>>>    if cpu is greater than 80% for 3 cycles then
>>> restart                # hung process?
>>>    if loadavg(5min) greater than 10 for 8 cycles then
>>> restart          # bad, bad, bad
>>>    if 20 restarts within 20 cycles then
>>> timeout                         # something is wrong, call the sys-
>>> admin
>>>    group mongrel
>>>
>>> check process mongrel_<%= @username %>_5001
>>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
>>>    start program = "/usr/bin/mongrel_rails cluster::start -C / 
>>> data/<%
>>> = @username %>/current/config/mongrel_cluster.yml --clean --only
>>> 5001"
>>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
>>> @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>>>    if totalmem is greater than 110.0 MB for 4 cycles then
>>> restart       # eating up memory?
>>>    if cpu is greater than 50% for 2 cycles then
>>> alert                  # send an email to admin
>>>    if cpu is greater than 80% for 3 cycles then
>>> restart                # hung process?
>>>    if loadavg(5min) greater than 10 for 8 cycles then
>>> restart          # bad, bad, bad
>>>    if 20 restarts within 20 cycles then
>>> timeout                         # something is wrong, call the sys-
>>> admin
>>>    group mongrel
>>>
>>> check process mongrel_<%= @username %>_5002
>>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
>>>    start program = "/usr/bin/mongrel_rails cluster::start -C / 
>>> data/<%
>>> = @username %>/current/config/mongrel_cluster.yml --clean --only
>>> 5002"
>>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
>>> @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>>>    if totalmem is greater than 110.0 MB for 4 cycles then
>>> restart       # eating up memory?
>>>    if cpu is greater than 50% for 2 cycles then
>>> alert                  # send an email to admin
>>>    if cpu is greater than 80% for 3 cycles then
>>> restart                # hung process?
>>>    if loadavg(5min) greater than 10 for 8 cycles then
>>> restart          # bad, bad, bad
>>>    if 20 restarts within 20 cycles then
>>> timeout                         # something is wrong, call the sys-
>>> admin
>>>    group mongrel
>>>
>>>
>>>         I wen't for a while using my own scripts to start and stop
>>> mongrel
>>> without using mongrel_cluster. But it works more reliably when I use
>>> mongrel_cluster and monit together.
>>>
>>> Cheers-
>>> -- Ezra Zygmuntowicz
>>> -- Lead Rails Evangelist
>>> -- ez at engineyard.com
>>> -- Engine Yard, Serious Rails Hosting
>>> -- (866) 518-YARD (9273)
>>>
>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>
> -- Ezra Zygmuntowicz 
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From RRussell at thoughtworks.com  Sun Apr  8 11:01:40 2007
From: RRussell at thoughtworks.com (Rolf Russell)
Date: Sun, 8 Apr 2007 10:01:40 -0500
Subject: [Mongrel] Rolf Russell is out of the office.
Message-ID: <OF855F6B6E.BE2E576F-ON862572B7.00528D27-862572B7.00528D27@thoughtworks.com>


I will be out of the office starting  04/06/2007 and will not return until
04/24/2007.

I will respond to your message when I return.


From ezmobius at gmail.com  Sun Apr  8 12:40:07 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Sun, 8 Apr 2007 09:40:07 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <8493AF6A-0C12-4F3C-B54D-7C875D9C499D@gmail.com>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
	<8493AF6A-0C12-4F3C-B54D-7C875D9C499D@gmail.com>
Message-ID: <8CA5A8B1-E689-476E-9534-5E2214F30961@brainspl.at>

Henry-

	That is what it quoted earlier in this email. Here is the monitrc  
for one mongrel using mongrel_cluster:

check process mongrel_USERNAME_5000
   with pidfile /data/USERNAME/shared/log/mongrel.5000.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/ 
USERNAME/current/config/mongrel_cluster.yml --clean --only 5000"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/ 
USERNAME/current/config/mongrel_cluster.yml  --only 5000"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel


	You need one of those entries for each mongrel you need to run.

Cheers-
-Ezra


On Apr 7, 2007, at 7:54 AM, Henry wrote:

> Ezra,
>
> Would you mind sharing the portion of your monit.conf that handles
> the cluster?
>
> Many thanks,
> Henry
>
>
> On Apr 3, 2007, at 6:28 PM, Ezra Zygmuntowicz wrote:
>
>>
>> 	Yes mongrel_cluster handles the pid files. Also it does a better job
>> of stopping mongrels. The problem I had when I used monit and
>> mongrel_rails without mongrel_cluster was that if a mongrel used too
>> much memory monit woudl not be able to stop it sometimes and so
>> execution woudl fail and timeout.
>>
>> 	Using mongrel_clutser avoids this problem completely. Trust me I've
>> tried it all different ways. I did monit without mongrel_cluster for
>> a about a full month on close to 200 servers and then switched them
>> all to monit and mongrel_cluster and get much better results.
>>
>> -Ezra
>>
>> On Apr 3, 2007, at 3:00 PM, snacktime wrote:
>>
>>> Makes sense that mongrel_cluster would handle a lot of edge cases
>>> better then monit.  Is it mainly the pid file handling that has been
>>> the main issue so far?
>>>
>>> Have you tried daemontools?  Seems to me like it would be more
>>> reliable since you wouldn't have to deal with pid files and
>>> backgrounding mongrel.
>>>
>>> Chris
>>>
>>> On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>>>>
>>>> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
>>>>
>>>>> Is there anything mongrel cluster gives you that monit doesn't?
>>>>> I'll
>>>>> be using monit to monitor a number of other services anyways,  
>>>>> so it
>>>>> seems logical to just use it for everything including mongrel.
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>> Chris-
>>>>
>>>>         WHen you use monit you can still use mongrel_cluster to
>>>> manage it.
>>>> You need the latest pre release of mongrel_cluster. This is the  
>>>> best
>>>> configuration I've been able to come up with for 64Bit systems. If
>>>> your on 32bit system then you can lower the memory limits by about
>>>> 20-30%
>>>>
>>>> check process mongrel_<%= @username %>_5000
>>>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
>>>>    start program = "/usr/bin/mongrel_rails cluster::start -C /
>>>> data/<%
>>>> = @username %>/current/config/mongrel_cluster.yml --clean --only
>>>> 5000"
>>>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/ 
>>>> <%=
>>>> @username %>/current/config/mongrel_cluster.yml --clean --only  
>>>> 5000"
>>>>    if totalmem is greater than 110.0 MB for 4 cycles then
>>>> restart       # eating up memory?
>>>>    if cpu is greater than 50% for 2 cycles then
>>>> alert                  # send an email to admin
>>>>    if cpu is greater than 80% for 3 cycles then
>>>> restart                # hung process?
>>>>    if loadavg(5min) greater than 10 for 8 cycles then
>>>> restart          # bad, bad, bad
>>>>    if 20 restarts within 20 cycles then
>>>> timeout                         # something is wrong, call the sys-
>>>> admin
>>>>    group mongrel
>>>>
>>>> check process mongrel_<%= @username %>_5001
>>>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
>>>>    start program = "/usr/bin/mongrel_rails cluster::start -C /
>>>> data/<%
>>>> = @username %>/current/config/mongrel_cluster.yml --clean --only
>>>> 5001"
>>>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/ 
>>>> <%=
>>>> @username %>/current/config/mongrel_cluster.yml --clean --only  
>>>> 5001"
>>>>    if totalmem is greater than 110.0 MB for 4 cycles then
>>>> restart       # eating up memory?
>>>>    if cpu is greater than 50% for 2 cycles then
>>>> alert                  # send an email to admin
>>>>    if cpu is greater than 80% for 3 cycles then
>>>> restart                # hung process?
>>>>    if loadavg(5min) greater than 10 for 8 cycles then
>>>> restart          # bad, bad, bad
>>>>    if 20 restarts within 20 cycles then
>>>> timeout                         # something is wrong, call the sys-
>>>> admin
>>>>    group mongrel
>>>>
>>>> check process mongrel_<%= @username %>_5002
>>>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
>>>>    start program = "/usr/bin/mongrel_rails cluster::start -C /
>>>> data/<%
>>>> = @username %>/current/config/mongrel_cluster.yml --clean --only
>>>> 5002"
>>>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/ 
>>>> <%=
>>>> @username %>/current/config/mongrel_cluster.yml --clean --only  
>>>> 5002"
>>>>    if totalmem is greater than 110.0 MB for 4 cycles then
>>>> restart       # eating up memory?
>>>>    if cpu is greater than 50% for 2 cycles then
>>>> alert                  # send an email to admin
>>>>    if cpu is greater than 80% for 3 cycles then
>>>> restart                # hung process?
>>>>    if loadavg(5min) greater than 10 for 8 cycles then
>>>> restart          # bad, bad, bad
>>>>    if 20 restarts within 20 cycles then
>>>> timeout                         # something is wrong, call the sys-
>>>> admin
>>>>    group mongrel
>>>>
>>>>
>>>>         I wen't for a while using my own scripts to start and stop
>>>> mongrel
>>>> without using mongrel_cluster. But it works more reliably when I  
>>>> use
>>>> mongrel_cluster and monit together.
>>>>
>>>> Cheers-
>>>> -- Ezra Zygmuntowicz
>>>> -- Lead Rails Evangelist
>>>> -- ez at engineyard.com
>>>> -- Engine Yard, Serious Rails Hosting
>>>> -- (866) 518-YARD (9273)
>>>>
>>>>
>>>> _______________________________________________
>>>> Mongrel-users mailing list
>>>> Mongrel-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>
>>
>> -- Ezra Zygmuntowicz 
>> -- Lead Rails Evangelist
>> -- ez at engineyard.com
>> -- Engine Yard, Serious Rails Hosting
>> -- (866) 518-YARD (9273)
>>
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

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



From hpoydar at gmail.com  Sun Apr  8 15:43:32 2007
From: hpoydar at gmail.com (Henry)
Date: Sun, 8 Apr 2007 15:43:32 -0400
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <8CA5A8B1-E689-476E-9534-5E2214F30961@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
	<8493AF6A-0C12-4F3C-B54D-7C875D9C499D@gmail.com>
	<8CA5A8B1-E689-476E-9534-5E2214F30961@brainspl.at>
Message-ID: <B3B5259E-C427-417D-858F-26474ADAA810@gmail.com>

Thanks, Ezra.  Apologies for not checking the whole thread.

On Apr 8, 2007, at 12:40 PM, Ezra Zygmuntowicz wrote:

> Henry-
>
> 	That is what it quoted earlier in this email. Here is the monitrc
> for one mongrel using mongrel_cluster:
>
> check process mongrel_USERNAME_5000
>    with pidfile /data/USERNAME/shared/log/mongrel.5000.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/
> USERNAME/current/config/mongrel_cluster.yml --clean --only 5000"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/
> USERNAME/current/config/mongrel_cluster.yml  --only 5000"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys- 
> admin
>    group mongrel
>
>
> 	You need one of those entries for each mongrel you need to run.
>
> Cheers-
> -Ezra
>
>
> On Apr 7, 2007, at 7:54 AM, Henry wrote:
>
>> Ezra,
>>
>> Would you mind sharing the portion of your monit.conf that handles
>> the cluster?
>>
>> Many thanks,
>> Henry
>>
>>
>> On Apr 3, 2007, at 6:28 PM, Ezra Zygmuntowicz wrote:
>>
>>>
>>> 	Yes mongrel_cluster handles the pid files. Also it does a better  
>>> job
>>> of stopping mongrels. The problem I had when I used monit and
>>> mongrel_rails without mongrel_cluster was that if a mongrel used too
>>> much memory monit woudl not be able to stop it sometimes and so
>>> execution woudl fail and timeout.
>>>
>>> 	Using mongrel_clutser avoids this problem completely. Trust me I've
>>> tried it all different ways. I did monit without mongrel_cluster for
>>> a about a full month on close to 200 servers and then switched them
>>> all to monit and mongrel_cluster and get much better results.
>>>
>>> -Ezra
>>>
>>> On Apr 3, 2007, at 3:00 PM, snacktime wrote:
>>>
>>>> Makes sense that mongrel_cluster would handle a lot of edge cases
>>>> better then monit.  Is it mainly the pid file handling that has  
>>>> been
>>>> the main issue so far?
>>>>
>>>> Have you tried daemontools?  Seems to me like it would be more
>>>> reliable since you wouldn't have to deal with pid files and
>>>> backgrounding mongrel.
>>>>
>>>> Chris
>>>>
>>>> On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>>>>>
>>>>> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
>>>>>
>>>>>> Is there anything mongrel cluster gives you that monit doesn't?
>>>>>> I'll
>>>>>> be using monit to monitor a number of other services anyways,
>>>>>> so it
>>>>>> seems logical to just use it for everything including mongrel.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>
>>>>> Chris-
>>>>>
>>>>>         WHen you use monit you can still use mongrel_cluster to
>>>>> manage it.
>>>>> You need the latest pre release of mongrel_cluster. This is the
>>>>> best
>>>>> configuration I've been able to come up with for 64Bit systems. If
>>>>> your on 32bit system then you can lower the memory limits by about
>>>>> 20-30%
>>>>>
>>>>> check process mongrel_<%= @username %>_5000
>>>>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
>>>>>    start program = "/usr/bin/mongrel_rails cluster::start -C /
>>>>> data/<%
>>>>> = @username %>/current/config/mongrel_cluster.yml --clean --only
>>>>> 5000"
>>>>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/
>>>>> <%=
>>>>> @username %>/current/config/mongrel_cluster.yml --clean --only
>>>>> 5000"
>>>>>    if totalmem is greater than 110.0 MB for 4 cycles then
>>>>> restart       # eating up memory?
>>>>>    if cpu is greater than 50% for 2 cycles then
>>>>> alert                  # send an email to admin
>>>>>    if cpu is greater than 80% for 3 cycles then
>>>>> restart                # hung process?
>>>>>    if loadavg(5min) greater than 10 for 8 cycles then
>>>>> restart          # bad, bad, bad
>>>>>    if 20 restarts within 20 cycles then
>>>>> timeout                         # something is wrong, call the  
>>>>> sys-
>>>>> admin
>>>>>    group mongrel
>>>>>
>>>>> check process mongrel_<%= @username %>_5001
>>>>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
>>>>>    start program = "/usr/bin/mongrel_rails cluster::start -C /
>>>>> data/<%
>>>>> = @username %>/current/config/mongrel_cluster.yml --clean --only
>>>>> 5001"
>>>>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/
>>>>> <%=
>>>>> @username %>/current/config/mongrel_cluster.yml --clean --only
>>>>> 5001"
>>>>>    if totalmem is greater than 110.0 MB for 4 cycles then
>>>>> restart       # eating up memory?
>>>>>    if cpu is greater than 50% for 2 cycles then
>>>>> alert                  # send an email to admin
>>>>>    if cpu is greater than 80% for 3 cycles then
>>>>> restart                # hung process?
>>>>>    if loadavg(5min) greater than 10 for 8 cycles then
>>>>> restart          # bad, bad, bad
>>>>>    if 20 restarts within 20 cycles then
>>>>> timeout                         # something is wrong, call the  
>>>>> sys-
>>>>> admin
>>>>>    group mongrel
>>>>>
>>>>> check process mongrel_<%= @username %>_5002
>>>>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
>>>>>    start program = "/usr/bin/mongrel_rails cluster::start -C /
>>>>> data/<%
>>>>> = @username %>/current/config/mongrel_cluster.yml --clean --only
>>>>> 5002"
>>>>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/
>>>>> <%=
>>>>> @username %>/current/config/mongrel_cluster.yml --clean --only
>>>>> 5002"
>>>>>    if totalmem is greater than 110.0 MB for 4 cycles then
>>>>> restart       # eating up memory?
>>>>>    if cpu is greater than 50% for 2 cycles then
>>>>> alert                  # send an email to admin
>>>>>    if cpu is greater than 80% for 3 cycles then
>>>>> restart                # hung process?
>>>>>    if loadavg(5min) greater than 10 for 8 cycles then
>>>>> restart          # bad, bad, bad
>>>>>    if 20 restarts within 20 cycles then
>>>>> timeout                         # something is wrong, call the  
>>>>> sys-
>>>>> admin
>>>>>    group mongrel
>>>>>
>>>>>
>>>>>         I wen't for a while using my own scripts to start and stop
>>>>> mongrel
>>>>> without using mongrel_cluster. But it works more reliably when I
>>>>> use
>>>>> mongrel_cluster and monit together.
>>>>>
>>>>> Cheers-
>>>>> -- Ezra Zygmuntowicz
>>>>> -- Lead Rails Evangelist
>>>>> -- ez at engineyard.com
>>>>> -- Engine Yard, Serious Rails Hosting
>>>>> -- (866) 518-YARD (9273)
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mongrel-users mailing list
>>>>> Mongrel-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>>
>>>> _______________________________________________
>>>> Mongrel-users mailing list
>>>> Mongrel-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>
>>>
>>> -- Ezra Zygmuntowicz 
>>> -- Lead Rails Evangelist
>>> -- ez at engineyard.com
>>> -- Engine Yard, Serious Rails Hosting
>>> -- (866) 518-YARD (9273)
>>>
>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>
> -- Ezra Zygmuntowicz 
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From rsanheim at gmail.com  Mon Apr  9 22:27:43 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Mon, 9 Apr 2007 21:27:43 -0500
Subject: [Mongrel] mongrel and log_level
Message-ID: <fc113d400704091927h403bb293s556bee37591cdc05@mail.gmail.com>

Hi all

I've noticed that the mongrel log output when run interactively (via
script/server) doesn't respect environment specific log levels,
because the logger is initialized way before the
'development_cached.rb' file is ever loaded (for example).

I'm guessing this is more a Rails issue then a Mongrel issue, so maybe
I should open or search for a ticket there?

- Rob
-- 
http://robsanheim.com
http://seekingalpha.com

From erik.hetzner at ucop.edu  Tue Apr 10 13:00:51 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Tue, 10 Apr 2007 10:00:51 -0700
Subject: [Mongrel] [OT] Ragel and FSM tutorials
In-Reply-To: <004501c7760c$cc9c02d0$0400a8c0@DEN2>
References: <D6347FBF-8FF9-4C9C-907D-7371434D39B2@mac.com>
	<004501c7760c$cc9c02d0$0400a8c0@DEN2>
Message-ID: <87d52cf9ks.wl%erik.hetzner@ucop.edu>

At Tue, 3 Apr 2007 12:26:13 -0400,
"Jim Hogue" <jjhogue at sbcglobal.net> wrote:
>
> (Off topic, but just in case others are interested :-).
>
> You should probably take a look at some computer science college level
> theory books.  Look for "Automata Theory", "Turing machines",
> "deterministic finite automation", and "non-deterministic finite
> automation".  The turning machine is the classic example.

[?]

Just to clarify, a Turing machine is not a finite automata but a more
powerful kind of theoretical device.

But this really isn?t the place. Start here
<http://en.wikipedia.org/wiki/Finite_state_machine>, skip the formal
definition at first, understand how a FSM can recognize regular
languages, and you?re on your way. The Sipser book referenced is
pretty good, in my opinion.

best,
Erik
-------------- 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/20070410/feccd1b9/attachment.bin 

From goodieboy at gmail.com  Tue Apr 10 14:26:34 2007
From: goodieboy at gmail.com (Matt M.)
Date: Tue, 10 Apr 2007 14:26:34 -0400
Subject: [Mongrel] comparison... why mongrel?
Message-ID: <c66dcac40704101126o6ed064f5o7404e26c8c51e527@mail.gmail.com>

Hi,

I've recently deployed a rails app and our platform is Apache 2.2 + mongrel
cluster. It seems to be working fine... although no real tests yet. I just
recently found out that it is *quite* possible that the live server will not
be getting an update to apache 2.2, and the current version is 1.3. So...
I've installed Apache 1.3 + FastCGI on the dev server and it's running fine
but...

In order to get any chance of having the admins upgrade Apache on the live
server... they want to know what the advantages are over using FastCGI
(which is a simple Apache mod install).

What makes Mongrel different that FastCGI?

What are the pros and cons of both?

Thank you for any feedback... I'm off to rdo more research!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070410/00bf843c/attachment.html 

From msoulier at digitaltorque.ca  Tue Apr 10 14:45:26 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Tue, 10 Apr 2007 14:45:26 -0400
Subject: [Mongrel] comparison... why mongrel?
In-Reply-To: <c66dcac40704101126o6ed064f5o7404e26c8c51e527@mail.gmail.com>
References: <c66dcac40704101126o6ed064f5o7404e26c8c51e527@mail.gmail.com>
Message-ID: <20070410184526.GF11892@tigger.digitaltorque.ca>

On 10/04/07 Matt M. said:

> What makes Mongrel different that FastCGI?

Personally, I find FastCGI's implementation in apache to be buggy, but that's
my experience. 

I just found the --prefix argument in mongrel, and it just saved Rails from
the rather shortsighted assumption that all Rails sites will be deployed at
the root of the site. 

As a side-question, does anyone know how to make Rails compose URLs properly
without using --prefix in mongrel?

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/20070410/42d8bd43/attachment.bin 

From kylekochis at gmail.com  Tue Apr 10 15:16:50 2007
From: kylekochis at gmail.com (Kyle Kochis)
Date: Tue, 10 Apr 2007 13:16:50 -0600
Subject: [Mongrel] comparison... why mongrel?
In-Reply-To: <c66dcac40704101126o6ed064f5o7404e26c8c51e527@mail.gmail.com>
References: <c66dcac40704101126o6ed064f5o7404e26c8c51e527@mail.gmail.com>
Message-ID: <6a7034b0704101216l5ca903cby1020a5ab55fa9049@mail.gmail.com>

My personal experiences with FastCGI have been buggy and just not very agile
at all. Setting up FastCGI was always a pain so I tried mongrel which was
just more simple and much less buggy. FastCGI is a little faster than
mongrel because mongrel has to use TCP and FCGI uses unix sockets. But if
you plan on scaling your application(s) to more machines then TCP (mongrel)
is clearly better than using unix sockets (FCGI). So my two main arguments
are agility and scalability. Additionally mongrel has some nice features
that just make life better.
Kyle Kochis

On 4/10/07, Matt M. <goodieboy at gmail.com> wrote:
>
> Hi,
>
> I've recently deployed a rails app and our platform is Apache 2.2 +
> mongrel cluster. It seems to be working fine... although no real tests yet.
> I just recently found out that it is *quite* possible that the live server
> will not be getting an update to apache 2.2, and the current version is
> 1.3. So... I've installed Apache 1.3 + FastCGI on the dev server and it's
> running fine but...
>
> In order to get any chance of having the admins upgrade Apache on the live
> server... they want to know what the advantages are over using FastCGI
> (which is a simple Apache mod install).
>
> What makes Mongrel different that FastCGI?
>
> What are the pros and cons of both?
>
> Thank you for any feedback... I'm off to rdo more research!
>
> Matt
>
> _______________________________________________
> 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/20070410/503dfd95/attachment.html 

From mzukowski at urbacon.net  Tue Apr 10 15:32:33 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Tue, 10 Apr 2007 15:32:33 -0400
Subject: [Mongrel] comparison... why mongrel?
In-Reply-To: <c66dcac40704101126o6ed064f5o7404e26c8c51e527@mail.gmail.com>
References: <c66dcac40704101126o6ed064f5o7404e26c8c51e527@mail.gmail.com>
Message-ID: <461BE651.3050607@urbacon.net>

The simple answer -- but one that probably won't satisfy your sysadmins
-- is that Mongrel is just easier to work with.

It's a tool built specifically around Rails/Ruby, and as such it
includes a lot of niceties that make using it a generally more pleasant
experience.

In my experience this is especially true if a) you are doing a lot of
active development (because restarting the server and debugging is a lot
easier than with FastCGI), and/or b) you plan on scaling later on with
something like Mongrel cluster. Keep in mind that even though this might
be a production environment, in the early stages of development you will
probably find yourself having to debug things on the production
instance. Environment-specific bugs will almost always show up. This is
where FastCGI can be extremely annoying compared to Mongrel.


Matt M. wrote:
> Hi,
> 
> I've recently deployed a rails app and our platform is Apache 2.2 + mongrel
> cluster. It seems to be working fine... although no real tests yet. I just
> recently found out that it is *quite* possible that the live server will
> not
> be getting an update to apache 2.2, and the current version is 1.3. So...
> I've installed Apache 1.3 + FastCGI on the dev server and it's running fine
> but...
> 
> In order to get any chance of having the admins upgrade Apache on the live
> server... they want to know what the advantages are over using FastCGI
> (which is a simple Apache mod install).
> 
> What makes Mongrel different that FastCGI?
> 
> What are the pros and cons of both?
> 
> Thank you for any feedback... I'm off to rdo more research!
> 
> Matt
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users



This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.



From grant at antiflux.org  Tue Apr 10 16:14:43 2007
From: grant at antiflux.org (Grant Hollingworth)
Date: Tue, 10 Apr 2007 14:14:43 -0600
Subject: [Mongrel] rails url prefix (was Re:  comparison... why mongrel?)
In-Reply-To: <20070410184526.GF11892@tigger.digitaltorque.ca>
References: <c66dcac40704101126o6ed064f5o7404e26c8c51e527@mail.gmail.com>
	<20070410184526.GF11892@tigger.digitaltorque.ca>
Message-ID: <20070410201443.GB381@antiflux.org>

* "Michael P. Soulier" <msoulier at digitaltorque.ca> [2007-04-10 12:55]:
>As a side-question, does anyone know how to make Rails compose URLs properly
>without using --prefix in mongrel?

Add this to environment.rb:
    ActionController::AbstractRequest.relative_url_root = "/blah"

From ross.singer at library.gatech.edu  Tue Apr 10 22:37:11 2007
From: ross.singer at library.gatech.edu (Ross Singer)
Date: Tue, 10 Apr 2007 22:37:11 -0400
Subject: [Mongrel] rails url prefix (was Re: comparison... why mongrel?)
In-Reply-To: <20070410201443.GB381@antiflux.org>
References: <c66dcac40704101126o6ed064f5o7404e26c8c51e527@mail.gmail.com>
	<20070410184526.GF11892@tigger.digitaltorque.ca>
	<20070410201443.GB381@antiflux.org>
Message-ID: <23b83f160704101937y621cacf6kb0894c0a6c651b86@mail.gmail.com>

Actually, there's a little more to it than that if you want your
public directory to work.

See:
http://www.ralree.info/2006/6/15/successful-settings-for-apache-forwarding-to-mongrel

-Ross.

On 4/10/07, Grant Hollingworth <grant at antiflux.org> wrote:
> * "Michael P. Soulier" <msoulier at digitaltorque.ca> [2007-04-10 12:55]:
> >As a side-question, does anyone know how to make Rails compose URLs properly
> >without using --prefix in mongrel?
>
> Add this to environment.rb:
>     ActionController::AbstractRequest.relative_url_root = "/blah"
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From bradley at railsmachine.com  Wed Apr 11 12:26:08 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Wed, 11 Apr 2007 12:26:08 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>
Message-ID: <461D0C20.5040009@railsmachine.com>

Thanks Carl. I'll patch this in and push the release. Last call!

Bradley

Carl Lerche wrote:
> For me, I fixed this problem by adding the following on line 79 of init.rb:
> 
> Dir.chdir(@options["cwd"]) if @options["cwd"]
> 
> -carl
> 
> On 3/27/07, Carl Lerche <carl.lerche at gmail.com> wrote:
>> Hello,
>>
>> I'm not sure if it's a slight bug with mongrel_cluster or me, but I'm
>> having some trouble running mongrel cluster with --clean in different
>> directories than the root of the rails app.
>>
>> It doesn't look like mongrel_cluster changes the working directory
>> anywhere (based off of the config file, but just passes the working
>> directory on to mongrel_rails. This is fine, except when it tries to
>> check the pid files. Does this make sense?
>>
>> thanks,
>> -carl
>>
>> On 3/27/07, Bradley Taylor <bradley at railsmachine.com> wrote:
>>> Hi Michele:
>>>
>>> Thanks for the freebsd report. I think there is a way for you to mount
>>> /proc to support linux process environment emulation.
>>>
>>> I'll also gladly accept a patch from anyone for 'ps' syntax that cause
>>> this warning.
>>>
>>> I think we'll release it as is today and due a quick patch if someone
>>> provides a fix.
>>>
>>> Regards,
>>> Bradley Taylor
>>> http://railsmachine.com
>>>
>>> Michele wrote:
>>>> Bradley,
>>>>
>>>> It seems to work on FreeBSD (I had to delete all gems before it
>>>> actually worked), even though I still get this:
>>>>
>>>> Checking all mongrel_clusters...
>>>> mongrel_rails cluster::status -C config.yml
>>>> ps: Process environment requires procfs(5)
>>>> ps: Process environment requires procfs(5)
>>>> ps: Process environment requires procfs(5)
>>>> ps: Process environment requires procfs(5)
>>>> ps: Process environment requires procfs(5)
>>>>
>>>> Best,
>>>> - MF
>>>>
>>>> --
>>>> Michele Finotto
>>>> http://finotto.org/
>>>> http://16bugs.com/
>>>> http://pagety.com/
>>>>
>>>>
>>>> On Mar 20, 2007, at 15:53 , Bradley Taylor wrote:
>>>>
>>>>> Hi all...
>>>>>
>>>>> Hopefully this is the last prelease. If people on non-linux systems
>>>>> could post back any problems with cluster::status, I'd appreciate it.
>>>>>
>>>>> Install with:
>>>>> gem install mongrel_cluster --source http://mongrel.rubyforge.org/
>>>>> releases/
>>>>>
>>>>> Note: This is only an update to mongrel_cluster and not Mongrel or
>>>>> other
>>>>> gems.
>>>>>
>>>>> Details about what's new (if you missed the first prerelease):
>>>>> http://blog.railsmachine.com/2007/2/26/mongrel_cluster-
>>>>> prerelease-1-0-1-1
>>>>>
>>>>> Thanks,
>>>>> Bradley Taylor
>>>>> http://railsmachine.com
>>>> _______________________________________________
>>>> Mongrel-users mailing list
>>>> Mongrel-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>
>>
>> --
>> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>>
> 
> 


From schoenm at earthlink.net  Wed Apr 11 13:55:29 2007
From: schoenm at earthlink.net (Michael A. Schoen)
Date: Wed, 11 Apr 2007 10:55:29 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461D0C20.5040009@railsmachine.com>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>
	<461D0C20.5040009@railsmachine.com>
Message-ID: <461D2111.6010803@earthlink.net>

Bradley Taylor wrote:
> Thanks Carl. I'll patch this in and push the release. Last call!

Just a question: why does a cluster restart do a stop and a start, 
rather than an actual restart on each Mongrel? A restart is "nicer", and 
handles much better cases in which a Mongrel can't (or shouldn't) stop 
immediately. The current stop/start approach means that the start often 
fails, because the stop hasn't actually shutdown the Mongrel yet.

Would it be possible to make doing an actual restart an option? Or 
another command that does a true restart?



From bradley at railsmachine.com  Wed Apr 11 14:48:50 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Wed, 11 Apr 2007 14:48:50 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461D2111.6010803@earthlink.net>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>
	<461D2111.6010803@earthlink.net>
Message-ID: <461D2D92.5040403@railsmachine.com>

Michael A. Schoen wrote:

> Just a question: why does a cluster restart do a stop and a start, 
> rather than an actual restart on each Mongrel? A restart is "nicer", and 
> handles much better cases in which a Mongrel can't (or shouldn't) stop 
> immediately. 

Originally, "cluster::restart" called "mongrel_rails restart". 
Unfortunately, this is not reliable for major changes and doing 
stop/start is the only way to guarantee that code changes will be applied.

 From the mongrel code (rails.rb, line 164):
# Reloads Rails.  This isn't too reliable really, but it
# should work for most minimal reload purposes.  The only reliable
# way to reload properly is to stop and then start the process.

I don't think it is entirely true to say that restart is "nicer" than 
stop/start. 'stop' waits for the current request to finish unless you 
use --force. In the context of a cluster, other cluster members will 
handle requests during the stop/start cycle.

 > The current stop/start approach means that the start often
 > fails, because the stop hasn't actually shutdown the Mongrel yet.
 >

It is possible that start will be called before the process is gone. 
I'll think about adding some sort of check in cluster::restart to verify 
the process is gone before calling start.

If your requests take a long time to complete, you might end up having 
other problems unless you have loads of ram and a million mongrels in 
your cluster.

 > Would it be possible to make doing an actual restart an option? Or
 > another command that does a true restart?

No, because it's unreliable.

Bradley



From schoenm at earthlink.net  Wed Apr 11 15:21:33 2007
From: schoenm at earthlink.net (Michael A. Schoen)
Date: Wed, 11 Apr 2007 12:21:33 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461D2D92.5040403@railsmachine.com>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>	<461D2111.6010803@earthlink.net>
	<461D2D92.5040403@railsmachine.com>
Message-ID: <461D353D.2060302@earthlink.net>

Bradley Taylor wrote:
> Unfortunately, this is not reliable for major changes and doing 
> stop/start is the only way to guarantee that code changes will be applied.
> 
>  From the mongrel code (rails.rb, line 164):
> # Reloads Rails.  This isn't too reliable really, but it
> # should work for most minimal reload purposes.  The only reliable
> # way to reload properly is to stop and then start the process.

Ah, but that's not what I'm suggesting -- a "reload" is distinct from a 
"restart". The "reload" option for Rails under Mongrel (from a HUP 
signal) just calls the Rails reload! method, and I understand how that 
can/will fail.

A "restart" (from a USR2 signal) just a plain old regular stop, with the 
  restart flag set such that once the Mongrel is stopped, it restarts.

This should nicely handle the situation in which a Mongrel might take a 
few seconds to shutdown (thereby missing it's start oppty).

Make sense?



From bradley at railsmachine.com  Wed Apr 11 17:12:59 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Wed, 11 Apr 2007 17:12:59 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461D353D.2060302@earthlink.net>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>
	<461D353D.2060302@earthlink.net>
Message-ID: <461D4F5B.8010208@railsmachine.com>

Sorry too many things going on... I was looking at the soft option.

Reviewing the code (Zed correct me if I'm wrong), stop and restart both 
call the same stop method. The graceful handling of an in-progress 
request is the same.

Restart also has some funky semantics when used in a cluster where it 
reuses the the command line arguments. This means that you can't modify 
the cluster configuration and apply the changes with a restart. The 
standard behavior of a linux (freebsd, etc) service is that 
configuration changes are reread on restart (apache, mysql,etc). So for 
the purposes of mongrel_cluster, restart == stop;start. Running a single 
mongrel with its own configuration file would behave as expected.

Bradley

Michael A. Schoen wrote:
> Bradley Taylor wrote:
>> Unfortunately, this is not reliable for major changes and doing 
>> stop/start is the only way to guarantee that code changes will be applied.
>>
>>  From the mongrel code (rails.rb, line 164):
>> # Reloads Rails.  This isn't too reliable really, but it
>> # should work for most minimal reload purposes.  The only reliable
>> # way to reload properly is to stop and then start the process.
> 
> Ah, but that's not what I'm suggesting -- a "reload" is distinct from a 
> "restart". The "reload" option for Rails under Mongrel (from a HUP 
> signal) just calls the Rails reload! method, and I understand how that 
> can/will fail.
> 
> A "restart" (from a USR2 signal) just a plain old regular stop, with the 
>   restart flag set such that once the Mongrel is stopped, it restarts.
> 
> This should nicely handle the situation in which a Mongrel might take a 
> few seconds to shutdown (thereby missing it's start oppty).
> 
> Make sense?
> 
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From schoenm at earthlink.net  Wed Apr 11 19:56:36 2007
From: schoenm at earthlink.net (Michael A. Schoen)
Date: Wed, 11 Apr 2007 16:56:36 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461D4F5B.8010208@railsmachine.com>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com>
Message-ID: <461D75B4.7090802@earthlink.net>

Bradley Taylor wrote:
> Reviewing the code (Zed correct me if I'm wrong), stop and restart both 
> call the same stop method. The graceful handling of an in-progress 
> request is the same.

Yes, and that handling works for me. The problem is that a stop;start 
fails when the stop takes a bit, whereas a stop-with-restart will always 
be just fine.

What happens now when I do a cluster restart is that some of my Mongrels 
end up just dead, as they actually stop (gracefully) after the start has 
already been called for. I could resolve this using a forced stop, but 
I'm looking for a more, not less, graceful process.

> Restart also has some funky semantics when used in a cluster where it 
> reuses the the command line arguments. This means that you can't modify 
> the cluster configuration and apply the changes with a restart. The 
> standard behavior of a linux (freebsd, etc) service is that 
> configuration changes are reread on restart (apache, mysql,etc). So for 
> the purposes of mongrel_cluster, restart == stop;start. Running a single 
> mongrel with its own configuration file would behave as expected.

Ah, so I understand why you made the change to have a cluster restart do 
a stop;start. We don't change the cluster configuration, so we aren't 
hit by that problem.

But would it be possible to get an alternative command added that does 
do an actual restart? If not, no worries, I'll hack it in on my end.


From wayneeseguin at gmail.com  Thu Apr 12 06:49:46 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Thu, 12 Apr 2007 06:49:46 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461D75B4.7090802@earthlink.net>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com>
	<461D75B4.7090802@earthlink.net>
Message-ID: <929BAB79-2A79-4112-A2C6-8D12DE24F511@gmail.com>

This may be a bit simple, but couldn't you concatenate the commands  
in a system call using either ';' (or &&), doesn't this (or both?) of  
them require that the previous command finishes before executing the  
current one?

What I'm thinking is that you can do something like:
`mongrel_rails stop... ; mongrel_rails start`
To accomplish the correct wait for the graceful stop?

I hope I'm not way off here as I just joined the discussion.

   ~Wayne

On Apr 11, 2007, at 19:56 , Michael A. Schoen wrote:

> Bradley Taylor wrote:
>> Reviewing the code (Zed correct me if I'm wrong), stop and restart  
>> both
>> call the same stop method. The graceful handling of an in-progress
>> request is the same.
>
> Yes, and that handling works for me. The problem is that a stop;start
> fails when the stop takes a bit, whereas a stop-with-restart will  
> always
> be just fine.
>
> What happens now when I do a cluster restart is that some of my  
> Mongrels
> end up just dead, as they actually stop (gracefully) after the  
> start has
> already been called for. I could resolve this using a forced stop, but
> I'm looking for a more, not less, graceful process.
>
>> Restart also has some funky semantics when used in a cluster where it
>> reuses the the command line arguments. This means that you can't  
>> modify
>> the cluster configuration and apply the changes with a restart. The
>> standard behavior of a linux (freebsd, etc) service is that
>> configuration changes are reread on restart (apache, mysql,etc).  
>> So for
>> the purposes of mongrel_cluster, restart == stop;start. Running a  
>> single
>> mongrel with its own configuration file would behave as expected.
>
> Ah, so I understand why you made the change to have a cluster  
> restart do
> a stop;start. We don't change the cluster configuration, so we aren't
> hit by that problem.
>
> But would it be possible to get an alternative command added that does
> do an actual restart? If not, no worries, I'll hack it in on my end.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From rgkaufman at gmail.com  Thu Apr 12 11:04:45 2007
From: rgkaufman at gmail.com (Rob Kaufman)
Date: Thu, 12 Apr 2007 08:04:45 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <929BAB79-2A79-4112-A2C6-8D12DE24F511@gmail.com>
References: <45FFF558.2090908@railsmachine.com>
	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>
	<461D0C20.5040009@railsmachine.com> <461D2111.6010803@earthlink.net>
	<461D2D92.5040403@railsmachine.com> <461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com> <461D75B4.7090802@earthlink.net>
	<929BAB79-2A79-4112-A2C6-8D12DE24F511@gmail.com>
Message-ID: <17112e2f0704120804k3dc540cdg27c06a32a050d1e4@mail.gmail.com>

Hi Wayne,
  Though that is a good idea in general, it doesn't get the job done
in this case.  The problem is that stop returns successfully as soon
as it sends the signal to the mongrel processes.  It goes out, says
"hey please stop what your doing" and then returns, telling you "I
told them", not "they have stopped".  It seems to me like what we need
is to have a --wait option.  The idea would be that mongrel_rails stop
--wait would not return until it had confirmed that all the processes
had truly stopped what they where doing.  It would be nice if wait
took an optional timeout argument.

  I see two benefits to this solution.  One it solves the problem
we're discussing here.  Your cluster reset could be composed of stop
--wait and start commands.  Second it will allow your system shutdown
or deployments to wait for every doggy to finish up and gracefully
return your maintenance page instead of just timing out.

Rob Kaufman


On 4/12/07, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:
> This may be a bit simple, but couldn't you concatenate the commands
> in a system call using either ';' (or &&), doesn't this (or both?) of
> them require that the previous command finishes before executing the
> current one?
>
> What I'm thinking is that you can do something like:
> `mongrel_rails stop... ; mongrel_rails start`
> To accomplish the correct wait for the graceful stop?
>
> I hope I'm not way off here as I just joined the discussion.
>
>    ~Wayne
>
> On Apr 11, 2007, at 19:56 , Michael A. Schoen wrote:
>
> > Bradley Taylor wrote:
> >> Reviewing the code (Zed correct me if I'm wrong), stop and restart
> >> both
> >> call the same stop method. The graceful handling of an in-progress
> >> request is the same.
> >
> > Yes, and that handling works for me. The problem is that a stop;start
> > fails when the stop takes a bit, whereas a stop-with-restart will
> > always
> > be just fine.
> >
> > What happens now when I do a cluster restart is that some of my
> > Mongrels
> > end up just dead, as they actually stop (gracefully) after the
> > start has
> > already been called for. I could resolve this using a forced stop, but
> > I'm looking for a more, not less, graceful process.
> >
> >> Restart also has some funky semantics when used in a cluster where it
> >> reuses the the command line arguments. This means that you can't
> >> modify
> >> the cluster configuration and apply the changes with a restart. The
> >> standard behavior of a linux (freebsd, etc) service is that
> >> configuration changes are reread on restart (apache, mysql,etc).
> >> So for
> >> the purposes of mongrel_cluster, restart == stop;start. Running a
> >> single
> >> mongrel with its own configuration file would behave as expected.
> >
> > Ah, so I understand why you made the change to have a cluster
> > restart do
> > a stop;start. We don't change the cluster configuration, so we aren't
> > hit by that problem.
> >
> > But would it be possible to get an alternative command added that does
> > do an actual restart? If not, no worries, I'll hack it in on my end.
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From wayneeseguin at gmail.com  Thu Apr 12 11:10:16 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Thu, 12 Apr 2007 11:10:16 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <17112e2f0704120804k3dc540cdg27c06a32a050d1e4@mail.gmail.com>
References: <45FFF558.2090908@railsmachine.com>
	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>
	<461D0C20.5040009@railsmachine.com>
	<461D2111.6010803@earthlink.net>
	<461D2D92.5040403@railsmachine.com>
	<461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com>
	<461D75B4.7090802@earthlink.net>
	<929BAB79-2A79-4112-A2C6-8D12DE24F511@gmail.com>
	<17112e2f0704120804k3dc540cdg27c06a32a050d1e4@mail.gmail.com>
Message-ID: <F3BE8F21-C46C-460E-B9D8-7929DDDF91A4@gmail.com>

Thanks Rob,

That makes total sense, thanks for that.

I agree that the best option seems to be to add a --wait option.

   ~Wayne

On Apr 12, 2007, at 11:04 , Rob Kaufman wrote:

> Hi Wayne,
>   Though that is a good idea in general, it doesn't get the job done
> in this case.  The problem is that stop returns successfully as soon
> as it sends the signal to the mongrel processes.  It goes out, says
> "hey please stop what your doing" and then returns, telling you "I
> told them", not "they have stopped".  It seems to me like what we need
> is to have a --wait option.  The idea would be that mongrel_rails stop
> --wait would not return until it had confirmed that all the processes
> had truly stopped what they where doing.  It would be nice if wait
> took an optional timeout argument.
>
>   I see two benefits to this solution.  One it solves the problem
> we're discussing here.  Your cluster reset could be composed of stop
> --wait and start commands.  Second it will allow your system shutdown
> or deployments to wait for every doggy to finish up and gracefully
> return your maintenance page instead of just timing out.
>
> Rob Kaufman
>
>
> On 4/12/07, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:
>> This may be a bit simple, but couldn't you concatenate the commands
>> in a system call using either ';' (or &&), doesn't this (or both?) of
>> them require that the previous command finishes before executing the
>> current one?
>>
>> What I'm thinking is that you can do something like:
>> `mongrel_rails stop... ; mongrel_rails start`
>> To accomplish the correct wait for the graceful stop?
>>
>> I hope I'm not way off here as I just joined the discussion.
>>
>>    ~Wayne
>>
>> On Apr 11, 2007, at 19:56 , Michael A. Schoen wrote:
>>
>>> Bradley Taylor wrote:
>>>> Reviewing the code (Zed correct me if I'm wrong), stop and restart
>>>> both
>>>> call the same stop method. The graceful handling of an in-progress
>>>> request is the same.
>>>
>>> Yes, and that handling works for me. The problem is that a  
>>> stop;start
>>> fails when the stop takes a bit, whereas a stop-with-restart will
>>> always
>>> be just fine.
>>>
>>> What happens now when I do a cluster restart is that some of my
>>> Mongrels
>>> end up just dead, as they actually stop (gracefully) after the
>>> start has
>>> already been called for. I could resolve this using a forced  
>>> stop, but
>>> I'm looking for a more, not less, graceful process.
>>>
>>>> Restart also has some funky semantics when used in a cluster  
>>>> where it
>>>> reuses the the command line arguments. This means that you can't
>>>> modify
>>>> the cluster configuration and apply the changes with a restart. The
>>>> standard behavior of a linux (freebsd, etc) service is that
>>>> configuration changes are reread on restart (apache, mysql,etc).
>>>> So for
>>>> the purposes of mongrel_cluster, restart == stop;start. Running a
>>>> single
>>>> mongrel with its own configuration file would behave as expected.
>>>
>>> Ah, so I understand why you made the change to have a cluster
>>> restart do
>>> a stop;start. We don't change the cluster configuration, so we  
>>> aren't
>>> hit by that problem.
>>>
>>> But would it be possible to get an alternative command added that  
>>> does
>>> do an actual restart? If not, no worries, I'll hack it in on my end.
>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From mzukowski at urbacon.net  Thu Apr 12 11:49:33 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Thu, 12 Apr 2007 11:49:33 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461D75B4.7090802@earthlink.net>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>	<461D4F5B.8010208@railsmachine.com>
	<461D75B4.7090802@earthlink.net>
Message-ID: <461E550D.5090602@urbacon.net>

Just a suggestion, but maybe the stop command should wait until all the
servers are actually down before it exits. What Michael describes below
is a fairly frustrating aspect of using mongrel_cluster. The restart
process right now kind of sucks, and I suspect that making it behave
more gracefully would make a lot of people happy.

Michael A. Schoen wrote:
> Bradley Taylor wrote:
>> Reviewing the code (Zed correct me if I'm wrong), stop and restart both 
>> call the same stop method. The graceful handling of an in-progress 
>> request is the same.
> 
> Yes, and that handling works for me. The problem is that a stop;start 
> fails when the stop takes a bit, whereas a stop-with-restart will always 
> be just fine.
> 
> What happens now when I do a cluster restart is that some of my Mongrels 
> end up just dead, as they actually stop (gracefully) after the start has 
> already been called for. I could resolve this using a forced stop, but 
> I'm looking for a more, not less, graceful process.
> 
>> Restart also has some funky semantics when used in a cluster where it 
>> reuses the the command line arguments. This means that you can't modify 
>> the cluster configuration and apply the changes with a restart. The 
>> standard behavior of a linux (freebsd, etc) service is that 
>> configuration changes are reread on restart (apache, mysql,etc). So for 
>> the purposes of mongrel_cluster, restart == stop;start. Running a single 
>> mongrel with its own configuration file would behave as expected.
> 
> Ah, so I understand why you made the change to have a cluster restart do 
> a stop;start. We don't change the cluster configuration, so we aren't 
> hit by that problem.
> 
> But would it be possible to get an alternative command added that does 
> do an actual restart? If not, no worries, I'll hack it in on my end.
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users



This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.



From schoenm at earthlink.net  Thu Apr 12 13:15:13 2007
From: schoenm at earthlink.net (Michael A. Schoen)
Date: Thu, 12 Apr 2007 10:15:13 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461E550D.5090602@urbacon.net>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>	<461D4F5B.8010208@railsmachine.com>	<461D75B4.7090802@earthlink.net>
	<461E550D.5090602@urbacon.net>
Message-ID: <461E6921.5000805@earthlink.net>

Matt Zukowski wrote:
> Just a suggestion, but maybe the stop command should wait until all the
> servers are actually down before it exits. What Michael describes below
> is a fairly frustrating aspect of using mongrel_cluster. The restart
> process right now kind of sucks, and I suspect that making it behave
> more gracefully would make a lot of people happy.

And Mongrel itself does support a more graceful restart, mongrel_cluster 
just doesn't use it at the moment. Even given the constraint that a true 
restart won't re-read the cluster config, still seems worth being 
available as an option.


From zedshaw at zedshaw.com  Thu Apr 12 13:40:28 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 12 Apr 2007 13:40:28 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461E6921.5000805@earthlink.net>
References: <45FFF558.2090908@railsmachine.com>
	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>
	<46093306.1000307@railsmachine.com>
	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>
	<461D0C20.5040009@railsmachine.com>
	<461D2111.6010803@earthlink.net>
	<461D2D92.5040403@railsmachine.com>
	<461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com>
	<461D75B4.7090802@earthlink.net> <461E550D.5090602@urbacon.net>
	<461E6921.5000805@earthlink.net>
Message-ID: <20070412134028.bb7f7750.zedshaw@zedshaw.com>

On Thu, 12 Apr 2007 10:15:13 -0700
"Michael A. Schoen" <schoenm at earthlink.net> wrote:

> Matt Zukowski wrote:
> > Just a suggestion, but maybe the stop command should wait until all the
> > servers are actually down before it exits. What Michael describes below
> > is a fairly frustrating aspect of using mongrel_cluster. The restart
> > process right now kind of sucks, and I suspect that making it behave
> > more gracefully would make a lot of people happy.
> 
> And Mongrel itself does support a more graceful restart, mongrel_cluster 
> just doesn't use it at the moment. Even given the constraint that a true 
> restart won't re-read the cluster config, still seems worth being 
> available as an option.

I think I'm going to say, no, you don't get this in mongrel_cluster.
When we had it there were way too many problems because how Rails does
this kind of soft restart isn't very clear.  It's basically a bunch of
black magic ruby that reloads all the stuff like in debug mode.  That
also means that it doesn't work with modules and systems that are
outside of rails.  For example, you can't hook into this restart
process so that you can properly close connections to Jabber servers.

This lead to people having weird problems like Mongrel not actually
restarting and memory leaks.  Of course, they don't blame Rails or the
plugin they're using, they blame Mongrel.  In order to keep the support
problems to a minimum, we just stop the server and restart.

What's wrong with that for people?  Apparently you all need constant
and completely available up-time for your web applications.  Great.
You can't get this from Mongrel, or from Rails, you need to look
outside at your proxy server, network architecture, and other sources.

However, you do have access to it.  Every time mongrel starts up it
tells you what posix signals cause what actions.  If you want a
graceful restart and you know it will work then you just hit your
mongrels with that signal.

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

From rm_mongrel at cheapcomplexdevices.com  Thu Apr 12 14:03:36 2007
From: rm_mongrel at cheapcomplexdevices.com (rm_mongrel at cheapcomplexdevices.com)
Date: Thu, 12 Apr 2007 11:03:36 -0700 (PDT)
Subject: [Mongrel] What's mongrel doing when it's idle.
Message-ID: <Pine.LNX.4.64.0704121055050.23099@rondesktop.cheapcomplexdevices.com>


A totally idle mongrel seems to wake up about once a second doing
a little stuff like:
   select(4, [3], [], [], {0, 999696})     = 0 (Timeout)
   gettimeofday({1176400534, 112594}, NULL) = 0
   select(4, [3], [], [], {0, 0})          = 0 (Timeout)
   time(NULL)                              = 1176400534
   time(NULL)                              = 1176400534
   gettimeofday({1176400534, 113841}, NULL) = 0
   gettimeofday({1176400534, 114138}, NULL) = 0
over and over.

I realize it's not a big deal to do so little so infrequently; but 
wondering why it wakes up to do anything at all.    Any reason
whatever it's polling for can't just be added to the select()
conditions?


I only noticed because on an extremely overloaded server (I have dozens of 
virtual machines running on a box here and memory on each is limited and 
each are running quite a few web servers) I was mildly surprised to see 
that the mongrel tasks didn't get swapped out completely.  The waking up 
once a second is probably why.

    Ron

PS: Equally curious to me as that irb seems to wake up a few times a 
second too; but that's less of a concern because I don't leave irbs 
running on purpose.

From schoenm at earthlink.net  Thu Apr 12 14:52:26 2007
From: schoenm at earthlink.net (Michael A. Schoen)
Date: Thu, 12 Apr 2007 11:52:26 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <20070412134028.bb7f7750.zedshaw@zedshaw.com>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>	<461D4F5B.8010208@railsmachine.com>	<461D75B4.7090802@earthlink.net>
	<461E550D.5090602@urbacon.net>	<461E6921.5000805@earthlink.net>
	<20070412134028.bb7f7750.zedshaw@zedshaw.com>
Message-ID: <461E7FEA.3010809@earthlink.net>

Zed A. Shaw wrote:
> I think I'm going to say, no, you don't get this in mongrel_cluster.
> When we had it there were way too many problems because how Rails does
> this kind of soft restart isn't very clear.  It's basically a bunch of
> black magic ruby that reloads all the stuff like in debug mode.  That

Am I misreading the code? I'm not talking about the HUP/reload stuff. 
I'm talking about the plain old regular Mongrel restart, which, from 
what I can tell, is a regular stop, with the restart flag set to true, 
such that it starts right back up again. No reloading of any Rails magic.


From mzukowski at urbacon.net  Thu Apr 12 15:00:31 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Thu, 12 Apr 2007 15:00:31 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <20070412134028.bb7f7750.zedshaw@zedshaw.com>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>	<461D4F5B.8010208@railsmachine.com>	<461D75B4.7090802@earthlink.net>
	<461E550D.5090602@urbacon.net>	<461E6921.5000805@earthlink.net>
	<20070412134028.bb7f7750.zedshaw@zedshaw.com>
Message-ID: <461E81CF.7050905@urbacon.net>

For me at least the issue isn't so much constant and complete
availability... It's that the "restart" command in mongrel_cluster
basically doesn't work. After stopping, it tires to start without
waiting for the servers to shut down. Most of the time this fails, as
the old servers are still shutting down.

Instead I find myself doing a manual 'stop', then ps'ing repeatedly to
see if all the servers have shut down, and then starting manually.

Zed A. Shaw wrote:
> On Thu, 12 Apr 2007 10:15:13 -0700
> "Michael A. Schoen" <schoenm at earthlink.net> wrote:
> 
>> Matt Zukowski wrote:
>>> Just a suggestion, but maybe the stop command should wait until all the
>>> servers are actually down before it exits. What Michael describes below
>>> is a fairly frustrating aspect of using mongrel_cluster. The restart
>>> process right now kind of sucks, and I suspect that making it behave
>>> more gracefully would make a lot of people happy.
>> And Mongrel itself does support a more graceful restart, mongrel_cluster 
>> just doesn't use it at the moment. Even given the constraint that a true 
>> restart won't re-read the cluster config, still seems worth being 
>> available as an option.
> 
> I think I'm going to say, no, you don't get this in mongrel_cluster.
> When we had it there were way too many problems because how Rails does
> this kind of soft restart isn't very clear.  It's basically a bunch of
> black magic ruby that reloads all the stuff like in debug mode.  That
> also means that it doesn't work with modules and systems that are
> outside of rails.  For example, you can't hook into this restart
> process so that you can properly close connections to Jabber servers.
> 
> This lead to people having weird problems like Mongrel not actually
> restarting and memory leaks.  Of course, they don't blame Rails or the
> plugin they're using, they blame Mongrel.  In order to keep the support
> problems to a minimum, we just stop the server and restart.
> 
> What's wrong with that for people?  Apparently you all need constant
> and completely available up-time for your web applications.  Great.
> You can't get this from Mongrel, or from Rails, you need to look
> outside at your proxy server, network architecture, and other sources.
> 
> However, you do have access to it.  Every time mongrel starts up it
> tells you what posix signals cause what actions.  If you want a
> graceful restart and you know it will work then you just hit your
> mongrels with that signal.
> 



This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.



From jamesludlow at gmail.com  Thu Apr 12 15:23:38 2007
From: jamesludlow at gmail.com (JDL)
Date: Thu, 12 Apr 2007 14:23:38 -0500
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461E81CF.7050905@urbacon.net>
References: <45FFF558.2090908@railsmachine.com>
	<461D2111.6010803@earthlink.net> <461D2D92.5040403@railsmachine.com>
	<461D353D.2060302@earthlink.net> <461D4F5B.8010208@railsmachine.com>
	<461D75B4.7090802@earthlink.net> <461E550D.5090602@urbacon.net>
	<461E6921.5000805@earthlink.net>
	<20070412134028.bb7f7750.zedshaw@zedshaw.com>
	<461E81CF.7050905@urbacon.net>
Message-ID: <b157956e0704121223ucd9b4fcsc6e99402caa64e85@mail.gmail.com>

On 4/12/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
> For me at least the issue isn't so much constant and complete
> availability... It's that the "restart" command in mongrel_cluster
> basically doesn't work. After stopping, it tires to start without
> waiting for the servers to shut down. Most of the time this fails, as
> the old servers are still shutting down.
>
> Instead I find myself doing a manual 'stop', then ps'ing repeatedly to
> see if all the servers have shut down, and then starting manually.

I have a server where I do the same thing.  I know it's stupid to do
it manually, but I keep telling myself that it'll get fixed in
mongrel_cluster eventually, and thankfully I rarely ever have to do a
restart anyway.

1. cap deploy
2. code is loaded, servers start to shutdown
3. shutdown is "complete" but not all mongrels are really done.
4. start is issued
5. watch the PID errors blow by
6. manually shut all of the mongrel processes down
7. manually start mongrel_cluster again

This isn't exactly ruining my life, but it's annoying.  A step 3.5
that said "Hey, let's wait until the servers are actually stopped"
would be super cool.

-- James

From carl.lerche at gmail.com  Thu Apr 12 15:28:55 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Thu, 12 Apr 2007 12:28:55 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461E81CF.7050905@urbacon.net>
References: <45FFF558.2090908@railsmachine.com>
	<461D2111.6010803@earthlink.net> <461D2D92.5040403@railsmachine.com>
	<461D353D.2060302@earthlink.net> <461D4F5B.8010208@railsmachine.com>
	<461D75B4.7090802@earthlink.net> <461E550D.5090602@urbacon.net>
	<461E6921.5000805@earthlink.net>
	<20070412134028.bb7f7750.zedshaw@zedshaw.com>
	<461E81CF.7050905@urbacon.net>
Message-ID: <ab90312e0704121228o64bd2e8arf88ac80aa4ccd653@mail.gmail.com>

Yes, I have the same problem. On high traffic apps, mongrel cluster's
restart will fail pretty consistently (for the reasons stated above).
A --wait option seems like a reasonable solution.

-carl

On 4/12/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
> For me at least the issue isn't so much constant and complete
> availability... It's that the "restart" command in mongrel_cluster
> basically doesn't work. After stopping, it tires to start without
> waiting for the servers to shut down. Most of the time this fails, as
> the old servers are still shutting down.
>
> Instead I find myself doing a manual 'stop', then ps'ing repeatedly to
> see if all the servers have shut down, and then starting manually.
>
> Zed A. Shaw wrote:
> > On Thu, 12 Apr 2007 10:15:13 -0700
> > "Michael A. Schoen" <schoenm at earthlink.net> wrote:
> >
> >> Matt Zukowski wrote:
> >>> Just a suggestion, but maybe the stop command should wait until all the
> >>> servers are actually down before it exits. What Michael describes below
> >>> is a fairly frustrating aspect of using mongrel_cluster. The restart
> >>> process right now kind of sucks, and I suspect that making it behave
> >>> more gracefully would make a lot of people happy.
> >> And Mongrel itself does support a more graceful restart, mongrel_cluster
> >> just doesn't use it at the moment. Even given the constraint that a true
> >> restart won't re-read the cluster config, still seems worth being
> >> available as an option.
> >
> > I think I'm going to say, no, you don't get this in mongrel_cluster.
> > When we had it there were way too many problems because how Rails does
> > this kind of soft restart isn't very clear.  It's basically a bunch of
> > black magic ruby that reloads all the stuff like in debug mode.  That
> > also means that it doesn't work with modules and systems that are
> > outside of rails.  For example, you can't hook into this restart
> > process so that you can properly close connections to Jabber servers.
> >
> > This lead to people having weird problems like Mongrel not actually
> > restarting and memory leaks.  Of course, they don't blame Rails or the
> > plugin they're using, they blame Mongrel.  In order to keep the support
> > problems to a minimum, we just stop the server and restart.
> >
> > What's wrong with that for people?  Apparently you all need constant
> > and completely available up-time for your web applications.  Great.
> > You can't get this from Mongrel, or from Rails, you need to look
> > outside at your proxy server, network architecture, and other sources.
> >
> > However, you do have access to it.  Every time mongrel starts up it
> > tells you what posix signals cause what actions.  If you want a
> > graceful restart and you know it will work then you just hit your
> > mongrels with that signal.
> >
>
>
>
> This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited.
> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


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

From zedshaw at zedshaw.com  Thu Apr 12 15:53:48 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 12 Apr 2007 15:53:48 -0400
Subject: [Mongrel] What's mongrel doing when it's idle.
In-Reply-To: <Pine.LNX.4.64.0704121055050.23099@rondesktop.cheapcomplexdevices.com>
References: <Pine.LNX.4.64.0704121055050.23099@rondesktop.cheapcomplexdevices.com>
Message-ID: <20070412155348.aa4d3cb9.zedshaw@zedshaw.com>

On Thu, 12 Apr 2007 11:03:36 -0700 (PDT)
rm_mongrel at cheapcomplexdevices.com wrote:

> 
> A totally idle mongrel seems to wake up about once a second doing
> a little stuff like:
>    select(4, [3], [], [], {0, 999696})     = 0 (Timeout)
>    gettimeofday({1176400534, 112594}, NULL) = 0
>    select(4, [3], [], [], {0, 0})          = 0 (Timeout)
>    time(NULL)                              = 1176400534
>    time(NULL)                              = 1176400534
>    gettimeofday({1176400534, 113841}, NULL) = 0
>    gettimeofday({1176400534, 114138}, NULL) = 0
> over and over.
> 
> I realize it's not a big deal to do so little so infrequently; but 
> wondering why it wakes up to do anything at all.    Any reason
> whatever it's polling for can't just be added to the select()
> conditions?

Ruby uses select() to do it's IO processing and thread control, but
only after you start one thread.

Ruby doesn't put a timeout parameter into the select call unless
there's a thread sleeping.

If you have threads waiting for IO, and have someone running Mongrel
from the console, and you don't have a thread calling sleep once a
second, then...

CTRL-C won't exit the process on most systems.

So, most ruby code that uses threads throws in a bogus sleeping thread
that doesn't do much.

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

From bradley at railsmachine.com  Thu Apr 12 16:07:34 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Thu, 12 Apr 2007 16:07:34 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <ab90312e0704121228o64bd2e8arf88ac80aa4ccd653@mail.gmail.com>
References: <45FFF558.2090908@railsmachine.com>	<461D2111.6010803@earthlink.net>
	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com>	<461D75B4.7090802@earthlink.net>
	<461E550D.5090602@urbacon.net>	<461E6921.5000805@earthlink.net>	<20070412134028.bb7f7750.zedshaw@zedshaw.com>	<461E81CF.7050905@urbacon.net>
	<ab90312e0704121228o64bd2e8arf88ac80aa4ccd653@mail.gmail.com>
Message-ID: <461E9186.8060405@railsmachine.com>

mongrel_rails stop accepts a --wait argument. If I add that to 
mongrel_cluster, will it solve these issues?

Bradley

Carl Lerche wrote:
> Yes, I have the same problem. On high traffic apps, mongrel cluster's
> restart will fail pretty consistently (for the reasons stated above).
> A --wait option seems like a reasonable solution.
> 
> -carl
> 
> On 4/12/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
>> For me at least the issue isn't so much constant and complete
>> availability... It's that the "restart" command in mongrel_cluster
>> basically doesn't work. After stopping, it tires to start without
>> waiting for the servers to shut down. Most of the time this fails, as
>> the old servers are still shutting down.
>>
>> Instead I find myself doing a manual 'stop', then ps'ing repeatedly to
>> see if all the servers have shut down, and then starting manually.
>>
>> Zed A. Shaw wrote:
>>> On Thu, 12 Apr 2007 10:15:13 -0700
>>> "Michael A. Schoen" <schoenm at earthlink.net> wrote:
>>>
>>>> Matt Zukowski wrote:
>>>>> Just a suggestion, but maybe the stop command should wait until all the
>>>>> servers are actually down before it exits. What Michael describes below
>>>>> is a fairly frustrating aspect of using mongrel_cluster. The restart
>>>>> process right now kind of sucks, and I suspect that making it behave
>>>>> more gracefully would make a lot of people happy.
>>>> And Mongrel itself does support a more graceful restart, mongrel_cluster
>>>> just doesn't use it at the moment. Even given the constraint that a true
>>>> restart won't re-read the cluster config, still seems worth being
>>>> available as an option.
>>> I think I'm going to say, no, you don't get this in mongrel_cluster.
>>> When we had it there were way too many problems because how Rails does
>>> this kind of soft restart isn't very clear.  It's basically a bunch of
>>> black magic ruby that reloads all the stuff like in debug mode.  That
>>> also means that it doesn't work with modules and systems that are
>>> outside of rails.  For example, you can't hook into this restart
>>> process so that you can properly close connections to Jabber servers.
>>>
>>> This lead to people having weird problems like Mongrel not actually
>>> restarting and memory leaks.  Of course, they don't blame Rails or the
>>> plugin they're using, they blame Mongrel.  In order to keep the support
>>> problems to a minimum, we just stop the server and restart.
>>>
>>> What's wrong with that for people?  Apparently you all need constant
>>> and completely available up-time for your web applications.  Great.
>>> You can't get this from Mongrel, or from Rails, you need to look
>>> outside at your proxy server, network architecture, and other sources.
>>>
>>> However, you do have access to it.  Every time mongrel starts up it
>>> tells you what posix signals cause what actions.  If you want a
>>> graceful restart and you know it will work then you just hit your
>>> mongrels with that signal.
>>>
>>
>>
>> This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited.
>> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.
>>
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> 
> 


From schoenm at earthlink.net  Thu Apr 12 16:35:06 2007
From: schoenm at earthlink.net (Michael A. Schoen)
Date: Thu, 12 Apr 2007 13:35:06 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461E9186.8060405@railsmachine.com>
References: <45FFF558.2090908@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>	<461D4F5B.8010208@railsmachine.com>	<461D75B4.7090802@earthlink.net>	<461E550D.5090602@urbacon.net>	<461E6921.5000805@earthlink.net>	<20070412134028.bb7f7750.zedshaw@zedshaw.com>	<461E81CF.7050905@urbacon.net>	<ab90312e0704121228o64bd2e8arf88ac80aa4ccd653@mail.gmail.com>
	<461E9186.8060405@railsmachine.com>
Message-ID: <461E97FA.70308@earthlink.net>

Bradley Taylor wrote:
> mongrel_rails stop accepts a --wait argument. If I add that to 
> mongrel_cluster, will it solve these issues?

Not for me I don't think. Again, I may be misreading it, but that --wait 
argument just looks like it literally waits, then does a hard kill. I 
would have expected that option to send a TERM, then wait up to @wait 
seconds for it to go away, and do a KILL if it was still there. If that 
were the implementation it sounds like it would work for most folks.

I'm really just looking for the ability to do a restart, ie., a graceful 
stop following by an automatic (within Mongrel) start.


From ezmobius at gmail.com  Thu Apr 12 16:43:27 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Thu, 12 Apr 2007 13:43:27 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461E97FA.70308@earthlink.net>
References: <45FFF558.2090908@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>	<461D4F5B.8010208@railsmachine.com>	<461D75B4.7090802@earthlink.net>	<461E550D.5090602@urbacon.net>	<461E6921.5000805@earthlink.net>	<20070412134028.bb7f7750.zedshaw@zedshaw.com>	<461E81CF.7050905@urbacon.net>	<ab90312e0704121228o64bd2e8arf88ac80aa4ccd653@mail.gmail.com>
	<461E9186.8060405@railsmachine.com> <461E97FA.70308@earthlink.net>
Message-ID: <D326E0A5-146C-4A8D-816E-850AD8614117@gmail.com>


On Apr 12, 2007, at 1:35 PM, Michael A. Schoen wrote:

> Bradley Taylor wrote:
>> mongrel_rails stop accepts a --wait argument. If I add that to
>> mongrel_cluster, will it solve these issues?
>
> Not for me I don't think. Again, I may be misreading it, but that -- 
> wait
> argument just looks like it literally waits, then does a hard kill. I
> would have expected that option to send a TERM, then wait up to @wait
> seconds for it to go away, and do a KILL if it was still there. If  
> that
> were the implementation it sounds like it would work for most folks.
>
> I'm really just looking for the ability to do a restart, ie., a  
> graceful
> stop following by an automatic (within Mongrel) start.


	You can accomplish gracefull mongrel cluster restarts with monit.  
using cluster::stop and cluster::start in the start/stop programs.  
Set a 'mongrel' group in the monit config and then use this for the  
restart task:

$ sudo monit restart all -g mongrel

	That will do each mongrel one at a time and it will make sure they  
stop and get started again, avoiding the issue of starting a new  
mongrel on the same port before the other one finishes. This is what  
works best for me.

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




check process mongrel_<%= @username %>_5000
   with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/<% 
= @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=  
@username %>/current/config/mongrel_cluster.yml --clean --only 5000"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_<%= @username %>_5001
   with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/<% 
= @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=  
@username %>/current/config/mongrel_cluster.yml --clean --only 5001"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_<%= @username %>_5002
   with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/<% 
= @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=  
@username %>/current/config/mongrel_cluster.yml --clean --only 5002"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

From zedshaw at zedshaw.com  Thu Apr 12 17:20:25 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 12 Apr 2007 17:20:25 -0400
Subject: [Mongrel] OHHHHHHHHHHHH!!!! Re: [ANN] Another mongrel_cluster
 prerelease 1.0.1.1
In-Reply-To: <461E7FEA.3010809@earthlink.net>
References: <45FFF558.2090908@railsmachine.com>
	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>
	<46093306.1000307@railsmachine.com>
	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>
	<461D0C20.5040009@railsmachine.com>
	<461D2111.6010803@earthlink.net>
	<461D2D92.5040403@railsmachine.com>
	<461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com>
	<461D75B4.7090802@earthlink.net> <461E550D.5090602@urbacon.net>
	<461E6921.5000805@earthlink.net>
	<20070412134028.bb7f7750.zedshaw@zedshaw.com>
	<461E7FEA.3010809@earthlink.net>
Message-ID: <20070412172025.0d53ef2e.zedshaw@zedshaw.com>

On Thu, 12 Apr 2007 11:52:26 -0700
"Michael A. Schoen" <schoenm at earthlink.net> wrote:

> Zed A. Shaw wrote:
> > I think I'm going to say, no, you don't get this in mongrel_cluster.
> > When we had it there were way too many problems because how Rails does
> > this kind of soft restart isn't very clear.  It's basically a bunch of
> > black magic ruby that reloads all the stuff like in debug mode.  That
> 
> Am I misreading the code? I'm not talking about the HUP/reload stuff. 
> I'm talking about the plain old regular Mongrel restart, which, from 
> what I can tell, is a regular stop, with the restart flag set to true, 
> such that it starts right back up again. No reloading of any Rails magic.

Ok, ok, ok, NOW we get it.  The problem was that mongrel_cluster was
calling start/stop on the Mongrel because of issues with the capistrano
symlinks from back in the day.  Now what we'll do is the following
change to mongrel_cluster:

1) When you do cluster::restart it sends the mongrel processes a USR2
signal.  This is the signal that tells mongrel to stop everything, wait
until that's done, then re-run the start command again.
	*** NOTE: If you change your mongrel_cluster config you'll have
to use start/stop.
2) When you do cluster::stop it sends TERM to do the stop.  THIS will
not wait, so if you're doing this and need to wait then use the
mongrel.log and ps manually.
3) When you do cluster::start, it will try to start.  It's on you to
handle this manually.

Everyone with this problem currently can very simply do the following
when they need the super graceful USR2:

  killall -USR2 mongrel_rails

That will usually work on most linux systems, people on other systems
can probably come up with their quick fix.

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

From luislavena at gmail.com  Thu Apr 12 17:25:00 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 12 Apr 2007 18:25:00 -0300
Subject: [Mongrel] OHHHHHHHHHHHH!!!! Re: [ANN] Another mongrel_cluster
	prerelease 1.0.1.1
In-Reply-To: <20070412172025.0d53ef2e.zedshaw@zedshaw.com>
References: <45FFF558.2090908@railsmachine.com>
	<461D2D92.5040403@railsmachine.com> <461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com> <461D75B4.7090802@earthlink.net>
	<461E550D.5090602@urbacon.net> <461E6921.5000805@earthlink.net>
	<20070412134028.bb7f7750.zedshaw@zedshaw.com>
	<461E7FEA.3010809@earthlink.net>
	<20070412172025.0d53ef2e.zedshaw@zedshaw.com>
Message-ID: <71166b3b0704121425x621438feh356a990fc206cfd1@mail.gmail.com>

On 4/12/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:

[... snipped lots of ramblings about HUP, USR2, restart, stop, start,
restart...]

>
> Everyone with this problem currently can very simply do the following
> when they need the super graceful USR2:
>
>   killall -USR2 mongrel_rails
>
> That will usually work on most linux systems, people on other systems
> can probably come up with their quick fix.
>

Thank God I'm on Windows ;-)

BTW, Zed, we need to talk, could you during the weekend? (I know,
you're a busy guy).

-- 
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  Thu Apr 12 17:33:20 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 12 Apr 2007 17:33:20 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461E81CF.7050905@urbacon.net>
References: <45FFF558.2090908@railsmachine.com>
	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>
	<46093306.1000307@railsmachine.com>
	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>
	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>
	<461D0C20.5040009@railsmachine.com>
	<461D2111.6010803@earthlink.net>
	<461D2D92.5040403@railsmachine.com>
	<461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com>
	<461D75B4.7090802@earthlink.net> <461E550D.5090602@urbacon.net>
	<461E6921.5000805@earthlink.net>
	<20070412134028.bb7f7750.zedshaw@zedshaw.com>
	<461E81CF.7050905@urbacon.net>
Message-ID: <20070412173320.e5cdb639.zedshaw@zedshaw.com>

On Thu, 12 Apr 2007 15:00:31 -0400
Matt Zukowski <mzukowski at urbacon.net> wrote:

> For me at least the issue isn't so much constant and complete
> availability... It's that the "restart" command in mongrel_cluster
> basically doesn't work. After stopping, it tires to start without
> waiting for the servers to shut down. Most of the time this fails, as
> the old servers are still shutting down.
> 
> Instead I find myself doing a manual 'stop', then ps'ing repeatedly to
> see if all the servers have shut down, and then starting manually.

Matt, yep, we just figured out what everyone was talking about.

Try this:

killall -USR2 mongrel_rails and it'll do a stop/wait/restart.

Next version of mongrel_cluster will just do that.

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

From zedshaw at zedshaw.com  Thu Apr 12 17:35:09 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Thu, 12 Apr 2007 17:35:09 -0400
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461E97FA.70308@earthlink.net>
References: <45FFF558.2090908@railsmachine.com>
	<461D2111.6010803@earthlink.net>
	<461D2D92.5040403@railsmachine.com>
	<461D353D.2060302@earthlink.net>
	<461D4F5B.8010208@railsmachine.com>
	<461D75B4.7090802@earthlink.net> <461E550D.5090602@urbacon.net>
	<461E6921.5000805@earthlink.net>
	<20070412134028.bb7f7750.zedshaw@zedshaw.com>
	<461E81CF.7050905@urbacon.net>
	<ab90312e0704121228o64bd2e8arf88ac80aa4ccd653@mail.gmail.com>
	<461E9186.8060405@railsmachine.com> <461E97FA.70308@earthlink.net>
Message-ID: <20070412173509.90800bb5.zedshaw@zedshaw.com>

On Thu, 12 Apr 2007 13:35:06 -0700
"Michael A. Schoen" <schoenm at earthlink.net> wrote:

> Bradley Taylor wrote:
> > mongrel_rails stop accepts a --wait argument. If I add that to 
> > mongrel_cluster, will it solve these issues?
> 
> Not for me I don't think. Again, I may be misreading it, but that --wait 
> argument just looks like it literally waits, then does a hard kill. I 
> would have expected that option to send a TERM, then wait up to @wait 
> seconds for it to go away, and do a KILL if it was still there. If that 
> were the implementation it sounds like it would work for most folks.

Michael,

Try running:

killall -USR2 mongrel_rails

and see if that works the way you expect it to work.  That's the signal
to tell Mongrel to do a stop/wait/start process (the real restart).

Next version of mongrel_cluster will just do this.

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

From schoenm at earthlink.net  Thu Apr 12 18:16:46 2007
From: schoenm at earthlink.net (Michael A. Schoen)
Date: Thu, 12 Apr 2007 15:16:46 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <20070412173509.90800bb5.zedshaw@zedshaw.com>
References: <45FFF558.2090908@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>	<461D4F5B.8010208@railsmachine.com>	<461D75B4.7090802@earthlink.net>
	<461E550D.5090602@urbacon.net>	<461E6921.5000805@earthlink.net>	<20070412134028.bb7f7750.zedshaw@zedshaw.com>	<461E81CF.7050905@urbacon.net>	<ab90312e0704121228o64bd2e8arf88ac80aa4ccd653@mail.gmail.com>	<461E9186.8060405@railsmachine.com>
	<461E97FA.70308@earthlink.net>
	<20070412173509.90800bb5.zedshaw@zedshaw.com>
Message-ID: <461EAFCE.5040707@earthlink.net>

Zed A. Shaw wrote:
> Try running:
> 
> killall -USR2 mongrel_rails
> 
> and see if that works the way you expect it to work.  That's the signal
> to tell Mongrel to do a stop/wait/start process (the real restart).
> 
> Next version of mongrel_cluster will just do this.

Perfect, thanks, exactly what I was looking for. Sorry for not being 
clear enough about this upfront.



From bradley at railsmachine.com  Thu Apr 12 19:45:57 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Thu, 12 Apr 2007 19:45:57 -0400
Subject: [Mongrel] OHHHHHHHHHHHH!!!! Re: [ANN] Another mongrel_cluster
 prerelease 1.0.1.1
In-Reply-To: <20070412172025.0d53ef2e.zedshaw@zedshaw.com>
References: <45FFF558.2090908@railsmachine.com>	<182D222C-1556-4580-B3DD-2B0AB4C63F48@flydown.org>	<46093306.1000307@railsmachine.com>	<ab90312e0703270901i6f44be3as8d199239af8f1b8b@mail.gmail.com>	<ab90312e0703270959nac8dcffgd380ee2a1d066607@mail.gmail.com>	<461D0C20.5040009@railsmachine.com>	<461D2111.6010803@earthlink.net>	<461D2D92.5040403@railsmachine.com>	<461D353D.2060302@earthlink.net>	<461D4F5B.8010208@railsmachine.com>	<461D75B4.7090802@earthlink.net>
	<461E550D.5090602@urbacon.net>	<461E6921.5000805@earthlink.net>	<20070412134028.bb7f7750.zedshaw@zedshaw.com>	<461E7FEA.3010809@earthlink.net>
	<20070412172025.0d53ef2e.zedshaw@zedshaw.com>
Message-ID: <461EC4B5.70504@railsmachine.com>

Zed A. Shaw wrote:

> 1) When you do cluster::restart it sends the mongrel processes a USR2
> signal.  This is the signal that tells mongrel to stop everything, wait
> until that's done, then re-run the start command again.
> 	*** NOTE: If you change your mongrel_cluster config you'll have
> to use start/stop.

I'm not big on breaking the existing semantics of cluster::restart. It 
should be possible to support reloading the configuration file via some 
kind of shadow mongrel_rails file. I will investigate...


Bradley

From rgkaufman at gmail.com  Fri Apr 13 01:23:53 2007
From: rgkaufman at gmail.com (Rob Kaufman)
Date: Thu, 12 Apr 2007 22:23:53 -0700
Subject: [Mongrel] [ANN] Another mongrel_cluster prerelease 1.0.1.1
In-Reply-To: <461EAFCE.5040707@earthlink.net>
References: <45FFF558.2090908@railsmachine.com> <461E550D.5090602@urbacon.net>
	<461E6921.5000805@earthlink.net>
	<20070412134028.bb7f7750.zedshaw@zedshaw.com>
	<461E81CF.7050905@urbacon.net>
	<ab90312e0704121228o64bd2e8arf88ac80aa4ccd653@mail.gmail.com>
	<461E9186.8060405@railsmachine.com> <461E97FA.70308@earthlink.net>
	<20070412173509.90800bb5.zedshaw@zedshaw.com>
	<461EAFCE.5040707@earthlink.net>
Message-ID: <17112e2f0704122223o6dce8c68sa10851e39f54f3c6@mail.gmail.com>

Thanks Zed,
  That sounds like an awesome solution.  Not that anyone who has been
around here long should be surprised when you come to the rescue

Rob Kaufman

On 4/12/07, Michael A. Schoen <schoenm at earthlink.net> wrote:
> Zed A. Shaw wrote:
> > Try running:
> >
> > killall -USR2 mongrel_rails
> >
> > and see if that works the way you expect it to work.  That's the signal
> > to tell Mongrel to do a stop/wait/start process (the real restart).
> >
> > Next version of mongrel_cluster will just do this.
>
> Perfect, thanks, exactly what I was looking for. Sorry for not being
> clear enough about this upfront.
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From azifali at gmail.com  Fri Apr 13 08:42:01 2007
From: azifali at gmail.com (Asif Ali)
Date: Fri, 13 Apr 2007 18:12:01 +0530
Subject: [Mongrel] mongrel on linux error - custom_require.rb:27:in
	`gem_original_require': no such file to load -- (LoadErro
Message-ID: <52d8feb90704130542o15082930j25f90fe1530514e2@mail.gmail.com>

We're deploying mongrel with Apache on CentOS.

I have installed mongrel but when I try to run it, I get the following
error.

Can someone tell my why and how to fix it. Also does anyone have experience
in deploying mongrel on CentOS ?

mongrel_rails start -d
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- (LoadError)
        from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from /usr/lib/ruby/gems/1.8/gems/mongrel_service-0.1
/lib/mongrel_service/init.rb:5
        from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.2/lib/gem_plugin.rb:134:in
`load'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:142:in
`each'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:142:in
`each'
        from /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.2/lib/gem_plugin.rb:112:in
`load'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:240
        from /usr/bin/mongrel_rails:18:in `load'
        from /usr/bin/mongrel_rails:18


Thanks in Advance.

Dude
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070413/150b2931/attachment.html 

From wayneeseguin at gmail.com  Fri Apr 13 08:48:53 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Fri, 13 Apr 2007 08:48:53 -0400
Subject: [Mongrel] mongrel on linux error - custom_require.rb:27:in
	`gem_original_require': no such file to load -- (LoadErro
In-Reply-To: <52d8feb90704130542o15082930j25f90fe1530514e2@mail.gmail.com>
References: <52d8feb90704130542o15082930j25f90fe1530514e2@mail.gmail.com>
Message-ID: <4CCE482E-2303-43BA-8B6B-D1B3DE2B95A8@gmail.com>

You're missing a gem.
Did you install fastthread?

   ~Wayne

On Apr 13, 2007, at 08:42 , Asif Ali wrote:
> We're deploying mongrel with Apache on CentOS.
>
> I have installed mongrel but when I try to run it, I get the  
> following error.
>
> Can someone tell my why and how to fix it. Also does anyone have  
> experience in deploying mongrel on CentOS ?
>
> mongrel_rails start -d
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in  
> `gem_original_require': no such file to load -- (LoadError)
>         from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: 
> 27:in `require'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel_service-0.1/lib/ 
> mongrel_service/init.rb:5
>         from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: 
> 27:in `gem_original_require'
>         from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: 
> 27:in `require'
>         from /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.2/lib/ 
> gem_plugin.rb:134:in `load'
>         from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb: 
> 142:in `each'
>         from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb: 
> 142:in `each'
>         from /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.2/lib/ 
> gem_plugin.rb:112:in `load'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:240
>         from /usr/bin/mongrel_rails:18:in `load'
>         from /usr/bin/mongrel_rails:18
>
>
> Thanks in Advance.
>
> Dude
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From azifali at gmail.com  Fri Apr 13 14:21:06 2007
From: azifali at gmail.com (Asif Ali)
Date: Fri, 13 Apr 2007 23:51:06 +0530
Subject: [Mongrel] mongrel on linux error
Message-ID: <52d8feb90704131121j11005e1due8ca1592ead0b0e9@mail.gmail.com>

We're deploying mongrel with Apache on CentOS.

I have installed mongrel but when I try to run it, I get the following
error.

Can someone tell my why and how to fix it. Also does anyone have experience
in deploying mongrel on CentOS ?

mongrel_rails start -d
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- (LoadError)
        from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from /usr/lib/ruby/gems/1.8/gems/mongrel_service-0.1
/lib/mongrel_service/init.rb:5
        from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.2/lib/gem_plugin.rb:134:in
`load'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:142:in
`each'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:142:in
`each'
        from /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.2/lib/gem_plugin.rb:112:in
`load'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:240
        from /usr/bin/mongrel_rails:18:in `load'
        from /usr/bin/mongrel_rails:18


Thanks in Advance.

Dude
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070413/1ec7c323/attachment-0001.html 

From eimorton at gmail.com  Sun Apr 15 16:04:06 2007
From: eimorton at gmail.com (Erik Morton)
Date: Sun, 15 Apr 2007 16:04:06 -0400
Subject: [Mongrel] Ferret and Mongrel. OSX vs. Linux
Message-ID: <F20B8CCF-DDE2-417D-985E-0C9A5C9B73B2@gmail.com>

I'm having a strange problem accessing a 1.7GB Ferret index from  
within Mongrel (1.0.1) on Linux. On OSX a Ferret search through Rails  
takes a fraction of a second. From the command line, bypassing  
Mongrel, the search takes about the same amount of time. On Fedora  
Core 4 a Ferret search from the command line takes a fraction of a  
second, but the same search through Mongrel never returns. The  
mongrel just spins and using 50% or so of the CPU.

Has anyone seen anything like this? Is there some kind of limit on  
the size of a file that Mongrel allows Rails to access in Linux? Help  
is greatly appreciated. I had no problem on Linux searching a Ferret  
index of about 1.5GB.

Erik

From zedshaw at zedshaw.com  Sun Apr 15 19:06:57 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Sun, 15 Apr 2007 19:06:57 -0400
Subject: [Mongrel] Ferret and Mongrel. OSX vs. Linux
In-Reply-To: <F20B8CCF-DDE2-417D-985E-0C9A5C9B73B2@gmail.com>
References: <F20B8CCF-DDE2-417D-985E-0C9A5C9B73B2@gmail.com>
Message-ID: <20070415190657.b9bfaef6.zedshaw@zedshaw.com>

On Sun, 15 Apr 2007 16:04:06 -0400
Erik Morton <eimorton at gmail.com> wrote:

> I'm having a strange problem accessing a 1.7GB Ferret index from  
> within Mongrel (1.0.1) on Linux. On OSX a Ferret search through Rails  
> takes a fraction of a second. From the command line, bypassing  
> Mongrel, the search takes about the same amount of time. On Fedora  
> Core 4 a Ferret search from the command line takes a fraction of a  
> second, but the same search through Mongrel never returns. The  
> mongrel just spins and using 50% or so of the CPU.
> 
> Has anyone seen anything like this? Is there some kind of limit on  
> the size of a file that Mongrel allows Rails to access in Linux? Help  
> is greatly appreciated. I had no problem on Linux searching a Ferret  
> index of about 1.5GB.

No, mongrel doesn't set any limits, and I don't think it could set
those kinds of OS limits without more extensive Ruby support.  It's
also odd that you have no problems on OSX but do have them on Linux.
When it comes to file IO problems it's usually the other way around.

There's a couple things you can do to get to the bottom of this.  Since
you have a reproducible test scenario, you can simply try your query,
make the CPU go 50% and then attach to it with:

 strace -p PID

This will print out the system calls being done by that ruby process
and should give you and the ferret author or myself an idea of what to
do next.

You may also have to delve into using gdb, but that's kind of complex.
Hit me up if strace doesn't help as there's a way to attach to a ruby
process via gdb and then force it to throw a ruby exception.  At a
minimum you could attach and do the command backtrace to see where in
the C callstack it's stuck.

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

From eimorton at gmail.com  Sun Apr 15 20:12:21 2007
From: eimorton at gmail.com (Erik Morton)
Date: Sun, 15 Apr 2007 20:12:21 -0400
Subject: [Mongrel] Ferret and Mongrel. OSX vs. Linux
In-Reply-To: <20070415190657.b9bfaef6.zedshaw@zedshaw.com>
References: <F20B8CCF-DDE2-417D-985E-0C9A5C9B73B2@gmail.com>
	<20070415190657.b9bfaef6.zedshaw@zedshaw.com>
Message-ID: <CA95AD1B-4A69-431D-A617-D24EB9EC915D@gmail.com>

Zed,
Thank you very much for the reply. The solution, as you will see, is  
very humbling for me. I installed strace and it looks like the  
problem is that there is a recursive permission denied error in an  
infinite loop that is hanging Mongrel:

open("/var/www/apps/search/current/config/../indexes/final/ 
segments_5", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)

My fix is obviously to change the ownership of my index files from  
root to the correct user.

The infinite loop seems like a Ferret issue. Do you agree?

Thanks again Zed.

Erik

On Apr 15, 2007, at 7:06 PM, Zed A. Shaw wrote:

> On Sun, 15 Apr 2007 16:04:06 -0400
> Erik Morton <eimorton at gmail.com> wrote:
>
>> I'm having a strange problem accessing a 1.7GB Ferret index from
>> within Mongrel (1.0.1) on Linux. On OSX a Ferret search through Rails
>> takes a fraction of a second. From the command line, bypassing
>> Mongrel, the search takes about the same amount of time. On Fedora
>> Core 4 a Ferret search from the command line takes a fraction of a
>> second, but the same search through Mongrel never returns. The
>> mongrel just spins and using 50% or so of the CPU.
>>
>> Has anyone seen anything like this? Is there some kind of limit on
>> the size of a file that Mongrel allows Rails to access in Linux? Help
>> is greatly appreciated. I had no problem on Linux searching a Ferret
>> index of about 1.5GB.
>
> No, mongrel doesn't set any limits, and I don't think it could set
> those kinds of OS limits without more extensive Ruby support.  It's
> also odd that you have no problems on OSX but do have them on Linux.
> When it comes to file IO problems it's usually the other way around.
>
> There's a couple things you can do to get to the bottom of this.   
> Since
> you have a reproducible test scenario, you can simply try your query,
> make the CPU go 50% and then attach to it with:
>
>  strace -p PID
>
> This will print out the system calls being done by that ruby process
> and should give you and the ferret author or myself an idea of what to
> do next.
>
> You may also have to delve into using gdb, but that's kind of complex.
> Hit me up if strace doesn't help as there's a way to attach to a ruby
> process via gdb and then force it to throw a ruby exception.  At a
> minimum you could attach and do the command backtrace to see where in
> the C callstack it's stuck.
>
> -- 
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> http://mongrel.rubyforge.org/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From zedshaw at zedshaw.com  Mon Apr 16 07:53:30 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 16 Apr 2007 07:53:30 -0400
Subject: [Mongrel] Ferret and Mongrel. OSX vs. Linux
In-Reply-To: <CA95AD1B-4A69-431D-A617-D24EB9EC915D@gmail.com>
References: <F20B8CCF-DDE2-417D-985E-0C9A5C9B73B2@gmail.com>
	<20070415190657.b9bfaef6.zedshaw@zedshaw.com>
	<CA95AD1B-4A69-431D-A617-D24EB9EC915D@gmail.com>
Message-ID: <20070416075330.a9900b5a.zedshaw@zedshaw.com>

On Sun, 15 Apr 2007 20:12:21 -0400
Erik Morton <eimorton at gmail.com> wrote:

> Zed,
> Thank you very much for the reply. The solution, as you will see, is  
> very humbling for me. I installed strace and it looks like the  
> problem is that there is a recursive permission denied error in an  
> infinite loop that is hanging Mongrel:
> 
> open("/var/www/apps/search/current/config/../indexes/final/ 
> segments_5", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)

Yeah, that's bad.  Probably lots of other ferret related errors like
that.
 
> My fix is obviously to change the ownership of my index files from  
> root to the correct user.
> 
> The infinite loop seems like a Ferret issue. Do you agree?

Yep, tell them about it.  That's basic IO operations.  It means that
the author is calling open and not checking for error conditions on the
return.  EVERY time someone has that habit they write code that's
easily hacked.

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

From matte at ruckuswireless.com  Tue Apr 17 00:09:45 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Mon, 16 Apr 2007 21:09:45 -0700
Subject: [Mongrel] problem restarting mongrel_cluster outside RAILS_ROOT -
 patch and other option
Message-ID: <46244889.1060108@ruckuswireless.com>

Hey folks.  Sorry for the SUPER long email but if you've been 
experiencing the same problems with restarting your mongrel cluster with 
Capistrano, then I have two solutions that have worked for me and I'm 
pretty sure will for you as well.

THE PROBLEM
I was having trouble restarting my clusters using Capistrano.  I've seen 
this come up before on the mailing list and looking through the archive 
I haven't been able to find a suitable answer or fix.

All my machines are updated to the latest mongrel and mongrel_cluster 
gems.  1.0.1 and 1.0.1.1 respectively.  Running a "cap restart" runs the 
correct command to restart the cluster (edited for brevity) ...

"sudo mongrel_rails cluster::restart -C [valid path to config] --clean"

This works when you are sitting in your rails app root, however, 
Capistrano runs it's commands from the ssh user's home directory.  I ran 
that same command from there and I got this dreaded error output.

/*** begin err output ***/
already stopped port 8000
already stopped port 8001
starting port 8000
!!! PID file log/mongrel.8000.pid already exists.  Mongrel could be 
running already.  Check your log/mongrel.8000.log for errors.
!!! Exiting with error.  You must stop mongrel and clear the .pid before 
I'll attempt a start.
starting port 8001
!!! PID file log/mongrel.8001.pid already exists.  Mongrel could be 
running already.  Check your log/mongrel.8001.log for errors.
!!! Exiting with error.  You must stop mongrel and clear the .pid before 
I'll attempt a start.
/*** end err output ***/

What was brought up earlier [1] was that it appears that mongrel is not 
changing the working directory to the one specified in the config file.  
A patch was submitted [2] but by my reckoning, has not been applied and 
released.

However, I believe the patch mentioned above may not be necessary 
because according to my research, the problem isn't with mongrel at 
all.  It's with mongrel_cluster, no offense Bradley.  :)  I've found two 
issues.  One I believe causes the other.

1) The basic problem is that the "start" and "stop" commands, when they 
are scanning for existing pid files, are not being run from the working 
directory, as specified by the :cwd setting in the mongrel_cluster 
config file.  mongrel_cluster does not use the working directory setting 
until it is past that point and finally calling the mongrel_rails 
command.  Thus, it isn't going to find the pid files if you are also 
susceptible to problem #2.

2) A relative directory :pid_file setting in the mongrel_cluster 
config.  If you're like me, your :pid_file setting is 
"log/mongrel.pid".  Using a relative directory like that is supposed to 
be based on the value of the :cwd setting.  But mongrel_cluster is not 
applying the :cwd setting when parsing the :pid_file setting for it's 
internal pid file variables.

SOLUTIONS... FINALLY!!  :)

1) The solution to the first problem is to patch 
mongrel_cluster/init.rb.  Add some directory change commands, like the 
"status" command uses.  I've uploaded my patch to Pastie at the address 
below.

<http://pastie.caboo.se/54340>

2) Don't use relative directories for the pid_file setting.  Once I 
changed to an absolute directory setting of, for example, 
"/www/app/shared/log/mongrel.pid" then mongrel_cluster correctly found 
my pid files.  Solution #1 is NOT needed in this instance.

Both solutions require the user to perform an action but I believe that 
the first solution requires less steps for the end user.  Instead of 
updating ALL of your mongrel_cluster config files, for every single app 
you're running, just update to the patched mongrel_cluster.

I suppose there's a THIRD solution and that's to patch the 
"read_options" function in init.rb.  Lines 28 and 29 need to be updated 
to  prepend @options["cwd"] if @options["pid_file"] or 
@options["log_file"] are relative paths.

Am I off base with all this?  Let me know.  And thanx for reading all 
the way to the end.  :)

matte - matte at silent-e.com

1: <http://rubyforge.org/pipermail/mongrel-users/2007-March/003341.html>
2: <http://rubyforge.org/pipermail/mongrel-users/2007-March/003343.html>


From wayneeseguin at gmail.com  Tue Apr 17 06:24:06 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 17 Apr 2007 06:24:06 -0400
Subject: [Mongrel] problem restarting mongrel_cluster outside RAILS_ROOT
	- patch and other option
In-Reply-To: <46244889.1060108@ruckuswireless.com>
References: <46244889.1060108@ruckuswireless.com>
Message-ID: <4093BA72-4464-4B4C-ABDF-7F924F649A60@gmail.com>

Matte,
On Apr 17, 2007, at 00:09 , Matte Edens wrote:
> "sudo mongrel_rails cluster::restart -C [valid path to config] -- 
> clean"

Is this really a problem with mongrel cluster?

A "fourth" solution is to simply modify your restart task in your  
Capistrano recipe:

task :restart, :roles => :app do
   run(or sudo) "cd #{current_path}; mongrel_rails cluster::restart - 
C [valid path to config] --clean"
end

~Wayne

From mikeisgreat at gmail.com  Tue Apr 17 11:36:27 2007
From: mikeisgreat at gmail.com (Michael Steinfeld)
Date: Tue, 17 Apr 2007 11:36:27 -0400
Subject: [Mongrel] problem restarting mongrel_cluster outside RAILS_ROOT
	- patch and other option
In-Reply-To: <4093BA72-4464-4B4C-ABDF-7F924F649A60@gmail.com>
References: <46244889.1060108@ruckuswireless.com>
	<4093BA72-4464-4B4C-ABDF-7F924F649A60@gmail.com>
Message-ID: <3d5db09e0704170836l59bad7ect79caacf6c066de22@mail.gmail.com>

Well, I have fought this so many times, and another issue that comes
up is if you had fastcgi previously in use before migrating to
mongrel.

I have spent countless hours trying to deal with the mongrel pids and
stopping and starting after each deploy. I lost the battle. I can
start/stop manually using the /etc/init.d/mongrel_cluster script
without fail.

I am attempting to offer a fifth option here which I have not yet put
into effect but plan to if I can't find any other solution. Wayne's
solutiion has not worked for me and setting the full path in
mongrel_cluster.yml has not worked either.

This is not the most advised approach I am sure.. but it will work
with a little tweaking. Then again I don't want my app to be down
during each deploy... *sighs
---------------
desc "Kill all the pids in case there are some zombies and remove
the .pid files"
task :before_before_deploy, :roles => :app do
  begin
    run "sudo kill -9 `ps -ef | grep mongrel | egrep -v grep | awk
'{print $2}'`"
    run "cd #{previous_release}/logs && sudo rm -rf *.pid"
  end

task :after_after_deploy, :roles => :app do
  begin
    " sudo /etc/init.d/mongrel_cluster start"
  end

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

This is probably overkill, but I ran out of patience.

Let me know what you guys think.

--mike

On 4/17/07, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:
> Matte,
> On Apr 17, 2007, at 00:09 , Matte Edens wrote:
> > "sudo mongrel_rails cluster::restart -C [valid path to config] --
> > clean"
>
> Is this really a problem with mongrel cluster?
>
> A "fourth" solution is to simply modify your restart task in your
> Capistrano recipe:
>
> task :restart, :roles => :app do
>    run(or sudo) "cd #{current_path}; mongrel_rails cluster::restart -
> C [valid path to config] --clean"
> end
>
> ~Wayne
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
-mike

From zedshaw at zedshaw.com  Tue Apr 17 14:14:48 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 17 Apr 2007 14:14:48 -0400
Subject: [Mongrel] problem restarting mongrel_cluster outside RAILS_ROOT
 - patch and other option
In-Reply-To: <3d5db09e0704170836l59bad7ect79caacf6c066de22@mail.gmail.com>
References: <46244889.1060108@ruckuswireless.com>
	<4093BA72-4464-4B4C-ABDF-7F924F649A60@gmail.com>
	<3d5db09e0704170836l59bad7ect79caacf6c066de22@mail.gmail.com>
Message-ID: <20070417141448.dbfdc40b.zedshaw@zedshaw.com>

On Tue, 17 Apr 2007 11:36:27 -0400
"Michael Steinfeld" <mikeisgreat at gmail.com> wrote:

It was discussed earlier, but have you tried kill -USR2?  It does the
proper restart where it waits for mongrel to stop internally and then
start again with the same command.  Here's how you'd change your script:


 desc "Make mongrel restart after deployment"
 task :after_after_deploy, :roles => :app do
   begin
     run "sudo killall -USR2 mongrel_rails"
   end

Let me know if that works.  There *might* be an issue with the current
directory symlinking on restart.

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

From fredsubs at gmail.com  Tue Apr 17 14:52:39 2007
From: fredsubs at gmail.com (Frederic Do Couto)
Date: Tue, 17 Apr 2007 19:52:39 +0100
Subject: [Mongrel] How to change the default encoding for dynamic pages
Message-ID: <53d17b4e0704171152j9a81473l966b0c4211874b56@mail.gmail.com>

Hello,

I'm trying to write a rails application serves by mongrel and using
accentuated characters in the .rhtml page. But Mongrel replace them by '?' .

It works fine for static pages by defining the charset to iso-8859-1 in the
mongrel_mime.yml

But how to change the default encoding (seems to be UTF-8) for the dynamic
pages ?

thanks for your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070417/fd6be7fc/attachment-0001.html 

From jbaty at fusionary.com  Tue Apr 17 14:59:02 2007
From: jbaty at fusionary.com (Jack Baty)
Date: Tue, 17 Apr 2007 14:59:02 -0400
Subject: [Mongrel] How to change the default encoding for dynamic pages
In-Reply-To: <53d17b4e0704171152j9a81473l966b0c4211874b56@mail.gmail.com>
References: <53d17b4e0704171152j9a81473l966b0c4211874b56@mail.gmail.com>
Message-ID: <81350a250704171159n851d97cid5bce493a9134cd7@mail.gmail.com>

Is this a Rails thing settable in environment.rb?

ActionController::Base.default_charset=("UTF-8")

Although I think as of Rails 1.2 UTF-8 is the default. I hate encoding
issues, as I never really know what's "in charge."


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


On 4/17/07, Frederic Do Couto <fredsubs at gmail.com> wrote:
> Hello,
>
> I'm trying to write a rails application serves by mongrel and using
> accentuated characters in the .rhtml page. But Mongrel replace them by '?' .
>
> It works fine for static pages by defining the charset to iso-8859-1 in the
> mongrel_mime.yml
>
> But how to change the default encoding (seems to be UTF-8) for the dynamic
> pages ?
>
> thanks for your help.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From fredsubs at gmail.com  Tue Apr 17 15:17:15 2007
From: fredsubs at gmail.com (Frederic Do Couto)
Date: Tue, 17 Apr 2007 20:17:15 +0100
Subject: [Mongrel] How to change the default encoding for dynamic pages
In-Reply-To: <81350a250704171159n851d97cid5bce493a9134cd7@mail.gmail.com>
References: <53d17b4e0704171152j9a81473l966b0c4211874b56@mail.gmail.com>
	<81350a250704171159n851d97cid5bce493a9134cd7@mail.gmail.com>
Message-ID: <53d17b4e0704171217w4621850auaafebf959b270392@mail.gmail.com>

thank you, it works.

i've added this line ActionController::Base.default_charset=("ISO-8859-1")
in the environment.rb.

i've tried with the iso-8859-15 to have the ? (euro) symbol but it doesn t
work. If you have another good idea ? ;)

thanks

On 4/17/07, Jack Baty <jbaty at fusionary.com> wrote:
>
> Is this a Rails thing settable in environment.rb?
>
> ActionController::Base.default_charset=("UTF-8")
>
> Although I think as of Rails 1.2 UTF-8 is the default. I hate encoding
> issues, as I never really know what's "in charge."
>
>
> --
>
> --------------------------------------------------------------------------------
> Jack Baty                  http://jackbaty.com/    (616) 822-5800
> Fusionary                  http://fusionary.com/   (616) 454-2357
> 820 Monroe N.W. Suite 212
> Grand Rapids, MI 49503
>
>
> On 4/17/07, Frederic Do Couto <fredsubs at gmail.com> wrote:
> > Hello,
> >
> > I'm trying to write a rails application serves by mongrel and using
> > accentuated characters in the .rhtml page. But Mongrel replace them by
> '?' .
> >
> > It works fine for static pages by defining the charset to iso-8859-1 in
> the
> > mongrel_mime.yml
> >
> > But how to change the default encoding (seems to be UTF-8) for the
> dynamic
> > pages ?
> >
> > thanks for your help.
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070417/a4b07ec6/attachment.html 

From matte at ruckuswireless.com  Tue Apr 17 15:27:31 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Tue, 17 Apr 2007 12:27:31 -0700
Subject: [Mongrel] problem restarting mongrel_cluster outside RAILS_ROOT
 - patch and other option
In-Reply-To: <4093BA72-4464-4B4C-ABDF-7F924F649A60@gmail.com>
References: <46244889.1060108@ruckuswireless.com>
	<4093BA72-4464-4B4C-ABDF-7F924F649A60@gmail.com>
Message-ID: <46251FA3.5080901@ruckuswireless.com>

Sorry.  another long one.

Wayne, I used to use that actually.  And I even tried it last night, and 
today, before sending the email.  It didn't work using capistrano, or 
from anywhere that wasn't a rails_root location.  There's still a 
problem of where the command is run and where mongrel_cluster thinks 
it's looking for the pid files.  Here's how I see it happening...

1) we run "cap restart" on local machine where it logs in via ssh to 
execute remote commands
2) located in the /home/ssh_user directory, the remote commands run from 
here.
3) restart runs a "stop/start" command sequence.  yes, I've been reading 
the discussion of using a -USR2 command, but for this discussion we 
ignore that until the bottom of this email.
4) "stop" line 101, reads the options
5) "read_options" line 28 calls "process_pid_file" to parse the pid_file 
setting
6) "process_pid_file" sets up several variables for future use.

Here is where it breaks down with a relative path pid_file setting.  
None of the File.* commands are run from the cwd in that function.  
They're run from the /home/ssh_user directory.  Now I don't know about 
you but I don't run my applications from that directory.  Thus, with a 
setting of "log/mongrel.pid", the port_pid_file function returns 
"log/mongrel.8000.pid" and check_process is looking for 
/home/ssh_user/log/mongrel.8000.pid which obviously doesn't exist.  
Making a small change, that I am not suggesting is a fix, just 
temporary, I rewrote this line in process_pid_file (line 40).

@pid_file_dir = File.dirname("#{@options['cwd']}/#{pid_file}")

That's just a test to see if it would work with the addition of the 
cwd.  It worked of course, because now File.dirname had an absolute path 
to parse.

So, my suggestions from the first email, IMHO, are still valid.  Patch 
mongrel_cluster/init.rb to either ...

1) Change directories in "stop" and "start" before the check_process 
functions are called so that relative directories are handled correctly, 
(see my pastie) or
2) Change the process_pid_file function to handle relative directory 
pid_file settings by prepending the cwd setting.

or 3) have everyone change their mongrel_cluster config files to us 
absolute directory paths.  And, then there's the more recent discussion 
of changing the restart command to just call a -USR2 on mongrel_rails.

Personally, I'd like it to be fixed within mongrel_cluster so that it's 
just picked up by everyone when they update their gem.  And instead of 
asking everyone to put in a "after_after_deploy" capistrano task like 
Zed mentioned in this thread.  However, I just tried the following 
capistrano task...

task :restart do
  sudo "killall -USR2 mongrel_rails"
end

and got this error "No matching processes were found".  No idea about 
that except that when I "ps aux | grep mongrel_rails", each command 
starts...

/usr/local/bin/ruby18 /usr/local/bin/mongrel_rails start -d -e 
production -a 127.0.0.1 -c /home/...

My linux_fu is not strong enough to know how to diagnose this last issue.

matte

Wayne E. Seguin wrote:
> Matte,
> On Apr 17, 2007, at 00:09 , Matte Edens wrote:
>   
>> "sudo mongrel_rails cluster::restart -C [valid path to config] -- 
>> clean"
>>     
>
> Is this really a problem with mongrel cluster?
>
> A "fourth" solution is to simply modify your restart task in your  
> Capistrano recipe:
>
> task :restart, :roles => :app do
>    run(or sudo) "cd #{current_path}; mongrel_rails cluster::restart - 
> C [valid path to config] --clean"
> end

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

From bradley at railsmachine.com  Tue Apr 17 16:13:14 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Tue, 17 Apr 2007 16:13:14 -0400
Subject: [Mongrel] problem restarting mongrel_cluster outside RAILS_ROOT
 - patch and other option
In-Reply-To: <46251FA3.5080901@ruckuswireless.com>
References: <46244889.1060108@ruckuswireless.com>	<4093BA72-4464-4B4C-ABDF-7F924F649A60@gmail.com>
	<46251FA3.5080901@ruckuswireless.com>
Message-ID: <46252A5A.6000201@railsmachine.com>

Hi:

As I mentioned earlier, I'll fix this for the final release (any day now 
- been really busy).

http://rubyforge.org/pipermail/mongrel-users/2007-April/003454.html

However, as I wrote before, its not a good idea to put pidfiles in a 
relative directory as they won't get cleaned up after a server crash. 
For linux, /var/run/mongrel_cluster is a better location.

http://rubyforge.org/pipermail/mongrel-users/2007-February/003000.html

Bradley

Matte Edens wrote:
> Sorry.  another long one.
> 
> Wayne, I used to use that actually.  And I even tried it last night, and 
> today, before sending the email.  It didn't work using capistrano, or 
> from anywhere that wasn't a rails_root location.  There's still a 
> problem of where the command is run and where mongrel_cluster thinks 
> it's looking for the pid files.  Here's how I see it happening...
> 
> 1) we run "cap restart" on local machine where it logs in via ssh to 
> execute remote commands
> 2) located in the /home/ssh_user directory, the remote commands run from 
> here.
> 3) restart runs a "stop/start" command sequence.  yes, I've been reading 
> the discussion of using a -USR2 command, but for this discussion we 
> ignore that until the bottom of this email.
> 4) "stop" line 101, reads the options
> 5) "read_options" line 28 calls "process_pid_file" to parse the pid_file 
> setting
> 6) "process_pid_file" sets up several variables for future use.
> 
> Here is where it breaks down with a relative path pid_file setting.  
> None of the File.* commands are run from the cwd in that function.  
> They're run from the /home/ssh_user directory.  Now I don't know about 
> you but I don't run my applications from that directory.  Thus, with a 
> setting of "log/mongrel.pid", the port_pid_file function returns 
> "log/mongrel.8000.pid" and check_process is looking for 
> /home/ssh_user/log/mongrel.8000.pid which obviously doesn't exist.  
> Making a small change, that I am not suggesting is a fix, just 
> temporary, I rewrote this line in process_pid_file (line 40).
> 
> @pid_file_dir = File.dirname("#{@options['cwd']}/#{pid_file}")
> 
> That's just a test to see if it would work with the addition of the 
> cwd.  It worked of course, because now File.dirname had an absolute path 
> to parse.
> 
> So, my suggestions from the first email, IMHO, are still valid.  Patch 
> mongrel_cluster/init.rb to either ...
> 
> 1) Change directories in "stop" and "start" before the check_process 
> functions are called so that relative directories are handled correctly, 
> (see my pastie) or
> 2) Change the process_pid_file function to handle relative directory 
> pid_file settings by prepending the cwd setting.
> 
> or 3) have everyone change their mongrel_cluster config files to us 
> absolute directory paths.  And, then there's the more recent discussion 
> of changing the restart command to just call a -USR2 on mongrel_rails.
> 
> Personally, I'd like it to be fixed within mongrel_cluster so that it's 
> just picked up by everyone when they update their gem.  And instead of 
> asking everyone to put in a "after_after_deploy" capistrano task like 
> Zed mentioned in this thread.  However, I just tried the following 
> capistrano task...
> 
> task :restart do
>   sudo "killall -USR2 mongrel_rails"
> end
> 
> and got this error "No matching processes were found".  No idea about 
> that except that when I "ps aux | grep mongrel_rails", each command 
> starts...
> 
> /usr/local/bin/ruby18 /usr/local/bin/mongrel_rails start -d -e 
> production -a 127.0.0.1 -c /home/...
> 
> My linux_fu is not strong enough to know how to diagnose this last issue.
> 
> matte
> 
> Wayne E. Seguin wrote:
>> Matte,
>> On Apr 17, 2007, at 00:09 , Matte Edens wrote:
>>   
>>> "sudo mongrel_rails cluster::restart -C [valid path to config] -- 
>>> clean"
>>>     
>>
>> Is this really a problem with mongrel cluster?
>>
>> A "fourth" solution is to simply modify your restart task in your  
>> Capistrano recipe:
>>
>> task :restart, :roles => :app do
>>    run(or sudo) "cd #{current_path}; mongrel_rails cluster::restart - 
>> C [valid path to config] --clean"
>> end
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From mikeisgreat at gmail.com  Tue Apr 17 16:34:40 2007
From: mikeisgreat at gmail.com (Michael Steinfeld)
Date: Tue, 17 Apr 2007 16:34:40 -0400
Subject: [Mongrel] problem restarting mongrel_cluster outside RAILS_ROOT
	- patch and other option
In-Reply-To: <46252A5A.6000201@railsmachine.com>
References: <46244889.1060108@ruckuswireless.com>
	<4093BA72-4464-4B4C-ABDF-7F924F649A60@gmail.com>
	<46251FA3.5080901@ruckuswireless.com>
	<46252A5A.6000201@railsmachine.com>
Message-ID: <3d5db09e0704171334j5b38b787n763dfbe6f5209d10@mail.gmail.com>

Bradley, I can wait a few more days! Great News! Also, thank you
everyone for the help.



On 4/17/07, Bradley Taylor <bradley at railsmachine.com> wrote:
> Hi:
>
> As I mentioned earlier, I'll fix this for the final release (any day now
> - been really busy).
>
> http://rubyforge.org/pipermail/mongrel-users/2007-April/003454.html
>
> However, as I wrote before, its not a good idea to put pidfiles in a
> relative directory as they won't get cleaned up after a server crash.
> For linux, /var/run/mongrel_cluster is a better location.
>
> http://rubyforge.org/pipermail/mongrel-users/2007-February/003000.html
>
> Bradley
>
> Matte Edens wrote:
> > Sorry.  another long one.
> >
> > Wayne, I used to use that actually.  And I even tried it last night, and
> > today, before sending the email.  It didn't work using capistrano, or
> > from anywhere that wasn't a rails_root location.  There's still a
> > problem of where the command is run and where mongrel_cluster thinks
> > it's looking for the pid files.  Here's how I see it happening...
> >
> > 1) we run "cap restart" on local machine where it logs in via ssh to
> > execute remote commands
> > 2) located in the /home/ssh_user directory, the remote commands run from
> > here.
> > 3) restart runs a "stop/start" command sequence.  yes, I've been reading
> > the discussion of using a -USR2 command, but for this discussion we
> > ignore that until the bottom of this email.
> > 4) "stop" line 101, reads the options
> > 5) "read_options" line 28 calls "process_pid_file" to parse the pid_file
> > setting
> > 6) "process_pid_file" sets up several variables for future use.
> >
> > Here is where it breaks down with a relative path pid_file setting.
> > None of the File.* commands are run from the cwd in that function.
> > They're run from the /home/ssh_user directory.  Now I don't know about
> > you but I don't run my applications from that directory.  Thus, with a
> > setting of "log/mongrel.pid", the port_pid_file function returns
> > "log/mongrel.8000.pid" and check_process is looking for
> > /home/ssh_user/log/mongrel.8000.pid which obviously doesn't exist.
> > Making a small change, that I am not suggesting is a fix, just
> > temporary, I rewrote this line in process_pid_file (line 40).
> >
> > @pid_file_dir = File.dirname("#{@options['cwd']}/#{pid_file}")
> >
> > That's just a test to see if it would work with the addition of the
> > cwd.  It worked of course, because now File.dirname had an absolute path
> > to parse.
> >
> > So, my suggestions from the first email, IMHO, are still valid.  Patch
> > mongrel_cluster/init.rb to either ...
> >
> > 1) Change directories in "stop" and "start" before the check_process
> > functions are called so that relative directories are handled correctly,
> > (see my pastie) or
> > 2) Change the process_pid_file function to handle relative directory
> > pid_file settings by prepending the cwd setting.
> >
> > or 3) have everyone change their mongrel_cluster config files to us
> > absolute directory paths.  And, then there's the more recent discussion
> > of changing the restart command to just call a -USR2 on mongrel_rails.
> >
> > Personally, I'd like it to be fixed within mongrel_cluster so that it's
> > just picked up by everyone when they update their gem.  And instead of
> > asking everyone to put in a "after_after_deploy" capistrano task like
> > Zed mentioned in this thread.  However, I just tried the following
> > capistrano task...
> >
> > task :restart do
> >   sudo "killall -USR2 mongrel_rails"
> > end
> >
> > and got this error "No matching processes were found".  No idea about
> > that except that when I "ps aux | grep mongrel_rails", each command
> > starts...
> >
> > /usr/local/bin/ruby18 /usr/local/bin/mongrel_rails start -d -e
> > production -a 127.0.0.1 -c /home/...
> >
> > My linux_fu is not strong enough to know how to diagnose this last issue.
> >
> > matte
> >
> > Wayne E. Seguin wrote:
> >> Matte,
> >> On Apr 17, 2007, at 00:09 , Matte Edens wrote:
> >>
> >>> "sudo mongrel_rails cluster::restart -C [valid path to config] --
> >>> clean"
> >>>
> >>
> >> Is this really a problem with mongrel cluster?
> >>
> >> A "fourth" solution is to simply modify your restart task in your
> >> Capistrano recipe:
> >>
> >> task :restart, :roles => :app do
> >>    run(or sudo) "cd #{current_path}; mongrel_rails cluster::restart -
> >> C [valid path to config] --clean"
> >> end
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
>


-- 
-mike

From matte at ruckuswireless.com  Tue Apr 17 16:46:28 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Tue, 17 Apr 2007 13:46:28 -0700
Subject: [Mongrel] problem restarting mongrel_cluster outside RAILS_ROOT
 - patch and other option
In-Reply-To: <46252A5A.6000201@railsmachine.com>
References: <46244889.1060108@ruckuswireless.com>	<4093BA72-4464-4B4C-ABDF-7F924F649A60@gmail.com>	<46251FA3.5080901@ruckuswireless.com>
	<46252A5A.6000201@railsmachine.com>
Message-ID: <46253224.9070407@ruckuswireless.com>

DOH.  missed that one.  shoulda looked closer.  That 
/var/run/mongrel_cluster location is a good idea.  hadn't thought of 
that.  However, you mention the init.d script.  My linux_fu is not 
strong so I'm guessing that the equivalent will work just fine in a 
FreeBSD setup.

Thanx Bradley.  I eagerly await the next release.  Now, off to update my 
config files.

matte

Bradley Taylor wrote:
> Hi:
>
> As I mentioned earlier, I'll fix this for the final release (any day now 
> - been really busy).
>
> http://rubyforge.org/pipermail/mongrel-users/2007-April/003454.html
>
> However, as I wrote before, its not a good idea to put pidfiles in a 
> relative directory as they won't get cleaned up after a server crash. 
> For linux, /var/run/mongrel_cluster is a better location.
>
> http://rubyforge.org/pipermail/mongrel-users/2007-February/003000.html
>
> Bradley
>
> Matte Edens wrote:
>   
>> Sorry.  another long one.
>>
>> <snip>
>>
>> matte
>>
>> Wayne E. Seguin wrote:
>>     
>>> Matte,
>>> On Apr 17, 2007, at 00:09 , Matte Edens wrote:
>>>   
>>>       
>>>> "sudo mongrel_rails cluster::restart -C [valid path to config] -- 
>>>> clean"
>>>>     
>>>>         
>>> Is this really a problem with mongrel cluster?
>>>
>>> A "fourth" solution is to simply modify your restart task in your  
>>> Capistrano recipe:
>>>
>>> task :restart, :roles => :app do
>>>    run(or sudo) "cd #{current_path}; mongrel_rails cluster::restart - 
>>> C [valid path to config] --clean"
>>> end


From nstlaurent at wantedtech.com  Tue Apr 17 15:44:31 2007
From: nstlaurent at wantedtech.com (Nicolas St-Laurent)
Date: Tue, 17 Apr 2007 15:44:31 -0400
Subject: [Mongrel] Session problem mongrel behind Apache proxy
Message-ID: <F8DBDA77-C19C-4C9E-9B00-8A9E10F2A13F@wantedtech.com>

Hi,

I've configured mongrel_clusters behind an Apache 2.2 proxy using  
named virtual host. Session are saved as ActiveRecordSession. But the  
cookies created on client side doesn't correspond to session data  
saved in database (keys are different). The RoR app react just like  
it doesn't have a session at all.

If I don't use Apache as a proxy/load balancer and call directly  
Mongrel_cluster, everything works well.

What should I do to get session working with Mongrel behind an Apache  
proxy/load balancer ?

**** Extract of my Apache config *****

# Setup a cluster for each application
<Proxy balancer://myapp>
     BalancerMember http://10.1.4.22:3000
     BalancerMember http://10.1.4.22:3001
     BalancerMember http://10.1.4.22:3002
</Proxy>

<VirtualHost 10.1.4.22:80>
     ServerName myapp.xxxxxxxx.yyy
     DocumentRoot /srv/www/rails/myapp/public

     <Directory "/srv/www/rails/myapp/public">
         Options FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>

     # The root of this virtual host redirect to Portal application
     ProxyPass / balancer://myapp/
     ProxyPassReverse / balancer://myapp/
     ProxyPreserveHost on

     # Make all of the /public/images directory served by Apache
     ProxyPass /images !
     Alias /images /srv/www/rails/myapp/public/images

     # Setup your Rewrite rules here
     RewriteEngine On

     # Rewrite index to check for static
     RewriteRule ^/$ /index.html [QSA]

     # Send all requests that are not found as existing files to the  
cluster
     RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
     RewriteRule ^/(.*)$ balancer://myapp%{REQUEST_URI} [P,QSA,L]

     # Error logs
     ErrorLog /var/log/apache2/myapp_error_log
     CustomLog /var/log/apache2/myapp_access_log combined
</VirtualHost>>

**** END ****

Thanks,

Nicolas

From kylekochis at gmail.com  Tue Apr 17 17:05:43 2007
From: kylekochis at gmail.com (Kyle Kochis)
Date: Tue, 17 Apr 2007 15:05:43 -0600
Subject: [Mongrel] How to change the default encoding for dynamic pages
In-Reply-To: <53d17b4e0704171217w4621850auaafebf959b270392@mail.gmail.com>
References: <53d17b4e0704171152j9a81473l966b0c4211874b56@mail.gmail.com>
	<81350a250704171159n851d97cid5bce493a9134cd7@mail.gmail.com>
	<53d17b4e0704171217w4621850auaafebf959b270392@mail.gmail.com>
Message-ID: <6a7034b0704171405m6e095bc8m189056f797e9839e@mail.gmail.com>

Are you encoding the symbols properly with html entities? That may be stupid
question but I wanted to make sure. Most systems/browsers don't know what to
do with weird (or not so weird) symbols even if they are valid in the
document encoding.
Kyle

On 4/17/07, Frederic Do Couto <fredsubs at gmail.com> wrote:
>
> thank you, it works.
>
> i've added this line ActionController::Base.default_charset=("ISO-8859-1")
> in the environment.rb.
>
> i've tried with the iso-8859-15 to have the ? (euro) symbol but it doesn t
> work. If you have another good idea ? ;)
>
> thanks
>
> On 4/17/07, Jack Baty <jbaty at fusionary.com> wrote:
> >
> > Is this a Rails thing settable in environment.rb?
> >
> > ActionController::Base.default_charset=("UTF-8")
> >
> > Although I think as of Rails 1.2 UTF-8 is the default. I hate encoding
> > issues, as I never really know what's "in charge."
> >
> >
> > --
> >
> > --------------------------------------------------------------------------------
> > Jack Baty                  http://jackbaty.com/    (616) 822-5800
> > Fusionary                   http://fusionary.com/   (616) 454-2357
> > 820 Monroe N.W. Suite 212
> > Grand Rapids, MI 49503
> >
> >
> > On 4/17/07, Frederic Do Couto <fredsubs at gmail.com > wrote:
> > > Hello,
> > >
> > > I'm trying to write a rails application serves by mongrel and using
> > > accentuated characters in the .rhtml page. But Mongrel replace them by
> > '?' .
> > >
> > > It works fine for static pages by defining the charset to iso-8859-1
> > in the
> > > mongrel_mime.yml
> > >
> > > But how to change the default encoding (seems to be UTF-8) for the
> > dynamic
> > > pages ?
> > >
> > > thanks for your help.
> > > _______________________________________________
> > > Mongrel-users mailing list
> > > Mongrel-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/mongrel-users
> > >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
>
> _______________________________________________
> 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/20070417/10c54ddf/attachment.html 

From fredsubs at gmail.com  Wed Apr 18 03:01:51 2007
From: fredsubs at gmail.com (Frederic Do Couto)
Date: Wed, 18 Apr 2007 09:01:51 +0200
Subject: [Mongrel] How to change the default encoding for dynamic pages
In-Reply-To: <6a7034b0704171405m6e095bc8m189056f797e9839e@mail.gmail.com>
References: <53d17b4e0704171152j9a81473l966b0c4211874b56@mail.gmail.com>
	<81350a250704171159n851d97cid5bce493a9134cd7@mail.gmail.com>
	<53d17b4e0704171217w4621850auaafebf959b270392@mail.gmail.com>
	<6a7034b0704171405m6e095bc8m189056f797e9839e@mail.gmail.com>
Message-ID: <53d17b4e0704180001i401d440am63d3d4896d78bd33@mail.gmail.com>

Hi,

Sure I can use the &euro; html entity but i'm looking way to the ? symbole
directly in the source code.

Thank you

On 4/17/07, Kyle Kochis <kylekochis at gmail.com> wrote:
>
> Are you encoding the symbols properly with html entities? That may be
> stupid question but I wanted to make sure. Most systems/browsers don't know
> what to do with weird (or not so weird) symbols even if they are valid in
> the document encoding.
> Kyle
>
> On 4/17/07, Frederic Do Couto <fredsubs at gmail.com> wrote:
> >
> > thank you, it works.
> >
> > i've added this line ActionController::Base.default_charset=("ISO-8859-1")
> > in the environment.rb.
> >
> > i've tried with the iso-8859-15 to have the ? (euro) symbol but it doesn
> > t work. If you have another good idea ? ;)
> >
> > thanks
> >
> > On 4/17/07, Jack Baty < jbaty at fusionary.com> wrote:
> > >
> > > Is this a Rails thing settable in environment.rb?
> > >
> > > ActionController::Base.default_charset=("UTF-8")
> > >
> > > Although I think as of Rails 1.2 UTF-8 is the default. I hate encoding
> > > issues, as I never really know what's "in charge."
> > >
> > >
> > > --
> > >
> > > --------------------------------------------------------------------------------
> > > Jack Baty                   http://jackbaty.com/    (616) 822-5800
> > > Fusionary                   http://fusionary.com/   (616) 454-2357
> > > 820 Monroe N.W. Suite 212
> > > Grand Rapids, MI 49503
> > >
> > >
> > > On 4/17/07, Frederic Do Couto < fredsubs at gmail.com > wrote:
> > > > Hello,
> > > >
> > > > I'm trying to write a rails application serves by mongrel and using
> > > > accentuated characters in the .rhtml page. But Mongrel replace them
> > > by '?' .
> > > >
> > > > It works fine for static pages by defining the charset to iso-8859-1
> > > in the
> > > > mongrel_mime.yml
> > > >
> > > > But how to change the default encoding (seems to be UTF-8) for the
> > > dynamic
> > > > pages ?
> > > >
> > > > thanks for your help.
> > > > _______________________________________________
> > > > Mongrel-users mailing list
> > > > Mongrel-users at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/mongrel-users
> > > >
> > > _______________________________________________
> > > Mongrel-users mailing list
> > > Mongrel-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/mongrel-users
> > >
> >
> >
> > _______________________________________________
> > 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/20070418/f896b940/attachment.html 

From fredsubs at gmail.com  Wed Apr 18 03:14:05 2007
From: fredsubs at gmail.com (Frederic Do Couto)
Date: Wed, 18 Apr 2007 09:14:05 +0200
Subject: [Mongrel] How to change the default encoding for dynamic pages
In-Reply-To: <6a7034b0704171405m6e095bc8m189056f797e9839e@mail.gmail.com>
References: <53d17b4e0704171152j9a81473l966b0c4211874b56@mail.gmail.com>
	<81350a250704171159n851d97cid5bce493a9134cd7@mail.gmail.com>
	<53d17b4e0704171217w4621850auaafebf959b270392@mail.gmail.com>
	<6a7034b0704171405m6e095bc8m189056f797e9839e@mail.gmail.com>
Message-ID: <53d17b4e0704180014o3b955ca9w1814baa2cfd101cf@mail.gmail.com>

Hi,

Sure I can use the &euro; html entity but i'm looking way to the ? symbole
directly in the source code.

Thank you

On 4/17/07, Kyle Kochis <kylekochis at gmail.com> wrote:
>
> Are you encoding the symbols properly with html entities? That may be
> stupid question but I wanted to make sure. Most systems/browsers don't know
> what to do with weird (or not so weird) symbols even if they are valid in
> the document encoding.
> Kyle
>
> On 4/17/07, Frederic Do Couto <fredsubs at gmail.com> wrote:
> >
> > thank you, it works.
> >
> > i've added this line ActionController::Base.default_charset=("ISO-8859-1")
> > in the environment.rb.
> >
> > i've tried with the iso-8859-15 to have the ? (euro) symbol but it doesn
> > t work. If you have another good idea ? ;)
> >
> > thanks
> >
> > On 4/17/07, Jack Baty < jbaty at fusionary.com> wrote:
> > >
> > > Is this a Rails thing settable in environment.rb?
> > >
> > > ActionController::Base.default_charset=("UTF-8")
> > >
> > > Although I think as of Rails 1.2 UTF-8 is the default. I hate encoding
> > > issues, as I never really know what's "in charge."
> > >
> > >
> > > --
> > >
> > > --------------------------------------------------------------------------------
> > > Jack Baty                   http://jackbaty.com/    (616) 822-5800
> > > Fusionary                   http://fusionary.com/   (616) 454-2357
> > > 820 Monroe N.W. Suite 212
> > > Grand Rapids, MI 49503
> > >
> > >
> > > On 4/17/07, Frederic Do Couto < fredsubs at gmail.com > wrote:
> > > > Hello,
> > > >
> > > > I'm trying to write a rails application serves by mongrel and using
> > > > accentuated characters in the .rhtml page. But Mongrel replace them
> > > by '?' .
> > > >
> > > > It works fine for static pages by defining the charset to iso-8859-1
> > > in the
> > > > mongrel_mime.yml
> > > >
> > > > But how to change the default encoding (seems to be UTF-8) for the
> > > dynamic
> > > > pages ?
> > > >
> > > > thanks for your help.
> > > > _______________________________________________
> > > > Mongrel-users mailing list
> > > > Mongrel-users at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/mongrel-users
> > > >
> > > _______________________________________________
> > > Mongrel-users mailing list
> > > Mongrel-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/mongrel-users
> > >
> >
> >
> > _______________________________________________
> > 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/20070418/173c7c42/attachment-0001.html 

From jeremy at hinegardner.org  Fri Apr 20 04:15:02 2007
From: jeremy at hinegardner.org (Jeremy Hinegardner)
Date: Fri, 20 Apr 2007 02:15:02 -0600
Subject: [Mongrel] order of registering uri's matters for URIClassifier ?
Message-ID: <20070420081502.GC643@hinegardner.org>

Hi all,

I'm playing around with mongrel handlers and I came across a behaviour
that seems abnormal to me with regard to the Configurator#uri calls.  It
appears that order matters.

For instance:

    ...
    listener do 
        uri "/icons", :handler => DirHandler.new("/var/www/icons")
        uri "/", :handler => DirHandler.new("/var/app/html")
        uri "/", :handler => stats
    end
    ...

with this sort of configuration, any URI that is alphabetically AFTER
"/icons" will be short circuited to a 404 error in mongrel.

The cause is basically :
    @classifier.resolve("/junk")  # => [nil,nil,nil]

Instead of :
    ["/junk", "/", [#<Mongrel::DirHandler>, #<Mongrel::StatusHandler>]]

I've attached a unit test that shows this effect by calling the
URIClassifier directly.  I'm not sure if this is a bug or a
misunderstanding on my part.

enjoy,

-jeremy

-- 
========================================================================
 Jeremy Hinegardner                              jeremy at hinegardner.org 

-------------- next part --------------
require 'test/unit'
require 'rubygems'
require 'mongrel'

include Mongrel 
class URIClassifierText < Test::Unit::TestCase
    def test_classifier_order
        u = URIClassifier.new
        root = "/"
        path = "/path"

        u.register(path,1)
        u.register(root,2)

        ["/before", "/way_past"].each do |uri|
            sn,pi,h = u.resolve(uri)
            assert_equal root,sn
            assert_equal uri, pi
            assert_equal 2,h
        end
    end
end


From seanmichaelbrown at gmail.com  Fri Apr 20 12:30:23 2007
From: seanmichaelbrown at gmail.com (Sean Brown)
Date: Fri, 20 Apr 2007 12:30:23 -0400
Subject: [Mongrel] Mongrel cluster log rotation best practices
Message-ID: <1086fb5f0704200930j3c6a07b2q9365aa8ef67a9869@mail.gmail.com>

OK, maybe not even best practices, but at least, tested practices.

>From my reading thus far, it is evident I shouldn't use Rails to
handle mongrel log rotation.  Fine, I'm sold on that.  The advice I'm
seeing says that that one should use an external script to do this.
So my question is, what are people using?  What's working well?
Simple bash scripts or compiled programs like logrotate?

Thanks in advance,

Sean

From jgeiger at gmail.com  Fri Apr 20 12:34:07 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Fri, 20 Apr 2007 11:34:07 -0500
Subject: [Mongrel] Mongrel cluster log rotation best practices
In-Reply-To: <1086fb5f0704200930j3c6a07b2q9365aa8ef67a9869@mail.gmail.com>
References: <1086fb5f0704200930j3c6a07b2q9365aa8ef67a9869@mail.gmail.com>
Message-ID: <466af3440704200934x78ec345dha58e1a853840478@mail.gmail.com>

http://www.atmos.org/2007/3/22/logrotate-and-mongrel


>From my comment:
I was doing something similar, but I've changed to using copytruncate
as well, as I don't really care about losing requests (apache has
them)

# Rails development log:
/web/servers/site/shared/log/development.log {
 copytruncate
 daily
 missingok
 rotate 7
 compress
 delaycompress
}


On 4/20/07, Sean Brown <seanmichaelbrown at gmail.com> wrote:
> OK, maybe not even best practices, but at least, tested practices.
>
> >From my reading thus far, it is evident I shouldn't use Rails to
> handle mongrel log rotation.  Fine, I'm sold on that.  The advice I'm
> seeing says that that one should use an external script to do this.
> So my question is, what are people using?  What's working well?
> Simple bash scripts or compiled programs like logrotate?
>
> Thanks in advance,
>
> Sean
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From randy.antler at screenplayinc.com  Fri Apr 20 18:20:28 2007
From: randy.antler at screenplayinc.com (Randy Antler)
Date: Fri, 20 Apr 2007 15:20:28 -0700
Subject: [Mongrel] Windows Server 2003 - Cygwin - Apache 2.0 - Rails 1.2.3
	-- httpd.so "permission denied"
Message-ID: <483B1F01-0D6A-4C81-BAF3-B44F7B8C2EBB@screenplayinc.com>

I'm new to Rails and Mongrel and I'm trying to get mongrel running  
for the first time.

I'm running Rails 1.2.3 under Cygwin on Windows Server 2003 (SP1)  
with Apache 2.0. The Rails apps works fine when proxied through  
Apache and running under WebRick, but Mongrel seems unhappy about  
something. The Apache service is running as the "Local System" user  
and I'm starting Mongrel as "ISUser" which is an Active Directory user.

When I invoke the following command:

	mongrel_rails start -h

It returns the following error message:

	/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/lib/http11.so:  
Permission denied - /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/ 
lib/http11.so (LoadError)

Can anyone give me any hints as to what I'm doing wrong and/or how to  
correct the problem?

Many thanks in advance!




From luislavena at gmail.com  Fri Apr 20 22:30:14 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 20 Apr 2007 23:30:14 -0300
Subject: [Mongrel] Windows Server 2003 - Cygwin - Apache 2.0 - Rails
	1.2.3 -- httpd.so "permission denied"
In-Reply-To: <483B1F01-0D6A-4C81-BAF3-B44F7B8C2EBB@screenplayinc.com>
References: <483B1F01-0D6A-4C81-BAF3-B44F7B8C2EBB@screenplayinc.com>
Message-ID: <71166b3b0704201930w2ac37b86nd2d6711193e0a817@mail.gmail.com>

On 4/20/07, Randy Antler <randy.antler at screenplayinc.com> wrote:
> I'm new to Rails and Mongrel and I'm trying to get mongrel running
> for the first time.
>
> I'm running Rails 1.2.3 under Cygwin on Windows Server 2003 (SP1)
> with Apache 2.0. The Rails apps works fine when proxied through
> Apache and running under WebRick, but Mongrel seems unhappy about
> something. The Apache service is running as the "Local System" user
> and I'm starting Mongrel as "ISUser" which is an Active Directory user.
>
> When I invoke the following command:
>
>         mongrel_rails start -h
>
> It returns the following error message:
>
>         /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/lib/http11.so:
> Permission denied - /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/
> lib/http11.so (LoadError)
>
> Can anyone give me any hints as to what I'm doing wrong and/or how to
> correct the problem?
>

Hi Randy,

It seems you're using ruby from cygwin, and not mswin32 (wich is
one-click installer or barebones distro from ruby-lang.org)

Those environments, even if they are "win", they aren't the same. The
extension (http11.so) is linked against msvcrt-ruby18.dll (ruby\bin
under mswin32 distro).

On cygwin, that file didn't exist (don't remember right now the equivalent).

What I would suggest is uninstall mswin32 version and compile the
"ruby" version of mongrel:

>gem uninstall mongrel

>gem install mongrel -v 1.0.1
(from the list choose the one with ruby platform).

That will trigger build process for native extension (I guess you have
gcc in your cygwin).

If no error is shown, calling mongrel_rails will work as expected.

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 zedshaw at zedshaw.com  Sat Apr 21 11:46:53 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Sat, 21 Apr 2007 11:46:53 -0400
Subject: [Mongrel] order of registering uri's matters for URIClassifier ?
In-Reply-To: <20070420081502.GC643@hinegardner.org>
References: <20070420081502.GC643@hinegardner.org>
Message-ID: <20070421114653.bb36a56c.zedshaw@zedshaw.com>

On Fri, 20 Apr 2007 02:15:02 -0600
Jeremy Hinegardner <jeremy at hinegardner.org> wrote:

> Hi all,
> 
> I'm playing around with mongrel handlers and I came across a behaviour
> that seems abnormal to me with regard to the Configurator#uri calls.  It
> appears that order matters.

I think this is a misunderstanding in how it works but let me double
check.
 
> I've attached a unit test that shows this effect by calling the
> URIClassifier directly.  I'm not sure if this is a bug or a
> misunderstanding on my part.

Thanks, this is perfect.  I'll take a look and see if it's something.

Oh, could you add this to the Mongrel bug tracker so that I'm
constantly annoyed and have to fix it?  :-)  Thanks.

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

From zedshaw at zedshaw.com  Sat Apr 21 11:48:46 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Sat, 21 Apr 2007 11:48:46 -0400
Subject: [Mongrel] Session problem mongrel behind Apache proxy
In-Reply-To: <F8DBDA77-C19C-4C9E-9B00-8A9E10F2A13F@wantedtech.com>
References: <F8DBDA77-C19C-4C9E-9B00-8A9E10F2A13F@wantedtech.com>
Message-ID: <20070421114846.a8e46d3c.zedshaw@zedshaw.com>

On Tue, 17 Apr 2007 15:44:31 -0400
Nicolas St-Laurent <nstlaurent at wantedtech.com> wrote:

> Hi,
> 
> I've configured mongrel_clusters behind an Apache 2.2 proxy using  
> named virtual host. Session are saved as ActiveRecordSession. But the  
> cookies created on client side doesn't correspond to session data  
> saved in database (keys are different). The RoR app react just like  
> it doesn't have a session at all.
> 
> If I don't use Apache as a proxy/load balancer and call directly  
> Mongrel_cluster, everything works well.
> 
> What should I do to get session working with Mongrel behind an Apache  
> proxy/load balancer ?

Not sure if you've solved this yet, but you can find out what Apache is
sending to Mongrel by doing this:

1) mongrel_rails start -B
2) Make some requests that should have cookies.
3) look in log/mongrel_debug/rails.log for the headers being given to
Mongrel.

That'll give you a clue as to what is going on.

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

From zedshaw at zedshaw.com  Sat Apr 21 11:51:33 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Sat, 21 Apr 2007 11:51:33 -0400
Subject: [Mongrel] a new upload progress bar
In-Reply-To: <21ee31950704020334x28eb96b2t2c6f2458d7823ed9@mail.gmail.com>
References: <21ee31950704020334x28eb96b2t2c6f2458d7823ed9@mail.gmail.com>
Message-ID: <20070421115133.faf60f9d.zedshaw@zedshaw.com>

On Mon, 2 Apr 2007 12:34:06 +0200
"Ry Dahl" <ry at tinyclouds.org> wrote:

> I'm modifying techno weenie's progress bar plug-in. Currently it works
> by making the browser poll the server, via AJAX, for updates on amount
> received. My plug-in provides a handler which will stream updates on
> the amount received, thus only one request needs to be made. Also, the
> progress can be updated at faster rates since the client doesn't need
> to poll. This should reduce loads on both server and client.

Hey Ry, are there any updates on this?  There's a lighttpd plugin as
well that Jan (lighttpd author) is working on.  He's talking about
standardizing.

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

From jeremy at hinegardner.org  Sat Apr 21 13:04:20 2007
From: jeremy at hinegardner.org (Jeremy Hinegardner)
Date: Sat, 21 Apr 2007 11:04:20 -0600
Subject: [Mongrel] order of registering uri's matters for URIClassifier ?
In-Reply-To: <20070421114653.bb36a56c.zedshaw@zedshaw.com>
References: <20070420081502.GC643@hinegardner.org>
	<20070421114653.bb36a56c.zedshaw@zedshaw.com>
Message-ID: <20070421170420.GJ643@hinegardner.org>

On Sat, Apr 21, 2007 at 11:46:53AM -0400, Zed A. Shaw wrote:
> On Fri, 20 Apr 2007 02:15:02 -0600
> Jeremy Hinegardner <jeremy at hinegardner.org> wrote:
> 
> > Hi all,
> > 
> > I'm playing around with mongrel handlers and I came across a behaviour
> > that seems abnormal to me with regard to the Configurator#uri calls.  It
> > appears that order matters.
> 
> I think this is a misunderstanding in how it works but let me double
> check.

Thanks, I wasn't sure if this was a misunderstanding on my part or an
actual bug.


> > I've attached a unit test that shows this effect by calling the
> > URIClassifier directly.  I'm not sure if this is a bug or a
> > misunderstanding on my part.
> 
> Thanks, this is perfect.  I'll take a look and see if it's something.
> 
> Oh, could you add this to the Mongrel bug tracker so that I'm
> constantly annoyed and have to fix it?  :-)  Thanks.

Its in the Mongrel bug tracker now.

enjoy,

-jeremy

-- 
========================================================================
 Jeremy Hinegardner                              jeremy at hinegardner.org 


From tve at rightscale.com  Sun Apr 22 12:41:07 2007
From: tve at rightscale.com (Thorsten von Eicken)
Date: Sun, 22 Apr 2007 09:41:07 -0700
Subject: [Mongrel] request_ends callback
Message-ID: <462B9023.2010403@rightscale.com>

I'm putting together a file upload server using the merb upload progress 
stuff (nice!) and I wish there was a request_ends callback. Why? I need 
to do some processing of the file after the upload (like pushing it to 
Amazon S3 in the back) and I'd like to continue providing user feedback 
through the progress HTTP requests The nicest way to do that would be to 
leverage the UploadProgress class since it has an instance for the 
specific upload_id. However, before my merb process handler gets called, 
the UploadProgress is deleted. I'd be glad to insert a request_ends 
callback into mongrel itself, but I'm not sure where to hook it. Would 
HttpServer#process_client right after the "handlers.each do" be a good spot?
Thanks for an awesome web server!
- Thorsten

From straightflush at gmail.com  Mon Apr 23 10:49:18 2007
From: straightflush at gmail.com (straightflush at gmail.com)
Date: Mon, 23 Apr 2007 10:49:18 -0400
Subject: [Mongrel] mongrel in production not using AR Sessions
Message-ID: <d9cab5bb0704230749k406a0f17q74b425f5d77b2cf4@mail.gmail.com>

Hello,

 For some reason when i change the "environments" line in
mongrel_cluster.yml to use production, ActiveRecord Sessions stop working.
Changing this line to development yield the correct result.  Entries in
database.yml are correct, and confirmed that the sessions table exists in
both environments and that production is indeed working
(production.logbeing filled up).

 Any idea why this would happen ?

Thanks
 Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070423/10aa09de/attachment-0001.html 

From njvack at wisc.edu  Mon Apr 23 11:20:19 2007
From: njvack at wisc.edu (Nathan Vack)
Date: Mon, 23 Apr 2007 10:20:19 -0500
Subject: [Mongrel] mongrel in production not using AR Sessions
In-Reply-To: <d9cab5bb0704230749k406a0f17q74b425f5d77b2cf4@mail.gmail.com>
References: <d9cab5bb0704230749k406a0f17q74b425f5d77b2cf4@mail.gmail.com>
Message-ID: <3673F43F-E4FA-429C-B083-038EF990C065@wisc.edu>

Are session entries being created in the table? Is your  
config.action_controller.session_store = :active_record_store line  
somehow restricted to development? Does setting the environment as an  
env variable or forcing it in production in environment.rb change  
things?

What happens if you clone the dev database to the production  
database? (of course, do this only on your dev box ;-)

Does it work with Webrick?

-Nate

On Apr 23, 2007, at 9:49 AM, straightflush at gmail.com wrote:

> Hello,
>
> For some reason when i change the "environments" line in
> mongrel_cluster.yml to use production, ActiveRecord Sessions stop  
> working.
> Changing this line to development yield the correct result.   
> Entries in
> database.yml are correct, and confirmed that the sessions table  
> exists in
> both environments and that production is indeed working
> (production.logbeing filled up).
>
> Any idea why this would happen ?
>
> Thanks
> Adam
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From pete at nextengine.com  Mon Apr 23 20:33:31 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Mon, 23 Apr 2007 17:33:31 -0700
Subject: [Mongrel] Passing environment to mongrel apps
Message-ID: <495BDE92-C96A-4600-88AE-99900EE1FC1F@nextengine.com>

Hi guys,

I'm looking for a way to pass environment variables to my Rails app  
via Mongrel.  I want to conditionally execute code in environment.rb  
based on these environment variables.

Background:

1. I have some special stuff I want to do when my Rails app first starts
2. So, stuff it in environment.rb in after_initialize, right?
3. Not this time.  I have several other background processes that  
include environment.rb, but shouldn't run this code.

Some other background:

I'm using lighttpd, mongrel, and mongrel_cluster

If there's not a way to do this, I can fallback on having all the  
background processes set an environment variable, but this doesn't  
seem as clean.

Thanks for the help!
Pete


From ufuk at pilli.com  Tue Apr 24 07:30:11 2007
From: ufuk at pilli.com (ufuk kocolu)
Date: Tue, 24 Apr 2007 14:30:11 +0300
Subject: [Mongrel] Passing environment to mongrel apps
In-Reply-To: <495BDE92-C96A-4600-88AE-99900EE1FC1F@nextengine.com>
References: <495BDE92-C96A-4600-88AE-99900EE1FC1F@nextengine.com>
Message-ID: <462DEA43.6010802@pilli.com>

I needed the same thing, if you are on linux just use

export ENV_NAME=value; mongrel_rails start



Pete DeLaurentis wrote:
> Hi guys,
>
> I'm looking for a way to pass environment variables to my Rails app  
> via Mongrel.  I want to conditionally execute code in environment.rb  
> based on these environment variables.
>
> Background:
>
> 1. I have some special stuff I want to do when my Rails app first starts
> 2. So, stuff it in environment.rb in after_initialize, right?
> 3. Not this time.  I have several other background processes that  
> include environment.rb, but shouldn't run this code.
>
> Some other background:
>
> I'm using lighttpd, mongrel, and mongrel_cluster
>
> If there's not a way to do this, I can fallback on having all the  
> background processes set an environment variable, but this doesn't  
> seem as clean.
>
> Thanks for the help!
> Pete
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>   


From pete at nextengine.com  Tue Apr 24 14:43:25 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Tue, 24 Apr 2007 11:43:25 -0700
Subject: [Mongrel] Passing environment to mongrel apps
In-Reply-To: <462DEA43.6010802@pilli.com>
References: <495BDE92-C96A-4600-88AE-99900EE1FC1F@nextengine.com>
	<462DEA43.6010802@pilli.com>
Message-ID: <0A572812-D595-4A20-AB7C-4C4691ED7751@nextengine.com>

Thanks!  That did the trick.  I ended up wrapping it in a new bash  
shell, so the environment variable wouldn't leak out to the other  
scripts I start afterward.

bash -c "ENV_NAME=value; mongrel_rails cluster::start"

Appreciate the help,
Pete

On Apr 24, 2007, at 4:30 AM, ufuk kocolu wrote:

> I needed the same thing, if you are on linux just use
>
> export ENV_NAME=value; mongrel_rails start
>
>
>
> Pete DeLaurentis wrote:
>> Hi guys,
>>
>> I'm looking for a way to pass environment variables to my Rails app
>> via Mongrel.  I want to conditionally execute code in environment.rb
>> based on these environment variables.
>>
>> Background:
>>
>> 1. I have some special stuff I want to do when my Rails app first  
>> starts
>> 2. So, stuff it in environment.rb in after_initialize, right?
>> 3. Not this time.  I have several other background processes that
>> include environment.rb, but shouldn't run this code.
>>
>> Some other background:
>>
>> I'm using lighttpd, mongrel, and mongrel_cluster
>>
>> If there's not a way to do this, I can fallback on having all the
>> background processes set an environment variable, but this doesn't
>> seem as clean.
>>
>> Thanks for the help!
>> Pete
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>>
>>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From terry.reese at oregonstate.edu  Wed Apr 25 02:04:57 2007
From: terry.reese at oregonstate.edu (Reese, Terry)
Date: Tue, 24 Apr 2007 23:04:57 -0700
Subject: [Mongrel] Session problem mongrel behind Apache proxy
Message-ID: <1454CCD2A8D4B74F9EEE8CB68C891CC9254710@NWS-EXCH3.nws.oregonstate.edu>

> Hi,
> 
> I've configured mongrel_clusters behind an Apache 2.2 proxy using  
> named virtual host. Session are saved as ActiveRecordSession. But the  
> cookies created on client side doesn't correspond to session data  
> saved in database (keys are different). The RoR app react just like  
> it doesn't have a session at all.
> 
> If I don't use Apache as a proxy/load balancer and call directly  
> Mongrel_cluster, everything works well.
> 
> What should I do to get session working with Mongrel behind an Apache  
> proxy/load balancer ?
 
I'm curious -- did you find a solution to this problem.  We have recently moved from a single mongrel thread to a placing mongrel behind Apache's load balancer and we are running into the same problem -- the initial request to the application initiates a session, but subsequent requests fail because the session data is empty.  Like you, if we don't use the load balancer it works fine.
 
--TR
 
*******************************************
Terry Reese
Cataloger for Networked Resources
Digital Production Unit Head
Oregon State University Libraries
Corvallis, OR  97331
tel: 541-737-6384
email: terry.reese at oregonstate.edu
http: http://oregonstate.edu/~reeset
*******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070424/b66b9866/attachment.html 

From ry at tinyclouds.org  Wed Apr 25 11:30:18 2007
From: ry at tinyclouds.org (Ry Dahl)
Date: Wed, 25 Apr 2007 17:30:18 +0200
Subject: [Mongrel] a new upload progress bar
In-Reply-To: <20070421115133.faf60f9d.zedshaw@zedshaw.com>
References: <21ee31950704020334x28eb96b2t2c6f2458d7823ed9@mail.gmail.com>
	<20070421115133.faf60f9d.zedshaw@zedshaw.com>
Message-ID: <21ee31950704250830w3377fefbg9a204bc0fba37a8f@mail.gmail.com>

I've just seen this too and I think it's a better way to go: sending
JSON instead updates instead of js function calls.

Note, it appears that the lighty plug-in does not stream this
response: you are still required to poll the server for each update.

Status: I've been idly toying with the idea of prototype.js executing
a streamed response from an XMLHttpRequest call (to avoid the use of
iframes; but I can't seem to get it to work with Safari YET) I plan on
changing both my mongrel plug-in and prototype code to send/receive
JSON instead of javascript functions now.

ry

From seanmichaelbrown at gmail.com  Wed Apr 25 12:08:58 2007
From: seanmichaelbrown at gmail.com (Sean Brown)
Date: Wed, 25 Apr 2007 12:08:58 -0400
Subject: [Mongrel] Session problem mongrel behind Apache proxy
In-Reply-To: <1454CCD2A8D4B74F9EEE8CB68C891CC9254710@NWS-EXCH3.nws.oregonstate.edu>
References: <1454CCD2A8D4B74F9EEE8CB68C891CC9254710@NWS-EXCH3.nws.oregonstate.edu>
Message-ID: <1086fb5f0704250908u48ccc28bvf0771e572505cbae@mail.gmail.com>

On 4/25/07, Reese, Terry <terry.reese at oregonstate.edu> wrote:
> > Hi,
> >
> > I've configured mongrel_clusters behind an Apache 2.2 proxy using
> > named virtual host. Session are saved as ActiveRecordSession. But the
> > cookies created on client side doesn't correspond to session data
> > saved in database (keys are different). The RoR app react just like
> > it doesn't have a session at all.
> >
> > If I don't use Apache as a proxy/load balancer and call directly
> > Mongrel_cluster, everything works well.
> >
> > What should I do to get session working with Mongrel behind an Apache
> > proxy/load balancer ?
>
> I'm curious -- did you find a solution to this problem.  We have recently
> moved from a single mongrel thread to a placing mongrel behind Apache's load
> balancer and we are running into the same problem -- the initial request to
> the application initiates a session, but subsequent requests fail because
> the session data is empty.  Like you, if we don't use the load balancer it
> works fine.


We've been working with the exact situation you both outline above,
but we've had no issues like you've described.  To be clear, we've
got:

6 mongrels (clustered)
Apache 2.2 proxying and load balancing, (as well as handling the static content)

Would you mind posting your Apache Virtual Host block?  My guess is a
misconfiguration there.

Sean

From terry.reese at oregonstate.edu  Wed Apr 25 12:18:50 2007
From: terry.reese at oregonstate.edu (Reese, Terry)
Date: Wed, 25 Apr 2007 09:18:50 -0700
Subject: [Mongrel] Session problem mongrel behind Apache proxy
In-Reply-To: <1086fb5f0704250908u48ccc28bvf0771e572505cbae@mail.gmail.com>
References: <1454CCD2A8D4B74F9EEE8CB68C891CC9254710@NWS-EXCH3.nws.oregonstate.edu>
	<1086fb5f0704250908u48ccc28bvf0771e572505cbae@mail.gmail.com>
Message-ID: <1454CCD2A8D4B74F9EEE8CB68C891CC92F36EC@NWS-EXCH3.nws.oregonstate.edu>

Could be -- this is the first time using the balancer with Mongrel so
something could be out of wack.  Anyway, here's the Virtual Host code
block.

Thanks, 

--TR

# Virtual Hosts
#
# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most
configurations
# use only name-based virtual hosts so the server doesn't need to worry
about
# IP addresses. This is indicated by the asterisks in the directives
below.
#
# Please see the documentation at
# <URL:http://httpd.apache.org/docs/2.2/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# Use name-based virtual hosting.
#
NameVirtualHost 128.193.xxx.xx:80

<VirtualHost 128.193.xxx.xx:80>
  SetEnv RAILS_ENV production
  ServerName search3.library.oregonstate.edu
  ServerAdmin terry.reese at oregonstate.edu
  DocumentRoot /usr/local/apache-lf3/rails/public/
  ErrorLog /usr/local/apache-lf3/rails/log/error.log
  CustomLog /usr/local/apache-lf3/rails/log/access.log common

  RewriteEngine On
  RewriteRule ^(.*/)?.svn/ - [F,L]

  ProxyPass /images/ !
  ProxyPass /stylesheets/ !
  ProxyPass /javascripts/ !
  ProxyPass /error/ !
  ProxyPass /icons/ !
  ProxyPass / balancer://libraryfind/
  ProxyPassReverse / balancer://libraryfind/
  ProxyPreserveHost On

  <Proxy balancer://libraryfind>
     BalancerMember http://127.0.0.1:4010
     BalancerMember http://127.0.0.1:4011
     BalancerMember http://127.0.0.1:4012
     BalancerMember http://127.0.0.1:4013
     BalancerMember http://127.0.0.1:4014
  </Proxy>

  <Directory "/usr/local/apache-lf3/rails/public">
     Options +FollowSymlinks +ExecCGI
     AllowOverride All
     Order allow,deny
     Allow from all
  </Directory>

  ErrorDocument 500 "<h2>Application error</h2>Rails application failed
to start properly"
  ErrorDocument 502 "<h2>Application error</h2>Unable to talk to
back-end service"

</VirtualHost>



> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org 
> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Sean Brown
> Sent: Wednesday, April 25, 2007 9:09 AM
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] Session problem mongrel behind Apache proxy
> 
> On 4/25/07, Reese, Terry <terry.reese at oregonstate.edu> wrote:
> > > Hi,
> > >
> > > I've configured mongrel_clusters behind an Apache 2.2 proxy using 
> > > named virtual host. Session are saved as ActiveRecordSession. But 
> > > the cookies created on client side doesn't correspond to session 
> > > data saved in database (keys are different). The RoR app 
> react just 
> > > like it doesn't have a session at all.
> > >
> > > If I don't use Apache as a proxy/load balancer and call directly 
> > > Mongrel_cluster, everything works well.
> > >
> > > What should I do to get session working with Mongrel behind an 
> > > Apache proxy/load balancer ?
> >
> > I'm curious -- did you find a solution to this problem.  We have 
> > recently moved from a single mongrel thread to a placing mongrel 
> > behind Apache's load balancer and we are running into the 
> same problem 
> > -- the initial request to the application initiates a session, but 
> > subsequent requests fail because the session data is empty. 
>  Like you, 
> > if we don't use the load balancer it works fine.
> 
> 
> We've been working with the exact situation you both outline 
> above, but we've had no issues like you've described.  To be 
> clear, we've
> got:
> 
> 6 mongrels (clustered)
> Apache 2.2 proxying and load balancing, (as well as handling 
> the static content)
> 
> Would you mind posting your Apache Virtual Host block?  My 
> guess is a misconfiguration there.
> 
> Sean
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 

From randy.antler at screenplayinc.com  Wed Apr 25 13:51:38 2007
From: randy.antler at screenplayinc.com (Randy Antler)
Date: Wed, 25 Apr 2007 10:51:38 -0700
Subject: [Mongrel] Windows Server 2003 - Cygwin - Apache 2.0 -
 Rails	1.2.3 -- httpd.so "permission denied" (Luis Lavena)
In-Reply-To: <mailman.75.1177339766.31315.mongrel-users@rubyforge.org>
References: <mailman.75.1177339766.31315.mongrel-users@rubyforge.org>
Message-ID: <462F952A.1060007@screenplayinc.com>

Thank you very much Luis. After re-installing Mongrel and related gems 
and selecting "Ruby" rather than "win32", mongrel appears to be working 
fine!
> Date: Fri, 20 Apr 2007 23:30:14 -0300
> From: "Luis Lavena" <luislavena at gmail.com>
>
> Hi Randy,
>
> It seems you're using ruby from cygwin, and not mswin32 (wich is
> one-click installer or barebones distro from ruby-lang.org)
>
> Those environments, even if they are "win", they aren't the same. The
> extension (http11.so) is linked against msvcrt-ruby18.dll (ruby\bin
> under mswin32 distro).
>
> On cygwin, that file didn't exist (don't remember right now the equivalent).
>
> What I would suggest is uninstall mswin32 version and compile the
> "ruby" version of mongrel:

-- 
Randy Antler
Director of Information Systems
(800) 742-1439 x 104


From terry.reese at oregonstate.edu  Wed Apr 25 20:09:19 2007
From: terry.reese at oregonstate.edu (Reese, Terry)
Date: Wed, 25 Apr 2007 17:09:19 -0700
Subject: [Mongrel] Session problem mongrel behind Apache proxy
In-Reply-To: <1086fb5f0704250908u48ccc28bvf0771e572505cbae@mail.gmail.com>
References: <1454CCD2A8D4B74F9EEE8CB68C891CC9254710@NWS-EXCH3.nws.oregonstate.edu>
	<1086fb5f0704250908u48ccc28bvf0771e572505cbae@mail.gmail.com>
Message-ID: <1454CCD2A8D4B74F9EEE8CB68C891CC92F38C4@NWS-EXCH3.nws.oregonstate.edu>

Just an FYI -- the problem solved itself by moving away from
ActiveRecord and using either memcache or SqlSession.

Thanks, 

--TR 

> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org 
> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Sean Brown
> Sent: Wednesday, April 25, 2007 9:09 AM
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] Session problem mongrel behind Apache proxy
> 
> On 4/25/07, Reese, Terry <terry.reese at oregonstate.edu> wrote:
> > > Hi,
> > >
> > > I've configured mongrel_clusters behind an Apache 2.2 proxy using 
> > > named virtual host. Session are saved as ActiveRecordSession. But 
> > > the cookies created on client side doesn't correspond to session 
> > > data saved in database (keys are different). The RoR app 
> react just 
> > > like it doesn't have a session at all.
> > >
> > > If I don't use Apache as a proxy/load balancer and call directly 
> > > Mongrel_cluster, everything works well.
> > >
> > > What should I do to get session working with Mongrel behind an 
> > > Apache proxy/load balancer ?
> >
> > I'm curious -- did you find a solution to this problem.  We have 
> > recently moved from a single mongrel thread to a placing mongrel 
> > behind Apache's load balancer and we are running into the 
> same problem 
> > -- the initial request to the application initiates a session, but 
> > subsequent requests fail because the session data is empty. 
>  Like you, 
> > if we don't use the load balancer it works fine.
> 
> 
> We've been working with the exact situation you both outline 
> above, but we've had no issues like you've described.  To be 
> clear, we've
> got:
> 
> 6 mongrels (clustered)
> Apache 2.2 proxying and load balancing, (as well as handling 
> the static content)
> 
> Would you mind posting your Apache Virtual Host block?  My 
> guess is a misconfiguration there.
> 
> Sean
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 

From herryanto at gmail.com  Thu Apr 26 00:49:05 2007
From: herryanto at gmail.com (Herryanto Siatono)
Date: Thu, 26 Apr 2007 12:49:05 +0800
Subject: [Mongrel] Win32 service - Errno::EINVAL (Invalid argument) when
	uploading image file
Message-ID: <002d01c787be$39cb9dd0$4e01a8c0@herrypc>

Hi guys,

I'm facing an error trying to run my app as mongrel_service, hope those who
have faced similar issue can help to shed some lights. 

The app was fine when running from console, but when running it as a
service, it failed when I try to upload 'image file', it has no issue
uploading other types of files. 

Environment:
------------
mongrel (1.0.1, 0.3.13.3)
mongrel_service (0.3.1)
rmagick (1.13.0)
ruby (1.8.5)
rails (1.2.3)
Tested on Windows XP and Windows 2003 server

Error Message:
--------------
Errno::EINVAL (Invalid argument):
    e:/ruby/lib/ruby/1.8/base64.rb:114:in `write'
    e:/ruby/lib/ruby/1.8/base64.rb:114:in `print'
    e:/ruby/lib/ruby/1.8/base64.rb:114:in `b64encode'
    e:/ruby/lib/ruby/1.8/base64.rb:113:in `scan'
    e:/ruby/lib/ruby/1.8/base64.rb:113:in `b64encode'
    /app/models/asset.rb:110:in `with_image'
    /app/models/asset.rb:100:in `crop_image_size'
    /vendor/rails/activerecord/lib/active_record/callbacks.rb:337:in `send'
    /vendor/rails/activerecord/lib/active_record/callbacks.rb:337:in
`callback'
    /vendor/rails/activerecord/lib/active_record/callbacks.rb:334:in `each'
    /vendor/rails/activerecord/lib/active_record/callbacks.rb:334:in
`callback'
    /vendor/rails/activerecord/lib/active_record/callbacks.rb:242:in
`create_or_update'
    /vendor/rails/activerecord/lib/active_record/base.rb:1617:in
`save_without_validation'
    /vendor/rails/activerecord/lib/active_record/validations.rb:810:in
`save_without_transactions'
    /vendor/rails/activerecord/lib/active_record/transactions.rb:105:in
`save'
    ....

 
/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/da
tabase_statements.rb:59:in `transaction'
    /vendor/rails/activerecord/lib/active_record/query_cache.rb:66:in `send'
Parameters: 

{"project_id"=>"1",
 "commit"=>"Upload file",
 "attachment"=>{"0"=>{"private"=>"0",
 "category_id"=>"",
 "description"=>"",
 "file"=>#<File:C:/WINDOWS/TEMP/CGI.5020.0>}}}

Service command:
----------------
"e:/ruby/bin/mongrel_service.exe" single -e production -p 4000 -a 0.0.0.0 -l
"log/mongrel.log" -P "log/mongrel.pid" -c "D:/rubywork/[appname]" -t 0 -r
"public" -n 1024

Not sure if it was access right issue as service runs as System account, but
I tried running the service in the console yet I'm getting the same error
message

Service console command:
-----------------------
> mongrel console single -e production -p 4000 -l -c "D:/rubywork/[appname]"


No error message shown on the console, log/mongrel.log file was not there as
well.


Thanks in advance.

Sincerely,

Herryanto Siatono


From luislavena at gmail.com  Thu Apr 26 02:20:47 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 26 Apr 2007 06:20:47 +0000
Subject: [Mongrel] Win32 service - Errno::EINVAL (Invalid argument) when
	uploading image file
In-Reply-To: <002d01c787be$39cb9dd0$4e01a8c0@herrypc>
References: <002d01c787be$39cb9dd0$4e01a8c0@herrypc>
Message-ID: <71166b3b0704252320s5f5a3458wd9da4434ce468d03@mail.gmail.com>

On 4/26/07, Herryanto Siatono <herryanto at gmail.com> wrote:
> Hi guys,
>
> I'm facing an error trying to run my app as mongrel_service, hope those who
> have faced similar issue can help to shed some lights.
>
> The app was fine when running from console, but when running it as a
> service, it failed when I try to upload 'image file', it has no issue
> uploading other types of files.
>
> Environment:
> ------------
> mongrel (1.0.1, 0.3.13.3)
> mongrel_service (0.3.1)
> rmagick (1.13.0)
> ruby (1.8.5)
> rails (1.2.3)
> Tested on Windows XP and Windows 2003 server
>
> Error Message:
> --------------
> Errno::EINVAL (Invalid argument):
>     e:/ruby/lib/ruby/1.8/base64.rb:114:in `write'
>     e:/ruby/lib/ruby/1.8/base64.rb:114:in `print'
>     e:/ruby/lib/ruby/1.8/base64.rb:114:in `b64encode'
>     e:/ruby/lib/ruby/1.8/base64.rb:113:in `scan'
>     e:/ruby/lib/ruby/1.8/base64.rb:113:in `b64encode'
>     /app/models/asset.rb:110:in `with_image'
>     /app/models/asset.rb:100:in `crop_image_size'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:337:in `send'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:337:in
> `callback'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:334:in `each'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:334:in
> `callback'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:242:in
> `create_or_update'
>     /vendor/rails/activerecord/lib/active_record/base.rb:1617:in
> `save_without_validation'
>     /vendor/rails/activerecord/lib/active_record/validations.rb:810:in
> `save_without_transactions'
>     /vendor/rails/activerecord/lib/active_record/transactions.rb:105:in
> `save'
>     ....
>
>
> /vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/da
> tabase_statements.rb:59:in `transaction'
>     /vendor/rails/activerecord/lib/active_record/query_cache.rb:66:in `send'
> Parameters:
>
> {"project_id"=>"1",
>  "commit"=>"Upload file",
>  "attachment"=>{"0"=>{"private"=>"0",
>  "category_id"=>"",
>  "description"=>"",
>  "file"=>#<File:C:/WINDOWS/TEMP/CGI.5020.0>}}}
>

What plugin are you using to manage attachments?

Also, is Ruby bin directory (e:/ruby/bin) in your path?

> Service command:
> ----------------
> "e:/ruby/bin/mongrel_service.exe" single -e production -p 4000 -a 0.0.0.0 -l
> "log/mongrel.log" -P "log/mongrel.pid" -c "D:/rubywork/[appname]" -t 0 -r
> "public" -n 1024
>
> Not sure if it was access right issue as service runs as System account, but
> I tried running the service in the console yet I'm getting the same error
> message
>

You get the same temporary file location? current user should store
temps into C:\Documents and Settings\[username]\Local Settings\Temp

Trying to write to C:\Windows\Temp could raise a LUA bug (Limited User Account).

Also, since you mention RMagick, are binaries (dlls) of ImageMagick in the path?

> Service console command:
> -----------------------
> > mongrel console single -e production -p 4000 -l -c "D:/rubywork/[appname]"
>
>
> No error message shown on the console, log/mongrel.log file was not there as
> well.
>

Blame me for that, current version lacks logging. We are cooking the
replacement which solve that issue.

After running mongrel_service console, the log/production.log file
shows the same error you listed before, right?

What are your privileges as user in the computers you're testing?
Normal (Power User), restrictred (User) or administrator?

-- 
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 herryanto at gmail.com  Fri Apr 27 01:52:32 2007
From: herryanto at gmail.com (Herryanto Siatono)
Date: Fri, 27 Apr 2007 13:52:32 +0800
Subject: [Mongrel] Win32 service - Errno::EINVAL (Invalid argument)
	whenuploading image file
In-Reply-To: <71166b3b0704252320s5f5a3458wd9da4434ce468d03@mail.gmail.com>
Message-ID: <005401c78890$412a7c40$4e01a8c0@herrypc>

Louis,

Thanks for your prompt reply. Yeah, that's the error log that I got in the
log file.

I'm running as Administrator. I've been cracking my head for days, hopefully
will be able to find a solution for this.

Herry

-----Original Message-----
From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis Lavena
Sent: 26 April 2007 14:21
To: mongrel-users at rubyforge.org
Subject: Re: [Mongrel] Win32 service - Errno::EINVAL (Invalid argument)
whenuploading image file

On 4/26/07, Herryanto Siatono <herryanto at gmail.com> wrote:
> Hi guys,
>
> I'm facing an error trying to run my app as mongrel_service, hope those
who
> have faced similar issue can help to shed some lights.
>
> The app was fine when running from console, but when running it as a
> service, it failed when I try to upload 'image file', it has no issue
> uploading other types of files.
>
> Environment:
> ------------
> mongrel (1.0.1, 0.3.13.3)
> mongrel_service (0.3.1)
> rmagick (1.13.0)
> ruby (1.8.5)
> rails (1.2.3)
> Tested on Windows XP and Windows 2003 server
>
> Error Message:
> --------------
> Errno::EINVAL (Invalid argument):
>     e:/ruby/lib/ruby/1.8/base64.rb:114:in `write'
>     e:/ruby/lib/ruby/1.8/base64.rb:114:in `print'
>     e:/ruby/lib/ruby/1.8/base64.rb:114:in `b64encode'
>     e:/ruby/lib/ruby/1.8/base64.rb:113:in `scan'
>     e:/ruby/lib/ruby/1.8/base64.rb:113:in `b64encode'
>     /app/models/asset.rb:110:in `with_image'
>     /app/models/asset.rb:100:in `crop_image_size'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:337:in
`send'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:337:in
> `callback'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:334:in
`each'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:334:in
> `callback'
>     /vendor/rails/activerecord/lib/active_record/callbacks.rb:242:in
> `create_or_update'
>     /vendor/rails/activerecord/lib/active_record/base.rb:1617:in
> `save_without_validation'
>     /vendor/rails/activerecord/lib/active_record/validations.rb:810:in
> `save_without_transactions'
>     /vendor/rails/activerecord/lib/active_record/transactions.rb:105:in
> `save'
>     ....
>
>
>
/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/da
> tabase_statements.rb:59:in `transaction'
>     /vendor/rails/activerecord/lib/active_record/query_cache.rb:66:in
`send'
> Parameters:
>
> {"project_id"=>"1",
>  "commit"=>"Upload file",
>  "attachment"=>{"0"=>{"private"=>"0",
>  "category_id"=>"",
>  "description"=>"",
>  "file"=>#<File:C:/WINDOWS/TEMP/CGI.5020.0>}}}
>

What plugin are you using to manage attachments?

Also, is Ruby bin directory (e:/ruby/bin) in your path?

> Service command:
> ----------------
> "e:/ruby/bin/mongrel_service.exe" single -e production -p 4000 -a 0.0.0.0
-l
> "log/mongrel.log" -P "log/mongrel.pid" -c "D:/rubywork/[appname]" -t 0 -r
> "public" -n 1024
>
> Not sure if it was access right issue as service runs as System account,
but
> I tried running the service in the console yet I'm getting the same error
> message
>

You get the same temporary file location? current user should store
temps into C:\Documents and Settings\[username]\Local Settings\Temp

Trying to write to C:\Windows\Temp could raise a LUA bug (Limited User
Account).

Also, since you mention RMagick, are binaries (dlls) of ImageMagick in the
path?

> Service console command:
> -----------------------
> > mongrel console single -e production -p 4000 -l -c
"D:/rubywork/[appname]"
>
>
> No error message shown on the console, log/mongrel.log file was not there
as
> well.
>

Blame me for that, current version lacks logging. We are cooking the
replacement which solve that issue.

After running mongrel_service console, the log/production.log file
shows the same error you listed before, right?

What are your privileges as user in the computers you're testing?
Normal (Power User), restrictred (User) or administrator?

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


From luislavena at gmail.com  Fri Apr 27 07:37:43 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 27 Apr 2007 08:37:43 -0300
Subject: [Mongrel] Win32 service - Errno::EINVAL (Invalid argument)
	whenuploading image file
In-Reply-To: <005401c78890$412a7c40$4e01a8c0@herrypc>
References: <71166b3b0704252320s5f5a3458wd9da4434ce468d03@mail.gmail.com>
	<005401c78890$412a7c40$4e01a8c0@herrypc>
Message-ID: <71166b3b0704270437w3c2a35b1p7f87eb21adba5d02@mail.gmail.com>

On 4/27/07, Herryanto Siatono <herryanto at gmail.com> wrote:
> Louis,
>
> Thanks for your prompt reply. Yeah, that's the error log that I got in the
> log file.
>
> I'm running as Administrator. I've been cracking my head for days, hopefully
> will be able to find a solution for this.
>

Henry,

When you have the time, please provide the inside information needed
to find the true problem.

1) What plugin are you using to manage upload attachments? (since I
see you have a crop_image_size and with_image inside Asset model

2) From the service command line, you have ruby installed in E:\Ruby.
Is this directory in your path? (Open a new console, type PATH and hit
enter, tell me if E:\Ruby is in there).

3) You also tested the service as "console", could you please indicate
the location of the temp file under that situation?

C:\Windows\Temp do not seems right for a process running with
Administrator or any other account credentials.

4) Since you mention RMagick, are ImageMagick binaries in the path too?

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 herryanto at gmail.com  Fri Apr 27 23:54:34 2007
From: herryanto at gmail.com (Herryanto Siatono)
Date: Sat, 28 Apr 2007 11:54:34 +0800
Subject: [Mongrel] Win32 service - Errno::EINVAL (Invalid
	argument)whenuploading image file
In-Reply-To: <71166b3b0704270437w3c2a35b1p7f87eb21adba5d02@mail.gmail.com>
Message-ID: <00ec01c78948$f0bedf80$4e01a8c0@herrypc>

Thanks Luis, btw, I found some hints, it failed when the 'puts' statement
was called. 

That's why the uploading of image failed, while other types are fine, when I
upload an image, I need to crop the image which instead call
Base64.b64encode, in which "puts" was called to display the output on
console.

So I did a simple test, I added puts before the execution of anything, and
it failed exactly at that line:

  def with_image(file_data = nil, &block)
    puts "testing"

    img = Magick::Image::read_inline(Base64.b64encode(file_data ||
self.data)).first
    block.call(img)
    img = nil
    GC.start
  end  


Error message thrown:

#{RAILS_ROOT}/app/models/asset.rb:115:in `write'
#{RAILS_ROOT}/app/models/asset.rb:115:in `puts'
#{RAILS_ROOT}/app/models/asset.rb:115:in `with_image'
#{RAILS_ROOT}/app/models/asset.rb:100:in `crop_image_size'

Now we are getting close, why puts failed when running as windows service?
Note that it works fine when I'm running with "mongrel_rails start"

And here are my answers to your questions. Thanks!

1) What plugin are you using to manage upload attachments? (since I
see you have a crop_image_size and with_image inside Asset model

I'm using rmagick-win32 with ImageMagick installed. Rmagick 1.13.0 and
ImageMagick 6.2.9-3 Q8.

I didn't use any plugin, I developed the file upload handling myself, with
some tricks learned from file_column and acts_as_attachment.

2) From the service command line, you have ruby installed in E:\Ruby.
Is this directory in your path? (Open a new console, type PATH and hit
enter, tell me if E:\Ruby is in there).

"E:\ruby\bin" is there.

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

PATH=E:\Program Files\Windows Resource Kits\Tools\;e:\program
files\imagemagick-6.2.9-q8;e:\ruby\bin;C:\Perl\bin\;C:\WINDOWS\system32;C:\W
INDOWS;C:\WINDOWS\Syst
em32\Wbem;C:\PROGRA~1\ULTRAE~1;C:\Program Files\Common Files\Adaptec
Shared\System;C:\Program Files\Microsoft SQL
Server\80\Tools\BINN;E:\PROGRA~1\ATT\Graphviz\
bin;e:\Program Files\WinSCP3\;e:\Program Files\Subversion\bin;C:\Program
Files\QuickTime\QTSystem\;E:\Program Files\Support
Tools\;D:\jdk\jdk1.5.0_04\bin;C:\Program
Files\CVSNT\;d:\java\apache\apache-ant-1.6.2\bin;D:\java\apache\Maven
1.0.2\bin\;e:\program files\xampp\mysql\bin;c:\php;c:\php-4.4.0;e:\program
files\svn-win32-1.3.1\bin;D:\rubywork\bin;E:\Program Files\Windows Resource
Kits\psexec


3) You also tested the service as "console", could you please indicate
the location of the temp file under that situation? C:\Windows\Temp do not
seems right for a process running with Administrator or any other account
credentials.

Sorry my mistake Luis running service as "console", throwing this message
instead:

{"project_id"=>"1",
 "commit"=>"Upload file",
 "attachment"=>{"0"=>{"private"=>"0",
 "category_id"=>"",
 "description"=>"",
 "file"=>#<File:C:/DOCUME~1/Herry/LOCALS~1/Temp/CGI.1936.0>}}}

While running it as normal windows service, the temp directory is
"c:\windows\temp".

4) Since you mention RMagick, are ImageMagick binaries in the path too?

Yep image magick is in the path. I can run 'convert' command.


From luislavena at gmail.com  Sat Apr 28 00:06:14 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 28 Apr 2007 01:06:14 -0300
Subject: [Mongrel] Win32 service - Errno::EINVAL (Invalid
	argument)whenuploading image file
In-Reply-To: <00ec01c78948$f0bedf80$4e01a8c0@herrypc>
References: <71166b3b0704270437w3c2a35b1p7f87eb21adba5d02@mail.gmail.com>
	<00ec01c78948$f0bedf80$4e01a8c0@herrypc>
Message-ID: <71166b3b0704272106u2fd5ff86m66c38b2cce959e54@mail.gmail.com>

On 4/28/07, Herryanto Siatono <herryanto at gmail.com> wrote:
> Thanks Luis, btw, I found some hints, it failed when the 'puts' statement
> was called.
>
> That's why the uploading of image failed, while other types are fine, when I
> upload an image, I need to crop the image which instead call
> Base64.b64encode, in which "puts" was called to display the output on
> console.
>
> So I did a simple test, I added puts before the execution of anything, and
> it failed exactly at that line:
>
>   def with_image(file_data = nil, &block)
>     puts "testing"
>
>     img = Magick::Image::read_inline(Base64.b64encode(file_data ||
> self.data)).first
>     block.call(img)
>     img = nil
>     GC.start
>   end
>

Let me guess, the line :115 is actually... PUTS!

Err, a big problem with this. Let me explain.

A service, also known on *nix fields as "daemon", by default, lacks a
"console" attached to it. That means STDIN, STDOUT and STDERR.

These default "pipes" are used by sentences like puts, which "write"
data to the console.

Since you're inside a service... you don't have one! :-P

Also, lot of folks will correct me on this: adding puts in your code
for debugging purposes is a bad practice. Instead you should use
logger.debug/info/warn/error to log the event inside the
development/production log files.

So, replace puts "testing" with logger.debug "testing" and that should
work fine since is the only place you're using it ;-)

Anyway, next version of service add a workaround for this "bug by
design" of services.

>
> Now we are getting close, why puts failed when running as windows service?
> Note that it works fine when I'm running with "mongrel_rails start"
>
> And here are my answers to your questions. Thanks!
>
> [...]

Everything looks good, actually :-D

Your feedback allowed you to pinpoint where the problem lies, so you
almost solved the issue by yourself, so thank you instead! ;-)

Regards and good weekend.

-- 
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 herryanto at gmail.com  Sun Apr 29 01:09:34 2007
From: herryanto at gmail.com (Herryanto Siatono)
Date: Sun, 29 Apr 2007 13:09:34 +0800
Subject: [Mongrel] Win32 service - Errno::EINVAL
	(Invalidargument)whenuploading image file
In-Reply-To: <71166b3b0704272106u2fd5ff86m66c38b2cce959e54@mail.gmail.com>
Message-ID: <000001c78a1c$95bb35a0$4e01a8c0@herrypc>

Without your step through, I wouldn't have found it, thanks anyway!

Btw, isn't it a bit harsh to throw an error when puts is called in mongrel
service? Coz sometimes the 'puts' was called by core library, eg. This case
the Base64.

Right now, I'm applying a patch to my app to ignore the stderr/stdout, and
the app works fine now:

class StdOutLogger
  def write(s)
       # do nothing
    end
  end
end
  
before_filter {
  $stdout = $stderr = StdOutLogger.new
}

Was wondering, if there's variable to call to find out if the code is
running on mongrel_service? So I can do simple filtering only to ignore
sterr/out when running as a service.

If not is there a way to pass a variable when starting mongrel_service? I
tried 
mongrel_service console single -c
d:/rubywork/[appname]MONGREL_TYPE='service'

But no luck! :)

Herry

-----Original Message-----
From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis Lavena
Sent: 28 April 2007 12:06
To: mongrel-users at rubyforge.org
Subject: Re: [Mongrel] Win32 service - Errno::EINVAL
(Invalidargument)whenuploading image file

On 4/28/07, Herryanto Siatono <herryanto at gmail.com> wrote:
> Thanks Luis, btw, I found some hints, it failed when the 'puts' statement
> was called.
>
> That's why the uploading of image failed, while other types are fine, when
I
> upload an image, I need to crop the image which instead call
> Base64.b64encode, in which "puts" was called to display the output on
> console.
>
> So I did a simple test, I added puts before the execution of anything, and
> it failed exactly at that line:
>
>   def with_image(file_data = nil, &block)
>     puts "testing"
>
>     img = Magick::Image::read_inline(Base64.b64encode(file_data ||
> self.data)).first
>     block.call(img)
>     img = nil
>     GC.start
>   end
>

Let me guess, the line :115 is actually... PUTS!

Err, a big problem with this. Let me explain.

A service, also known on *nix fields as "daemon", by default, lacks a
"console" attached to it. That means STDIN, STDOUT and STDERR.

These default "pipes" are used by sentences like puts, which "write"
data to the console.

Since you're inside a service... you don't have one! :-P

Also, lot of folks will correct me on this: adding puts in your code
for debugging purposes is a bad practice. Instead you should use
logger.debug/info/warn/error to log the event inside the
development/production log files.

So, replace puts "testing" with logger.debug "testing" and that should
work fine since is the only place you're using it ;-)

Anyway, next version of service add a workaround for this "bug by
design" of services.

>
> Now we are getting close, why puts failed when running as windows service?
> Note that it works fine when I'm running with "mongrel_rails start"
>
> And here are my answers to your questions. Thanks!
>
> [...]

Everything looks good, actually :-D

Your feedback allowed you to pinpoint where the problem lies, so you
almost solved the issue by yourself, so thank you instead! ;-)

Regards and good weekend.

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


From luislavena at gmail.com  Sun Apr 29 01:18:53 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 29 Apr 2007 02:18:53 -0300
Subject: [Mongrel] Win32 service - Errno::EINVAL
	(Invalidargument)whenuploading image file
In-Reply-To: <000001c78a1c$95bb35a0$4e01a8c0@herrypc>
References: <71166b3b0704272106u2fd5ff86m66c38b2cce959e54@mail.gmail.com>
	<000001c78a1c$95bb35a0$4e01a8c0@herrypc>
Message-ID: <71166b3b0704282218t65d3021vd8e282f4b50d21e7@mail.gmail.com>

On 4/29/07, Herryanto Siatono <herryanto at gmail.com> wrote:
> Without your step through, I wouldn't have found it, thanks anyway!
>
> Btw, isn't it a bit harsh to throw an error when puts is called in mongrel
> service? Coz sometimes the 'puts' was called by core library, eg. This case
> the Base64.
>

Well, thats a design flaw, from mongrel_service I must admit, and from
Windows Services too (I'm 100% responsible for this).

Is not the service who thow it, is the ruby interpreter that tried to
write to the standard Out, even if they don't have a valid console
attached.

One workaround is replace ruby.exe with rubyw.exe, which ignores
everything that is console related, but found that brakes the new
service implementation (WiP, not in repository).

> Right now, I'm applying a patch to my app to ignore the stderr/stdout, and
> the app works fine now:
>
> class StdOutLogger
>   def write(s)
>        # do nothing
>     end
>   end
> end
>
> before_filter {
>   $stdout = $stderr = StdOutLogger.new
> }
>
> Was wondering, if there's variable to call to find out if the code is
> running on mongrel_service? So I can do simple filtering only to ignore
> sterr/out when running as a service.
>

The safer solution is redirect STDOUT and STDERR from ruby:

STDOUT.reopen("c:/path/to/log/file.log")

> If not is there a way to pass a variable when starting mongrel_service? I
> tried
> mongrel_service console single -c
> d:/rubywork/[appname]MONGREL_TYPE='service'
>

Currently there isn't. Adding environment variables prior starting
child process is currently in my TODO for new service implementation.

Also, the STDOUT/ERR problem (ala, puts) will be solved too. Must
tweak a few things with x64 platforms and do some testing.

> But no luck! :)
>

I know, I know, shame on me :-P

Regards and good weekend.

-- 
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 jamesmead44 at gmail.com  Sun Apr 29 08:28:09 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Sun, 29 Apr 2007 13:28:09 +0100
Subject: [Mongrel] NoMethodError exceptions
Message-ID: <1db558f00704290528m5fbc6452l2f04ab2fc3915478@mail.gmail.com>

I'm getting the following exceptions when running mongrel_rails. Any ideas
what might be causing the problem?

Error details...

$ mongrel_rails
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel/command.rb:168:in
`run': When creating '': undefined method `downcase' for nil:NilClass
(NoMethodError)
        from /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3
/bin/mongrel_rails:224
        from /opt/local/bin/mongrel_rails:16:in `load'
        from /opt/local/bin/mongrel_rails:16

$ mongrel_rails start
Running Mongrel server in development mode at 0.0.0.0:3000
Server ready.
ERROR(NoMethodError): undefined method `readpartial' for
#<TCPSocket:0x24f2274>
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:352:in
`process_client'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:332:in
`initialize'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:331:in
`timeout'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:331:in
`initialize'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:328:in
`initialize'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:328:in `new'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:328:in
`initialize'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:328:in
`times'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:328:in
`initialize'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/bin/mongrel_rails:166:in
`new'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/bin/mongrel_rails:166:in
`start_mongrel'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/bin/mongrel_rails:181:in
`run'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel/command.rb:183:in
`run'
/opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/bin/mongrel_rails:224
/opt/local/bin/mongrel_rails:16:in `load'
/opt/local/bin/mongrel_rails:16

Environment details...

$ gem list mongrel

*** LOCAL GEMS ***

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

$ gem list gem_plugin

*** LOCAL GEMS ***

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

$ gem list daemons

*** LOCAL GEMS ***

daemons (1.0.4)
    A toolkit to create and control daemons in different ways

$ script/console
Loading development environment.
>> Rails::Info
=> About your application's environment
Ruby version                 1.8.2 (powerpc-darwin8.2.0)
RubyGems version             0.9.2
Rails version                1.0.0
Active Record version        1.13.2
Action Pack version          1.11.2
Action Web Service version   1.0.0
Action Mailer version        1.1.5
Active Support version       1.2.5
Application root             **************
Environment                  development
Database adapter             mysql

Thanks.
-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070429/ed4ca5c8/attachment.html 

From will at hotgazpacho.com  Sun Apr 29 08:46:26 2007
From: will at hotgazpacho.com (Will Green)
Date: Sun, 29 Apr 2007 08:46:26 -0400
Subject: [Mongrel] NoMethodError exceptions
In-Reply-To: <1db558f00704290528m5fbc6452l2f04ab2fc3915478@mail.gmail.com>
References: <1db558f00704290528m5fbc6452l2f04ab2fc3915478@mail.gmail.com>
Message-ID: <463493A2.5000109@hotgazpacho.com>

Upgrade your Mongrel to the latest (1.0.1), and try again.

James Mead wrote:
> I'm getting the following exceptions when running mongrel_rails. Any 
> ideas what might be causing the problem?
> 
> Error details...
> 
> $ mongrel_rails
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel/command.rb:168:in 
> `run': When creating '': undefined method `downcase' for nil:NilClass 
> (NoMethodError)
>         from 
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/bin/mongrel_rails:224
>         from /opt/local/bin/mongrel_rails:16:in `load'
>         from /opt/local/bin/mongrel_rails:16
> 
> $ mongrel_rails start
> Running Mongrel server in development mode at 0.0.0.0:3000 
> <http://0.0.0.0:3000>
> Server ready.
> ERROR(NoMethodError): undefined method `readpartial' for 
> #<TCPSocket:0x24f2274>
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:352:in 
> `process_client'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel- 0.3.3/lib/mongrel.rb:332:in 
> `initialize'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:331:in 
> `timeout'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:331:in 
> `initialize'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:328:in 
> `initialize'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:328:in `new'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel- 0.3.3/lib/mongrel.rb:328:in 
> `initialize'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:328:in 
> `times'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel.rb:328:in 
> `initialize'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/bin/mongrel_rails:166:in 
> `new'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/bin/mongrel_rails:166:in 
> `start_mongrel'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel- 
> 0.3.3/bin/mongrel_rails:181:in `run'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/lib/mongrel/command.rb:183:in 
> `run'
> /opt/local/lib/ruby/gems/1.8/gems/mongrel-0.3.3/bin/mongrel_rails:224
> /opt/local/bin/mongrel_rails:16:in `load'
> /opt/local/bin/mongrel_rails:16
> 
> Environment details...
> 
> $ gem list mongrel      
> 
> *** LOCAL GEMS ***
> 
> mongrel (0.3.3)
>     A small fast HTTP library and server that runs Rails, Camping, and
>     Nitro apps.
> 
> $ gem list gem_plugin
> 
> *** LOCAL GEMS ***
> 
> gem_plugin (0.2.1)
>     A plugin system based only on rubygems that uses dependencies only
> 
> $ gem list daemons
> 
> *** LOCAL GEMS ***
> 
> daemons (1.0.4)
>     A toolkit to create and control daemons in different ways
> 
> $ script/console
> Loading development environment.
>> > Rails::Info
> => About your application's environment
> Ruby version                 1.8.2 (powerpc-darwin8.2.0)
> RubyGems version             0.9.2
> Rails version                1.0.0
> Active Record version        1.13.2
> Action Pack version          1.11.2
> Action Web Service version   1.0.0
> Action Mailer version        1.1.5
> Active Support version       1.2.5
> Application root             **************
> Environment                  development
> Database adapter             mysql
> 
> Thanks.
> -- 
> James.
> http://blog.floehopper.org
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

From herryanto at gmail.com  Sun Apr 29 09:03:13 2007
From: herryanto at gmail.com (Herryanto Siatono)
Date: Sun, 29 Apr 2007 21:03:13 +0800
Subject: [Mongrel] Win32 service -
	Errno::EINVAL(Invalidargument)whenuploading image file
In-Reply-To: <71166b3b0704282218t65d3021vd8e282f4b50d21e7@mail.gmail.com>
Message-ID: <003101c78a5e$c071f080$4e01a8c0@herrypc>


No worries Louis, have been grateful for the existence of Mongrel, glad to
know those few issues are going to be resolved.

Thanks for the safer workaround. And you have a good weekend too.

Herry

-----Original Message-----
From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis Lavena
Sent: 29 April 2007 13:19
To: mongrel-users at rubyforge.org
Subject: Re: [Mongrel] Win32 service -
Errno::EINVAL(Invalidargument)whenuploading image file

On 4/29/07, Herryanto Siatono <herryanto at gmail.com> wrote:
> Without your step through, I wouldn't have found it, thanks anyway!
>
> Btw, isn't it a bit harsh to throw an error when puts is called in mongrel
> service? Coz sometimes the 'puts' was called by core library, eg. This
case
> the Base64.
>

Well, thats a design flaw, from mongrel_service I must admit, and from
Windows Services too (I'm 100% responsible for this).

Is not the service who thow it, is the ruby interpreter that tried to
write to the standard Out, even if they don't have a valid console
attached.

One workaround is replace ruby.exe with rubyw.exe, which ignores
everything that is console related, but found that brakes the new
service implementation (WiP, not in repository).

> Right now, I'm applying a patch to my app to ignore the stderr/stdout, and
> the app works fine now:
>
> class StdOutLogger
>   def write(s)
>        # do nothing
>     end
>   end
> end
>
> before_filter {
>   $stdout = $stderr = StdOutLogger.new
> }
>
> Was wondering, if there's variable to call to find out if the code is
> running on mongrel_service? So I can do simple filtering only to ignore
> sterr/out when running as a service.
>

The safer solution is redirect STDOUT and STDERR from ruby:

STDOUT.reopen("c:/path/to/log/file.log")

> If not is there a way to pass a variable when starting mongrel_service? I
> tried
> mongrel_service console single -c
> d:/rubywork/[appname]MONGREL_TYPE='service'
>

Currently there isn't. Adding environment variables prior starting
child process is currently in my TODO for new service implementation.

Also, the STDOUT/ERR problem (ala, puts) will be solved too. Must
tweak a few things with x64 platforms and do some testing.

> But no luck! :)
>

I know, I know, shame on me :-P

Regards and good weekend.

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


From jamesmead44 at gmail.com  Sun Apr 29 09:44:08 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Sun, 29 Apr 2007 14:44:08 +0100
Subject: [Mongrel] NoMethodError exceptions
In-Reply-To: <463493A2.5000109@hotgazpacho.com>
References: <1db558f00704290528m5fbc6452l2f04ab2fc3915478@mail.gmail.com>
	<463493A2.5000109@hotgazpacho.com>
Message-ID: <1db558f00704290644r3459a4t807bd6e8d5e4f0ac@mail.gmail.com>

On 29/04/07, Will Green <will at hotgazpacho.com> wrote:
>
> Upgrade your Mongrel to the latest (1.0.1), and try again.
>

Using gem install or gem update - I always get 0.3.3 version of mongrel.
Presumably a mirror issue...?

However, I downloaded the 1.0.1 gem and tried to install it, but it looks
like mongrel needs ruby 1.8.4 or greater and I only have 1.8.2 on this
machine.

$ sudo gem install
/Users/jamesmead/downloads/mongrel-1.0.1.gem--include-dependencies
Password:
ERROR:  While executing gem ... (RuntimeError)
    Error instaling /Users/jamesmead/downloads/mongrel-1.0.1.gem:
        mongrel requires Ruby version >= 1.8.4

$ ruby --version
ruby 1.8.2 (2004-12-25) [powerpc-darwin8.2.0]

So I assume my only option is to upgrade my ruby version...?
-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070429/d516ab4f/attachment.html 

From ezmobius at gmail.com  Sun Apr 29 12:37:29 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Sun, 29 Apr 2007 09:37:29 -0700
Subject: [Mongrel] NoMethodError exceptions
In-Reply-To: <1db558f00704290644r3459a4t807bd6e8d5e4f0ac@mail.gmail.com>
References: <1db558f00704290528m5fbc6452l2f04ab2fc3915478@mail.gmail.com>
	<463493A2.5000109@hotgazpacho.com>
	<1db558f00704290644r3459a4t807bd6e8d5e4f0ac@mail.gmail.com>
Message-ID: <475DA1D1-E120-4D7E-A5C9-DC67119EC519@brainspl.at>


On Apr 29, 2007, at 6:44 AM, James Mead wrote:

> On 29/04/07, Will Green <will at hotgazpacho.com> wrote:
> Upgrade your Mongrel to the latest (1.0.1), and try again.
>
> Using gem install or gem update - I always get 0.3.3 version of  
> mongrel. Presumably a mirror issue...?
>
> However, I downloaded the 1.0.1 gem and tried to install it, but it  
> looks like mongrel needs ruby 1.8.4 or greater and I only have  
> 1.8.2 on this machine.
>
> $ sudo gem install /Users/jamesmead/downloads/mongrel- 1.0.1.gem -- 
> include-dependencies
> Password:
> ERROR:  While executing gem ... (RuntimeError)
>     Error instaling /Users/jamesmead/downloads/mongrel-1.0.1.gem:
>         mongrel requires Ruby version >= 1.8.4
>
> $ ruby --version
> ruby 1.8.2 (2004-12-25) [powerpc-darwin8.2.0]
>
> So I assume my only option is to upgrade my ruby version...?
> -- 
> James.
> http://blog.floehopper.org


James-

	Mongrel has *always* required ruby 1.8.4 or later. So you will have  
to upgrade ruby if you plan on using mongrel peridion.

Thanks

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



From will at hotgazpacho.com  Sun Apr 29 13:30:11 2007
From: will at hotgazpacho.com (Will Green)
Date: Sun, 29 Apr 2007 13:30:11 -0400
Subject: [Mongrel] NoMethodError exceptions
In-Reply-To: <1db558f00704290644r3459a4t807bd6e8d5e4f0ac@mail.gmail.com>
References: <1db558f00704290528m5fbc6452l2f04ab2fc3915478@mail.gmail.com>	<463493A2.5000109@hotgazpacho.com>
	<1db558f00704290644r3459a4t807bd6e8d5e4f0ac@mail.gmail.com>
Message-ID: <4634D623.9040003@hotgazpacho.com>

> So I assume my only option is to upgrade my ruby version...?

You assume correctly.

Also, I noticed you're using Rails 1.0. You might want to upgrade that 
to 1.2.

From zack99 at gmail.com  Sun Apr 29 22:59:57 2007
From: zack99 at gmail.com (Isaac)
Date: Mon, 30 Apr 2007 12:59:57 +1000
Subject: [Mongrel] ERROR: Failed to build gem native extension.
Message-ID: <2bdffc600704291959n42bac9e0n3d2f4701a7ed3cf0@mail.gmail.com>

Hi all,
I'd really appreciate some help with this...

As you see below, I tried to install mongrel after updating my gems, but I
get the error shown:

sudo gem install mongrel
Select which gem to install for your platform (i486-linux)
 1. mongrel 1.0.1 (ruby)
 2. mongrel 1.0.1 (mswin32)
 3. mongrel 1.0 (mswin32)
 4. mongrel 1.0 (ruby)
 5. Skip this gem
 6. Cancel installation
> 1
Install required dependency fastthread? [Yn]
Select which gem to install for your platform (i486-linux)
 1. fastthread 1.0 (ruby)
 2. fastthread 1.0 (mswin32)
 3. fastthread 0.6.4.1 (mswin32)
 4. fastthread 0.6.4.1 (ruby)
 5. Skip this gem
 6. Cancel installation
> 1
Building native extensions.  This could take a while...
ERROR:  While executing gem ... (Gem::Installer::ExtensionBuildError)
    ERROR: Failed to build gem native extension.

ruby extconf.rb install mongrel
extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)
        from extconf.rb:1


Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/fastthread-
1.0 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/fastthread-1.0
/ext/fastthread/gem_make.out

Please help!
Regards,
Isaac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070430/b5ca5af3/attachment.html 

From luislavena at gmail.com  Sun Apr 29 23:05:14 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 30 Apr 2007 00:05:14 -0300
Subject: [Mongrel] ERROR: Failed to build gem native extension.
In-Reply-To: <2bdffc600704291959n42bac9e0n3d2f4701a7ed3cf0@mail.gmail.com>
References: <2bdffc600704291959n42bac9e0n3d2f4701a7ed3cf0@mail.gmail.com>
Message-ID: <71166b3b0704292005n40767159pfe3651c2f58a6d29@mail.gmail.com>

On 4/29/07, Isaac <zack99 at gmail.com> wrote:
> Hi all,
> I'd really appreciate some help with this...
>
> As you see below, I tried to install mongrel after updating my gems, but I
> get the error shown:
>
> sudo gem install mongrel
> Select which gem to install for your platform (i486-linux)
>  1. mongrel 1.0.1 (ruby)
>  2. mongrel 1.0.1 (mswin32)
>  3. mongrel 1.0 (mswin32)
>  4. mongrel 1.0 (ruby)
>  5. Skip this gem
>  6. Cancel installation
> > 1
> Install required dependency fastthread? [Yn]
> Select which gem to install for your platform (i486-linux)
>  1. fastthread 1.0 (ruby)
>  2. fastthread 1.0 (mswin32)
>  3. fastthread 0.6.4.1 (mswin32)
>  4. fastthread 0.6.4.1 (ruby)
>  5. Skip this gem
>  6. Cancel installation
> > 1
> Building native extensions.  This could take a while...
> ERROR:  While executing gem ...
> (Gem::Installer::ExtensionBuildError)
>     ERROR: Failed to build gem native extension.
>
> ruby extconf.rb install mongrel
> extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)
>         from extconf.rb:1
>
>

It looks like you have a broken ruby installation.

Debian? try doing:

ruby -w -rubygems -e 'require "mkmf"'

and post the log here.

But I could bet you're missing build environment :-)

>
> Please help!
> Regards,
> Isaac
>

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 zack99 at gmail.com  Sun Apr 29 23:17:33 2007
From: zack99 at gmail.com (Isaac)
Date: Mon, 30 Apr 2007 13:17:33 +1000
Subject: [Mongrel] ERROR: Failed to build gem native extension.
In-Reply-To: <71166b3b0704292005n40767159pfe3651c2f58a6d29@mail.gmail.com>
References: <2bdffc600704291959n42bac9e0n3d2f4701a7ed3cf0@mail.gmail.com>
	<71166b3b0704292005n40767159pfe3651c2f58a6d29@mail.gmail.com>
Message-ID: <2bdffc600704292017ved5a809o597ca5a8e6658666@mail.gmail.com>

Hi,
Close: Ubuntu

Here's what that particular command returns...

ruby -w -rubygems -e 'require "mkmf"'
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- mkmf (LoadError)
        from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from -e:1

-Isaac

On 4/30/07, Luis Lavena <luislavena at gmail.com> wrote:
>
> On 4/29/07, Isaac <zack99 at gmail.com> wrote:
> > Hi all,
> > I'd really appreciate some help with this...
> >
> > As you see below, I tried to install mongrel after updating my gems, but
> I
> > get the error shown:
> >
> > sudo gem install mongrel
> > Select which gem to install for your platform (i486-linux)
> >  1. mongrel 1.0.1 (ruby)
> >  2. mongrel 1.0.1 (mswin32)
> >  3. mongrel 1.0 (mswin32)
> >  4. mongrel 1.0 (ruby)
> >  5. Skip this gem
> >  6. Cancel installation
> > > 1
> > Install required dependency fastthread? [Yn]
> > Select which gem to install for your platform (i486-linux)
> >  1. fastthread 1.0 (ruby)
> >  2. fastthread 1.0 (mswin32)
> >  3. fastthread 0.6.4.1 (mswin32)
> >  4. fastthread 0.6.4.1 (ruby)
> >  5. Skip this gem
> >  6. Cancel installation
> > > 1
> > Building native extensions.  This could take a while...
> > ERROR:  While executing gem ...
> > (Gem::Installer::ExtensionBuildError)
> >     ERROR: Failed to build gem native extension.
> >
> > ruby extconf.rb install mongrel
> > extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)
> >         from extconf.rb:1
> >
> >
>
> It looks like you have a broken ruby installation.
>
> Debian? try doing:
>
> ruby -w -rubygems -e 'require "mkmf"'
>
> and post the log here.
>
> But I could bet you're missing build environment :-)
>
> >
> > Please help!
> > Regards,
> > Isaac
> >
>
> 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
> _______________________________________________
> 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/20070430/09a0f594/attachment-0001.html 

From luislavena at gmail.com  Sun Apr 29 23:22:14 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 30 Apr 2007 00:22:14 -0300
Subject: [Mongrel] ERROR: Failed to build gem native extension.
In-Reply-To: <2bdffc600704292017ved5a809o597ca5a8e6658666@mail.gmail.com>
References: <2bdffc600704291959n42bac9e0n3d2f4701a7ed3cf0@mail.gmail.com>
	<71166b3b0704292005n40767159pfe3651c2f58a6d29@mail.gmail.com>
	<2bdffc600704292017ved5a809o597ca5a8e6658666@mail.gmail.com>
Message-ID: <71166b3b0704292022n39c55a38ia0560346a5273f55@mail.gmail.com>

On 4/30/07, Isaac <zack99 at gmail.com> wrote:
> Hi,
> Close: Ubuntu
>

Oh, ok, you willl need: apt-get build-essential, ruby-1.8dev, errr...
guess thats all?
(bear with me, I'm a windows guy :-)

More info that could be useful:

http://sas.sparklingstudios.com/articles/read/install-mongrel-on-ubuntu-6-06-dapper

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 don at jibjab.net  Sun Apr 29 23:11:46 2007
From: don at jibjab.net (Don Park)
Date: Sun, 29 Apr 2007 20:11:46 -0700
Subject: [Mongrel] ERROR: Failed to build gem native extension.
In-Reply-To: <71166b3b0704292005n40767159pfe3651c2f58a6d29@mail.gmail.com>
References: <2bdffc600704291959n42bac9e0n3d2f4701a7ed3cf0@mail.gmail.com>
	<71166b3b0704292005n40767159pfe3651c2f58a6d29@mail.gmail.com>
Message-ID: <A8C9DF49-066F-4F34-B141-6226225B14D3@jibjab.net>


On Apr 29, 2007, at 8:05 PM, Luis Lavena wrote:
> On 4/29/07, Isaac <zack99 at gmail.com> wrote:
>> extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)
>>         from extconf.rb:1

its most likely an ubuntu system that needs to have ruby-dev installed.
don


From zack99 at gmail.com  Sun Apr 29 23:29:27 2007
From: zack99 at gmail.com (Isaac)
Date: Mon, 30 Apr 2007 13:29:27 +1000
Subject: [Mongrel] ERROR: Failed to build gem native extension.
In-Reply-To: <A8C9DF49-066F-4F34-B141-6226225B14D3@jibjab.net>
References: <2bdffc600704291959n42bac9e0n3d2f4701a7ed3cf0@mail.gmail.com>
	<71166b3b0704292005n40767159pfe3651c2f58a6d29@mail.gmail.com>
	<A8C9DF49-066F-4F34-B141-6226225B14D3@jibjab.net>
Message-ID: <2bdffc600704292029s73645e6alf89bb72765161613@mail.gmail.com>

Thanks Don, Luis, worked like a charm :D



On 4/30/07, Don Park <don at jibjab.net> wrote:
>
>
> On Apr 29, 2007, at 8:05 PM, Luis Lavena wrote:
> > On 4/29/07, Isaac <zack99 at gmail.com> wrote:
> >> extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)
> >>         from extconf.rb:1
>
> its most likely an ubuntu system that needs to have ruby-dev installed.
> don
>
> _______________________________________________
> 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/20070430/9f310910/attachment.html