From pergesu at gmail.com  Fri May  4 05:22:23 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Fri, 4 May 2007 03:22:23 -0600
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
Message-ID: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>

I'm running FreeBSD 6.1 and installed the 1.0.1.1 mongrel_cluster
prerelease.  I had a problem with the mongrels not stopping, and it
turns out it's because ps is reporting my processes as just
[ruby18]

instead of someting more like "mongrel_rails start -d ......."

Not sure why it's doing that, but it is.  Any ideas?

For the time being I just changed line 165 of init.rb to read
pid = ps_output =~ /mongrel_rails|ruby18/ ? pid : nil

and that's working fine.

Pat

From pergesu at gmail.com  Fri May  4 05:38:28 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Fri, 4 May 2007 03:38:28 -0600
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
Message-ID: <810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>

On 5/4/07, Pat Maddox <pergesu at gmail.com> wrote:
> I'm running FreeBSD 6.1 and installed the 1.0.1.1 mongrel_cluster
> prerelease.  I had a problem with the mongrels not stopping, and it
> turns out it's because ps is reporting my processes as just
> [ruby18]
>
> instead of someting more like "mongrel_rails start -d ......."
>
> Not sure why it's doing that, but it is.  Any ideas?
>
> For the time being I just changed line 165 of init.rb to read
> pid = ps_output =~ /mongrel_rails|ruby18/ ? pid : nil
>
> and that's working fine.
>
> Pat
>

I've got two sets of mongrels running now, one running a staging
environment and the other production.

[twist at jack ~/twist/shared/log]$ ps ax | grep ruby
88908  ??  S      0:01.96 [ruby18]
88911  ??  S      0:02.15 [ruby18]
88914  ??  S      0:02.14 [ruby18]
89021  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
start -d -e production -c
89026  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
start -d -e production -c
89029  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
start -d -e production -c

The [ruby18] processes are all staging mongrels.  Any clue as to why
they wouldn't show the full command?

Pat

From miles at pixar.com  Fri May  4 11:05:04 2007
From: miles at pixar.com (Miles Egan)
Date: Fri, 4 May 2007 08:05:04 -0700
Subject: [Mongrel] possible fix for mongrel hangs
Message-ID: <30B09B51-382E-465A-A1A3-AA5380ADE416@pixar.com>

We've been experiencing the same kinds of hangs other people have  
described here lately.  For no obvious reason our mongrel processes  
just freeze up and nothing short of a kill -9 can retrieve them.   
This is in a standard linux apache 2.2/balancer setup.

Anyway, following some threads online I tried adding these directives:

     SetEnv force-proxy-request-1.0 1
     SetEnv proxy-nokeepalive 1

To the apache config and I haven't seen a hang all week.  Sorry I  
don't have a more scientific explanation for this or ideas for a  
deeper fix but these might be worth a try if you're stuck.

--
miles



From paul.mylchreest at mac.com  Fri May  4 12:01:23 2007
From: paul.mylchreest at mac.com (Paul Mylchreest)
Date: Fri, 04 May 2007 12:01:23 -0400
Subject: [Mongrel] possible fix for mongrel hangs
In-Reply-To: <30B09B51-382E-465A-A1A3-AA5380ADE416@pixar.com>
References: <30B09B51-382E-465A-A1A3-AA5380ADE416@pixar.com>
Message-ID: <6105A2D2-2532-4E3A-9AFE-DDB752C8AB1D@mac.com>

If you see this in the apache error log:

proxy: error reading status line from remote server ...

its probably Apache bug 39499.

I found the solution sometime ago here:

<http://blog.pomozov.info/posts/apache-mongrel-and-proxy-error.html>

   #Fix for Apache bug 39499
   SetEnv force-proxy-request-1.0 1
   SetEnv proxy-nokeepalive 1

On 4-May-07, at 11:05 , Miles Egan wrote:

> We've been experiencing the same kinds of hangs other people have
> described here lately.  For no obvious reason our mongrel processes
> just freeze up and nothing short of a kill -9 can retrieve them.
> This is in a standard linux apache 2.2/balancer setup.
>
> Anyway, following some threads online I tried adding these directives:
>
>      SetEnv force-proxy-request-1.0 1
>      SetEnv proxy-nokeepalive 1
>
> To the apache config and I haven't seen a hang all week.  Sorry I
> don't have a more scientific explanation for this or ideas for a
> deeper fix but these might be worth a try if you're stuck.
>
> --
> miles
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From miles at pixar.com  Fri May  4 12:13:47 2007
From: miles at pixar.com (Miles Egan)
Date: Fri, 4 May 2007 09:13:47 -0700
Subject: [Mongrel] possible fix for mongrel hangs
In-Reply-To: <6105A2D2-2532-4E3A-9AFE-DDB752C8AB1D@mac.com>
References: <30B09B51-382E-465A-A1A3-AA5380ADE416@pixar.com>
	<6105A2D2-2532-4E3A-9AFE-DDB752C8AB1D@mac.com>
Message-ID: <0CB9E9FC-4AAE-4DE1-A3D1-DEBB0BC14730@pixar.com>

On May 4, 2007, at 9:01 AM, Paul Mylchreest wrote:
> If you see this in the apache error log:
>
> proxy: error reading status line from remote server ...
>
> its probably Apache bug 39499.
>
> I found the solution sometime ago here:
>
> <http://blog.pomozov.info/posts/apache-mongrel-and-proxy-error.html>
>

I think that's where I found the solution too, actually.

--
miles

"If money played an instrument it would be the saxophone." - Achewood

From matte at ruckuswireless.com  Fri May  4 14:26:13 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Fri, 04 May 2007 11:26:13 -0700
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
	<810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
Message-ID: <463B7AC5.5090000@ruckuswireless.com>

I too am running mongrel on 6.1 but I have a few on 4.x as well.  I 
experienced problems with stopping mongrels UNTIL I switched the pidfile 
location in the config file to point to

/var/tmp/[site].pid

If you are using a relative path to your pid files in the config file, 
as I was when I was having problems, it wouldn't properly stop.  I'm not 
sure of your exact circumstances but you might try switching the pidfile 
location.  This made ALL the difference.  I have NO problems with 
processes that won't stop.

Using the /var/tmp directory is regarded as "best practice".  This is, I 
believe, mentioned in the release announcement for the 1.0.1.1 
pre-release.  Search the archives and you should find it.

matte

Pat Maddox wrote:
> On 5/4/07, Pat Maddox <pergesu at gmail.com> wrote:
>   
>> I'm running FreeBSD 6.1 and installed the 1.0.1.1 mongrel_cluster
>> prerelease.  I had a problem with the mongrels not stopping, and it
>> turns out it's because ps is reporting my processes as just
>> [ruby18]
>>
>> instead of someting more like "mongrel_rails start -d ......."
>>
>> Not sure why it's doing that, but it is.  Any ideas?
>>
>> For the time being I just changed line 165 of init.rb to read
>> pid = ps_output =~ /mongrel_rails|ruby18/ ? pid : nil
>>
>> and that's working fine.
>>
>> Pat
>>
>>     
>
> I've got two sets of mongrels running now, one running a staging
> environment and the other production.
>
> [twist at jack ~/twist/shared/log]$ ps ax | grep ruby
> 88908  ??  S      0:01.96 [ruby18]
> 88911  ??  S      0:02.15 [ruby18]
> 88914  ??  S      0:02.14 [ruby18]
> 89021  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> start -d -e production -c
> 89026  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> start -d -e production -c
> 89029  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> start -d -e production -c
>
> The [ruby18] processes are all staging mongrels.  Any clue as to why
> they wouldn't show the full command?
>
> Pat
> _______________________________________________
> 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/20070504/9753ccbc/attachment.html 

From carl.lerche at gmail.com  Fri May  4 22:59:27 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Fri, 4 May 2007 19:59:27 -0700
Subject: [Mongrel] Tell me why my Shoutcase handler sucks!
Message-ID: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>

So, I want to build the greatest online radio ever! (for my, currently
crappy, faderwave.net radio station. Right now, I'm running Icecast
straight up. The only problem is that managing different DJs and
keeping them off the air when they aren't supposed to be there is a
pain. There also is not one single management package that does
everything. My current system is a hacked together mess.

So, I want to build a unified ruby based solution. No, I'm not going
to try to replace Icecast with a hacked pure ruby version, but I am
going to try to setup a proxy for DJs to connect to where I can manage
every small bit.

To do all that, I really have to understand how Icecast works. So, I
hacked together a mongrel handler that can accept broadcasting clients
and send the stream to listeners... except I don't really know what
I'm doing. So, I would appreciate it if you could look over the code
and tell me why it sucks and how to improve it. It's really short,
under 100 lines with comments.

Of course, this is just a really rough solution that I hacked together
to experiment with interfacing with broadcasting clients and audio
players. Anyway, here it is:

http://pastie.caboo.se/59073

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

From carl.lerche at gmail.com  Fri May  4 23:01:47 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Fri, 4 May 2007 20:01:47 -0700
Subject: [Mongrel] Tell me why my Shoutcase handler sucks!
In-Reply-To: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>
References: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>
Message-ID: <ab90312e0705042001ib61bfd3h5c35e11734ea88cb@mail.gmail.com>

woops, the subject is supposed to be Shoutcast!!!

On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> So, I want to build the greatest online radio ever! (for my, currently
> crappy, faderwave.net radio station. Right now, I'm running Icecast
> straight up. The only problem is that managing different DJs and
> keeping them off the air when they aren't supposed to be there is a
> pain. There also is not one single management package that does
> everything. My current system is a hacked together mess.
>
> So, I want to build a unified ruby based solution. No, I'm not going
> to try to replace Icecast with a hacked pure ruby version, but I am
> going to try to setup a proxy for DJs to connect to where I can manage
> every small bit.
>
> To do all that, I really have to understand how Icecast works. So, I
> hacked together a mongrel handler that can accept broadcasting clients
> and send the stream to listeners... except I don't really know what
> I'm doing. So, I would appreciate it if you could look over the code
> and tell me why it sucks and how to improve it. It's really short,
> under 100 lines with comments.
>
> Of course, this is just a really rough solution that I hacked together
> to experiment with interfacing with broadcasting clients and audio
> players. Anyway, here it is:
>
> http://pastie.caboo.se/59073
>
> Thanks,
> -carl
> --
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>


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

From tom at hur.st  Sat May  5 15:15:11 2007
From: tom at hur.st (Thomas Hurst)
Date: Sat, 5 May 2007 20:15:11 +0100
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
	<810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
Message-ID: <20070505191511.GA90903@voi.aagh.net>

* Pat Maddox (pergesu at gmail.com) wrote:

> [twist at jack ~/twist/shared/log]$ ps ax | grep ruby
> 88908  ??  S      0:01.96 [ruby18]
..
> 89029  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> start -d -e production -c
> 
> The [ruby18] processes are all staging mongrels.  Any clue as to why
> they wouldn't show the full command?

They've probably been swapped out; -f can bring the full command name
back if you're root.

-- 
Thomas 'Freaky' Hurst
    http://hur.st/

From pergesu at gmail.com  Sat May  5 18:27:56 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Sat, 5 May 2007 16:27:56 -0600
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <20070505191511.GA90903@voi.aagh.net>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
	<810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
	<20070505191511.GA90903@voi.aagh.net>
Message-ID: <810a540e0705051527p2ca9b266m47d2aca4a2fe0326@mail.gmail.com>

On 5/5/07, Thomas Hurst <tom at hur.st> wrote:
> * Pat Maddox (pergesu at gmail.com) wrote:
>
> > [twist at jack ~/twist/shared/log]$ ps ax | grep ruby
> > 88908  ??  S      0:01.96 [ruby18]
> ..
> > 89029  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> > start -d -e production -c
> >
> > The [ruby18] processes are all staging mongrels.  Any clue as to why
> > they wouldn't show the full command?
>
> They've probably been swapped out; -f can bring the full command name
> back if you're root.

What do you mean swapped out?

Pat

From msoulier at digitaltorque.ca  Sat May  5 21:04:11 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Sat, 5 May 2007 21:04:11 -0400
Subject: [Mongrel] mongrel becoming unresponsive
Message-ID: <20070506010410.GS4346@tigger.digitaltorque.ca>

Hello,

I'm running mongrel behind apache via proxypass. Every now and then, a spammer
tries to proxy traffic through apache, and for some reason, apache forwards
the request to mongrel, even though it's not a site being hosted by me. 

At times this seems to cause mongrel to become unresponsive, and all requests
to the site then fail with a proxy error until mongrel is restarted. 

I'm not sure of how to troubleshoot this issue. Help appreciated. 

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/20070505/b7a71f69/attachment.bin 

From pete at nextengine.com  Sat May  5 21:33:53 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Sat, 5 May 2007 18:33:53 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506010410.GS4346@tigger.digitaltorque.ca>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
Message-ID: <01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>

Hi Mike,

My mongrels are dying too, but running behind Lighttpd.  Are you  
seeing anything in the logs?  I see absolutely nothing.  Just the  
last request that went through... but it's pretty old.

At first, I thought it might be my version of Ruby or Rails.  But now  
I've tried all sort of combinations, and rebuilt all the gems each  
time (based on advice on this forum).

My solution for now is to run a few mongrels, and have Monit restart  
them when they become unresponsive.  I have a few die each day.

Zed, is there anything we can do to debug this further?  Is there a  
good place we can put some logs in the Mongrel code?  Or something we  
can try the next time they go down?

Thanks,
Pete

On May 5, 2007, at 6:04 PM, Michael P. Soulier wrote:

> Hello,
>
> I'm running mongrel behind apache via proxypass. Every now and  
> then, a spammer
> tries to proxy traffic through apache, and for some reason, apache  
> forwards
> the request to mongrel, even though it's not a site being hosted by  
> me.
>
> At times this seems to cause mongrel to become unresponsive, and  
> all requests
> to the site then fail with a proxy error until mongrel is restarted.
>
> I'm not sure of how to troubleshoot this issue. Help appreciated.
>
> 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
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From tom at hur.st  Sat May  5 21:39:02 2007
From: tom at hur.st (Thomas Hurst)
Date: Sun, 6 May 2007 02:39:02 +0100
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <810a540e0705051527p2ca9b266m47d2aca4a2fe0326@mail.gmail.com>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
	<810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
	<20070505191511.GA90903@voi.aagh.net>
	<810a540e0705051527p2ca9b266m47d2aca4a2fe0326@mail.gmail.com>
Message-ID: <20070506013902.GA11635@voi.aagh.net>

* Pat Maddox (pergesu at gmail.com) wrote:

(Sorry to the moderator(s), who I keep spamming by sending from the wrong
address.  I've added a folder-hook to prevent it)

> > They've probably been swapped out; -f can bring the full command name
> > back if you're root.
> 
> What do you mean swapped out?

I mean, the pages which contain the command line are not in system
memory, so it's just showing you the command name instead of swapping
them back in, which could get quite expensive on a loaded system with
lots of inactive processes (think: 4k * 1000 processes for something the
user probably doesn't even want).

You can turn it off by rebuilding it without the -DLAZY_PS line, ala:

cd /usr/src/bin/ps && sed -i .orig -e 's/-DLAZY_PS//' Makefile && make clean all install

But obviously this isn't something mongrel should be depending on ;)

Maybe we could use a proper interface to process lists, with backends to
ps(1), procfs(5), kvm(3), Win32, etc.  I have a decent chunk of code for
FreeBSD/kvm(3) right here, though it's not yet 64bit clean.

-- 
Thomas 'Freaky' Hurst
    http://hur.st/

From tom at hur.st  Sat May  5 21:51:44 2007
From: tom at hur.st (Thomas Hurst)
Date: Sun, 6 May 2007 02:51:44 +0100
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506010410.GS4346@tigger.digitaltorque.ca>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
Message-ID: <20070506015144.GB11635@voi.aagh.net>

* Michael P. Soulier (msoulier at digitaltorque.ca) wrote:

> At times this seems to cause mongrel to become unresponsive, and all
> requests to the site then fail with a proxy error until mongrel is
> restarted. 
> 
> I'm not sure of how to troubleshoot this issue. Help appreciated. 

Try using gdb to get a backtrace:

% gdb `which ruby` <pid of mongrel>

Then "bt" to get a list of the functions it's calling.  You may need to
recompile Ruby with debugging symbols if it's mostly "???".  On FreeBSD
this is as simple as "portupgrade -fm '-DWITH_DEBUG' ruby"

http://eigenclass.org/hiki/ruby+live+process+introspection may be of
use.

Other options are ktrace, strace and truss (depending on what system
you're on) to get an idea of the syscalls it's performing, but this may
not be very useful depending on how it's hung.

-- 
Thomas 'Freaky' Hurst
    http://hur.st/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070506/588fdd4b/attachment.bin 

From msoulier at digitaltorque.ca  Sat May  5 22:05:17 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Sat, 5 May 2007 22:05:17 -0400
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
Message-ID: <20070506020517.GT4346@tigger.digitaltorque.ca>

On 05/05/07 Pete DeLaurentis said:

> Hi Mike,
> 
> My mongrels are dying too, but running behind Lighttpd.  Are you  
> seeing anything in the logs?  I see absolutely nothing.  Just the  
> last request that went through... but it's pretty old.

Nothing in the logs to indicate what the problem might be. Seems to happen
when it processes a 404 error sometimes. 

ActionController::RoutingError (no route found to match
"/2006/04/15/employee-of-the-century-dead-at-100/trackback/" with
{:method=>:post}):
    /usr/local/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/routing.rb:1292:in
`recognize_path'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/routing.rb:1282:in
`recognize'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:40:in
`dispatch'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:78:in
`process'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76:in
`process'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:618:in
`process_client'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in
`process_client'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
    /usr/local/ruby/bin/mongrel_rails:18


rescue_action_in_public executed
Rendering status404 Not
Foundfile/var/www/papproach/config/../public/404.htmllayoutfalse within
layouts//application
Rendering /var/www/papproach/config/../public/404.html (404 Not Found)

> My solution for now is to run a few mongrels, and have Monit restart  
> them when they become unresponsive.  I have a few die each day.

I have one instance supervised with runit, but supervision doesn't help since
the mongrel doesn't crash, it just hangs. I now have a 10 minute cron that
checks on it and restarts it if it's unresponsive, and it's doing so a few
times an hour now, which is disturbing. 

> Zed, is there anything we can do to debug this further?  Is there a  
> good place we can put some logs in the Mongrel code?  Or something we  
> can try the next time they go down?

It's happening a lot to me right now. No --debug option to mongrel?

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/20070505/453d1cdb/attachment.bin 

From pete at nextengine.com  Sat May  5 22:21:54 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Sat, 5 May 2007 19:21:54 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506020517.GT4346@tigger.digitaltorque.ca>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
Message-ID: <C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>

Hi Mike,

You're definitely hitting this more often then I am (about once per  
day).

With monit, you can do an HTTP request and test the response, which  
is how I determined if it's hanged.  Sounds pretty similar to what  
you're doing with cron.

Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,  
Ruby 1.8.5, Rails 1.2, and Mongrel 1.0.1.  I also run memcached,  
lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster  
(the latest version).

Thanks,
Pete


On May 5, 2007, at 7:05 PM, Michael P. Soulier wrote:

> On 05/05/07 Pete DeLaurentis said:
>
>> Hi Mike,
>>
>> My mongrels are dying too, but running behind Lighttpd.  Are you
>> seeing anything in the logs?  I see absolutely nothing.  Just the
>> last request that went through... but it's pretty old.
>
> Nothing in the logs to indicate what the problem might be. Seems to  
> happen
> when it processes a 404 error sometimes.
>
> ActionController::RoutingError (no route found to match
> "/2006/04/15/employee-of-the-century-dead-at-100/trackback/" with
> {:method=>:post}):
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/ 
> action_controller/routing.rb:1292:in
> `recognize_path'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/ 
> action_controller/routing.rb:1282:in
> `recognize'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/ 
> dispatcher.rb:40:in
> `dispatch'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/rails.rb:78:in
> `process'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/rails.rb:76:in
> `process'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:618:in
> `process_client'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:617:in
> `process_client'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:736:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:736:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:720:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/configurator.rb:271:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/configurator.rb:270:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:127:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/command.rb:211:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:243
>     /usr/local/ruby/bin/mongrel_rails:18
>
>
> rescue_action_in_public executed
> Rendering status404 Not
> Foundfile/var/www/papproach/config/../public/404.htmllayoutfalse  
> within
> layouts//application
> Rendering /var/www/papproach/config/../public/404.html (404 Not Found)
>
>> My solution for now is to run a few mongrels, and have Monit restart
>> them when they become unresponsive.  I have a few die each day.
>
> I have one instance supervised with runit, but supervision doesn't  
> help since
> the mongrel doesn't crash, it just hangs. I now have a 10 minute  
> cron that
> checks on it and restarts it if it's unresponsive, and it's doing  
> so a few
> times an hour now, which is disturbing.
>
>> Zed, is there anything we can do to debug this further?  Is there a
>> good place we can put some logs in the Mongrel code?  Or something we
>> can try the next time they go down?
>
> It's happening a lot to me right now. No --debug option to mongrel?
>
> 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
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From msoulier at digitaltorque.ca  Sat May  5 22:54:06 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Sat, 5 May 2007 22:54:06 -0400
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506015144.GB11635@voi.aagh.net>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506015144.GB11635@voi.aagh.net>
Message-ID: <20070506025406.GU4346@tigger.digitaltorque.ca>

On 06/05/07 Thomas Hurst said:

> Try using gdb to get a backtrace:
> 
> % gdb `which ruby` <pid of mongrel>

Unfortunately it's on a VPS where I don't get gdb. I don't have full control
over the box. 

> Then "bt" to get a list of the functions it's calling.  You may need to
> recompile Ruby with debugging symbols if it's mostly "???".  On FreeBSD
> this is as simple as "portupgrade -fm '-DWITH_DEBUG' ruby"
> 
> http://eigenclass.org/hiki/ruby+live+process+introspection may be of
> use.
> 
> Other options are ktrace, strace and truss (depending on what system
> you're on) to get an idea of the syscalls it's performing, but this may
> not be very useful depending on how it's hung.

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/20070505/6604fa81/attachment.bin 

From msoulier at digitaltorque.ca  Sat May  5 22:55:46 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Sat, 5 May 2007 22:55:46 -0400
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
Message-ID: <20070506025545.GV4346@tigger.digitaltorque.ca>

On 05/05/07 Pete DeLaurentis said:

> Hi Mike,
> 
> You're definitely hitting this more often then I am (about once per  
> day).
> 
> With monit, you can do an HTTP request and test the response, which  
> is how I determined if it's hanged.  Sounds pretty similar to what  
> you're doing with cron.
> 
> Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,  
> Ruby 1.8.5, Rails 1.2, and Mongrel 1.0.1.  I also run memcached,  
> lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster  
> (the latest version).

I'm running a Linux VPS, which I think is RedHat based. ruby 1.8.4 and
mongrel 1.0.1, with Rails 1.2.2. 

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/20070505/09201a6f/attachment.bin 

From zach at plugthegap.co.uk  Sun May  6 20:15:51 2007
From: zach at plugthegap.co.uk (Zachary Powell)
Date: Sun, 6 May 2007 20:15:51 -0400
Subject: [Mongrel] Mongrel and EBADF error consuming resources
Message-ID: <ac243e420705061715q2b64e5e8r97d9486f94b2ad0e@mail.gmail.com>

In the last few weeks I've noticed the load average spiking up for 5
minutes at a time (2-3.5 on a system that usually runs around
0.5-1.5). Looking closer I found that one mongrel process and
litespeed are at the top, and using strace I've found that they're
passing the file below, seems to get stuck on single file/EBADF error.
It happens with a number of different urls, and they're all
caches_page so I don't think it has anything to do with my rails code.
Also, the mongrel process is still usable during this time (I can
request pages from it and the loop below continues uneffected, so its
not one request locking up the process). Any ideas on how I can
straighten this out?

thanks,

Zach

(mongrel (1.0.1, cluster 0.2.0, rails 1.1.16, ruby 1.8.4 on fedora)

read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
--- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "", 16384)                    = 0
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)

From shodson at gmail.com  Mon May  7 01:45:25 2007
From: shodson at gmail.com (Scott Hodson)
Date: Sun, 6 May 2007 22:45:25 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506025545.GV4346@tigger.digitaltorque.ca>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
Message-ID: <3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>

Try upgrading to Ruby 1.8.6, my mongrels were hanging too until I upgraded
my ruby, gem and rails to the latest versions and it's all working better
now.

On 5/5/07, Michael P. Soulier <msoulier at digitaltorque.ca> wrote:
>
> On 05/05/07 Pete DeLaurentis said:
>
> > Hi Mike,
> >
> > You're definitely hitting this more often then I am (about once per
> > day).
> >
> > With monit, you can do an HTTP request and test the response, which
> > is how I determined if it's hanged.  Sounds pretty similar to what
> > you're doing with cron.
> >
> > Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,
> > Ruby 1.8.5, Rails 1.2, and Mongrel 1.0.1.  I also run memcached,
> > lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster
> > (the latest version).
>
> I'm running a Linux VPS, which I think is RedHat based. ruby 1.8.4 and
> mongrel 1.0.1, with Rails 1.2.2.
>
> 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
>
> _______________________________________________
> 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/20070506/c85bff04/attachment.html 

From michael.dauria at gmail.com  Mon May  7 10:07:58 2007
From: michael.dauria at gmail.com (Michael D'Auria)
Date: Mon, 7 May 2007 10:07:58 -0400
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
Message-ID: <1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>

I wouldn't upgrade to Ruby 1.8.6 unless my app was written for Rails 1.2 as
Ruby 1.8.6 requires Rails 1.2.3/

On 5/7/07, Scott Hodson <shodson at gmail.com> wrote:
>
> Try upgrading to Ruby 1.8.6, my mongrels were hanging too until I upgraded
> my ruby, gem and rails to the latest versions and it's all working better
> now.
>
> On 5/5/07, Michael P. Soulier <msoulier at digitaltorque.ca> wrote:
> >
> > On 05/05/07 Pete DeLaurentis said:
> >
> > > Hi Mike,
> > >
> > > You're definitely hitting this more often then I am (about once per
> > > day).
> > >
> > > With monit, you can do an HTTP request and test the response, which
> > > is how I determined if it's hanged.  Sounds pretty similar to what
> > > you're doing with cron.
> > >
> > > Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,
> > > Ruby 1.8.5 , Rails 1.2, and Mongrel 1.0.1.  I also run memcached,
> > > lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster
> > > (the latest version).
> >
> > I'm running a Linux VPS, which I think is RedHat based. ruby 1.8.4 and
> > mongrel 1.0.1, with Rails 1.2.2.
> >
> > 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
> >
> > _______________________________________________
> > 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/20070507/d3337094/attachment.html 

From pete at nextengine.com  Mon May  7 10:44:35 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Mon, 7 May 2007 07:44:35 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
Message-ID: <F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>

That's interesting Scott.  I was running Ruby 1.8.4, and first  
noticed the problem when I upgraded to 1.8.6.  I did some other  
things at that same time though... I also added memcached (which I  
connect to in environment.rb).

I recently tried having monit call a simple test controller / action  
every 2 minutes on each mongrel.  The controller doesn't access the  
DB or memcache... it just renders "hello world" to the HTML.   
Shouldn't help... but it does.

So far so good, the mongrels have stayed responsive for the last  
couple days.  Based on the fact that this fixed things, I'm thinking  
it's some kind of timeout issue within mongrel.

-Pete

On May 7, 2007, at 7:07 AM, Michael D'Auria wrote:

> I wouldn't upgrade to Ruby 1.8.6 unless my app was written for  
> Rails 1.2 as Ruby 1.8.6 requires Rails 1.2.3/
>
> On 5/7/07, Scott Hodson <shodson at gmail.com> wrote:
> Try upgrading to Ruby 1.8.6, my mongrels were hanging too until I  
> upgraded my ruby, gem and rails to the latest versions and it's all  
> working better now.
>
> On 5/5/07, Michael P. Soulier <msoulier at digitaltorque.ca > wrote:
> On 05/05/07 Pete DeLaurentis said:
>
> > Hi Mike,
> >
> > You're definitely hitting this more often then I am (about once per
> > day).
> >
> > With monit, you can do an HTTP request and test the response, which
> > is how I determined if it's hanged.  Sounds pretty similar to what
> > you're doing with cron.
> >
> > Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,
> > Ruby 1.8.5 , Rails 1.2, and Mongrel 1.0.1.  I also run memcached,
> > lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster
> > (the latest version).
>
> I'm running a Linux VPS, which I think is RedHat based. ruby 1.8.4 and
> mongrel 1.0.1, with Rails 1.2.2.
>
> 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
>
> _______________________________________________
> 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/20070507/ca516622/attachment-0001.html 

From wyhaines at gmail.com  Mon May  7 10:53:06 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Mon, 7 May 2007 07:53:06 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
Message-ID: <f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>

On 5/7/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> That's interesting Scott.  I was running Ruby 1.8.4, and first noticed the
> problem when I upgraded to 1.8.6.  I did some other things at that same time
> though... I also added memcached (which I connect to in environment.rb).

Just another useless data point, but I never have had a problem with
Mongrel on Ruby 1.8.5.


Kirk Haines

From miles at pixar.com  Mon May  7 11:22:35 2007
From: miles at pixar.com (Miles Egan)
Date: Mon, 7 May 2007 08:22:35 -0700
Subject: [Mongrel] Mongrel and EBADF error consuming resources
In-Reply-To: <ac243e420705061715q2b64e5e8r97d9486f94b2ad0e@mail.gmail.com>
References: <ac243e420705061715q2b64e5e8r97d9486f94b2ad0e@mail.gmail.com>
Message-ID: <AA092648-12A8-475B-B856-7C7787DFD323@pixar.com>

On May 6, 2007, at 5:15 PM, Zachary Powell wrote:
> In the last few weeks I've noticed the load average spiking up for 5
> minutes at a time (2-3.5 on a system that usually runs around
> 0.5-1.5). Looking closer I found that one mongrel process and
> litespeed are at the top, and using strace I've found that they're
> passing the file below, seems to get stuck on single file/EBADF error.

I've seen this too but I haven't found the cause yet.

--
miles

"If money played an instrument it would be the saxophone." - Achewood

From miles at pixar.com  Mon May  7 11:26:29 2007
From: miles at pixar.com (Miles Egan)
Date: Mon, 7 May 2007 08:26:29 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
Message-ID: <302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>

We've had this here too, to the point where it was becoming a bit of  
a crisis.  I've seen several suggested remedies:

1. make sure your log rotation is done outside mongrel, not using  
ruby's log rotation features
2. make sure your rails app doesn't ever try to write to stdout or  
stderr
3. avoid pstore-based sessions
4. disable http keepalive on the apache frontend

We tried all of these and it looks like #4 might have finally done  
the trick.

--
miles

"If money played an instrument it would be the saxophone." - Achewood

From pete at nextengine.com  Mon May  7 12:06:20 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Mon, 7 May 2007 09:06:20 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
Message-ID: <64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>

Thanks for the tips Miles.  One of them really hit home:

I love writing to stdout, and it's all over the place in my app.   
It's great because you can run your scripts / apps as foreground and  
get a live trace, or daemonized and it goes to the log file.  Your  
warning on this one sounds like the voice of experience, and I  
believe it.  But I'd like to understand the details.

Any ideas why this is a dangerous thing to do?

Thanks,
Pete

BTW. I don't know if lighty has a keepalive feature, but I'll look  
into this.   Sounds like it was the main issue for you, and it could  
be for me too.




On May 7, 2007, at 8:26 AM, Miles Egan wrote:

> We've had this here too, to the point where it was becoming a bit of
> a crisis.  I've seen several suggested remedies:
>
> 1. make sure your log rotation is done outside mongrel, not using
> ruby's log rotation features
> 2. make sure your rails app doesn't ever try to write to stdout or
> stderr
> 3. avoid pstore-based sessions
> 4. disable http keepalive on the apache frontend
>
> We tried all of these and it looks like #4 might have finally done
> the trick.
>
> --
> miles
>
> "If money played an instrument it would be the saxophone." - Achewood
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From miles at pixar.com  Mon May  7 12:20:25 2007
From: miles at pixar.com (Miles Egan)
Date: Mon, 7 May 2007 09:20:25 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
Message-ID: <EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>

On May 7, 2007, at 9:06 AM, Pete DeLaurentis wrote:
> Thanks for the tips Miles.  One of them really hit home:
>
> I love writing to stdout, and it's all over the place in my app.
> It's great because you can run your scripts / apps as foreground and
> get a live trace, or daemonized and it goes to the log file.  Your
> warning on this one sounds like the voice of experience, and I
> believe it.  But I'd like to understand the details.
>
> Any ideas why this is a dangerous thing to do?

I gather from browsing this list that it interferes with Ruby's  
threads and non-blocking i/o but I'm sure somebody on the list can  
give you a better explanation.  I'd recommend using the logging  
features and just keeping an active tail -f on the log.

--
miles

"If money played an instrument it would be the saxophone." - Achewood

From wyhaines at gmail.com  Mon May  7 13:03:10 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Mon, 7 May 2007 10:03:10 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
Message-ID: <f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>

On 5/7/07, Miles Egan <miles at pixar.com> wrote:

> > I love writing to stdout, and it's all over the place in my app.
>
> I gather from browsing this list that it interferes with Ruby's
> threads and non-blocking i/o but I'm sure somebody on the list can
> give you a better explanation.  I'd recommend using the logging
> features and just keeping an active tail -f on the log.

It's a shameless plug, but you might look at
http://analogger.swiftcore.org to help with logging.  It should be
simple to use it from Rails, though nobody has given me any specific
feedback on that, yet.


Kirk Haines

From mzukowski at urbacon.net  Mon May  7 14:29:03 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Mon, 07 May 2007 14:29:03 -0400
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>	<20070506025545.GV4346@tigger.digitaltorque.ca>	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
Message-ID: <463F6FEF.1030700@urbacon.net>

Just out of curiosity, why does mongrel_rails by default put its .pid 
files in the log directory rather than in tmp or tmp/pids? Putting them 
in the log directory seems to me like a strange decision, since they're 
not logs -- they're temporary state files.


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 doug.arogos at gmail.com  Mon May  7 14:39:35 2007
From: doug.arogos at gmail.com (Doug Smith)
Date: Mon, 7 May 2007 11:39:35 -0700
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <463F6FEF.1030700@urbacon.net>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
	<463F6FEF.1030700@urbacon.net>
Message-ID: <42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>

I have thought this as well -- but it's not just Mongrel that does
this.  Ferret's DRb server also puts the .pid file into the logs
directory.   I'd prefer a dedicated location myself.

Thanks,

Doug

On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
> Just out of curiosity, why does mongrel_rails by default put its .pid
> files in the log directory rather than in tmp or tmp/pids? Putting them
> in the log directory seems to me like a strange decision, since they're
> not logs -- they're temporary state files.
>
>
> 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 don at jibjab.net  Mon May  7 14:44:33 2007
From: don at jibjab.net (Don Park)
Date: Mon, 7 May 2007 11:44:33 -0700
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
	<463F6FEF.1030700@urbacon.net>
	<42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
Message-ID: <FBC69C01-8620-4524-8340-86C29D4547FE@jibjab.net>

i believe the answer is the decision was made pre-rails 1.2 which  
added tmp/* to the rails directory tree. plus maybe other frameworks  
dont have tmp/pids and log was a safe default.

don

On May 7, 2007, at 11:39 AM, Doug Smith wrote:

> I have thought this as well -- but it's not just Mongrel that does
> this.  Ferret's DRb server also puts the .pid file into the logs
> directory.   I'd prefer a dedicated location myself.
>
> Thanks,
>
> Doug
>
> On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
>> Just out of curiosity, why does mongrel_rails by default put its .pid
>> files in the log directory rather than in tmp or tmp/pids? Putting  
>> them
>> in the log directory seems to me like a strange decision, since  
>> they're
>> not logs -- they're temporary state files.
>>
>>
>> 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
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From matte at ruckuswireless.com  Mon May  7 14:46:03 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Mon, 07 May 2007 11:46:03 -0700
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>	<463F6FEF.1030700@urbacon.net>
	<42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
Message-ID: <463F73EB.5020105@ruckuswireless.com>

So just change your config files.  Easy peasy.

Best practice, if using mongrel_cluster, is to throw it into a directory 
like what you're suggesting.  In the announcement thread for 
mongrel_cluster 1.0.1.1 it's recommended to config for using the 
/var/run directory.  But you can choose what you want.

FYI

matte - matte at ruckuswireless.com

Doug Smith wrote:
> I have thought this as well -- but it's not just Mongrel that does
> this.  Ferret's DRb server also puts the .pid file into the logs
> directory.   I'd prefer a dedicated location myself.
>
> Thanks,
>
> Doug
>
> On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
>   
>> Just out of curiosity, why does mongrel_rails by default put its .pid
>> files in the log directory rather than in tmp or tmp/pids? Putting them
>> in the log directory seems to me like a strange decision, since they're
>> not logs -- they're temporary state files.
>>
>>     



From nathanclark80 at gmail.com  Mon May  7 18:55:24 2007
From: nathanclark80 at gmail.com (Nathan Clark)
Date: Mon, 7 May 2007 17:55:24 -0500
Subject: [Mongrel] mongrel becoming unresponsive
Message-ID: <d21af660705071555vca1e6f6wf31579e016554345@mail.gmail.com>

I am also having an issue with mongrel becoming unresponsive.
Here is it's environment:
    Red Hat Enterprise Linux ES release 4
        ruby 1.8.5 (2007-03-13 patchlevel 35) [x86_64-linux]
    Mongrel Web Server 1.0.1

In front of these mongrels, is Apache and the haproxy load balancer

I am running several different ROR sites on the same server.
after a few hours the rails application will become unresponsive.

My log file sings this tune:

    Server overloaded with 5 processors (5 max). Dropping connection.
    Mon May 07 11:53:04 -0500 2007: Reaping 4 threads for slow workers
because of 'max processors'
    Thread #<Thread:0x2a98447ab0 sleep> is too old, killing.
    Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this thread:
max processorsThread #<Thread:0x2a98451740 sleep> is too old, killing.
    Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this thread:
max processorsThread #<Thread:0x2a98459990 sleep> is too old, killing.
    Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this thread:
max processorsThread #<Thread:0x2a984d9168 sleep> is too old, killing.

    Server overloaded with 5 processors (5 max). Dropping connection.
    Mon May 07 11:53:06 -0500 2007: Reaping 5 threads for slow workers
because of 'max processors'

    Mon May 07 13:29:29 -0500 2007: Reaping 3 threads for slow workers
because of 'shutdown'
    Thread #<Thread:0x2a98472468 sleep> is too old, killing.
    Mon May 07 13:29:29 -0500 2007: Error calling
Dispatcher.dispatch#<Mongrel::TimeoutError: Mongrel timed out this
thread: shutdown>Thread
#<Thread:0x2a98597b68 sleep> is too old, killing.

A restart of the mongrel, fixes it, but it doesn't last.
I have been trying to use the gdb to to gain some insight as the the root
cause.
Using the examples I found on the web,, the following was suggested

    (gdb) set $ary = (int)backtrace(-1)
    (gdb) set $count = *($ary+8)
    (gdb) set $index = 0
    (gdb) while $index < $count
    >  x/1s *((int)rb_ary_entry($ary, $index)+12)
    >  set $index = $index + 1
    >end

However, I get an error on the second line
    "(gdb) set $count = *($ary+8)
    Cannot access memory at address 0xffffffff985779d8"

Has anyone seen this before?

Cheers,
Nathan C.


-- 
Together we can solve any issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070507/87c2ab8b/attachment.html 

From ezmobius at gmail.com  Mon May  7 19:01:20 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Mon, 7 May 2007 16:01:20 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <d21af660705071555vca1e6f6wf31579e016554345@mail.gmail.com>
References: <d21af660705071555vca1e6f6wf31579e016554345@mail.gmail.com>
Message-ID: <FD6127AA-7612-4862-BA9F-97D9ECB0B08A@brainspl.at>

Nathan-


	This line is very telling:

   Server overloaded with 5 processors (5 max). Dropping connection

	Mongrel has a numprocs setting that defaults to 900 i think. It  
looks like somehow it is being set to 5 in your mongrels so they  
start timing out threads when there are more then 5 connections in  
mongrel being processed. I'd say up your numb procs to 50 or so and  
if you are using haproxy make it limit connections to mongrel to one  
at atime. That way the requests queue in haproxy and only go to  
mongrels that aren't busy.


Cheers-
-Ezra
	

On May 7, 2007, at 3:55 PM, Nathan Clark wrote:

> I am also having an issue with mongrel becoming unresponsive.
> Here is it's environment:
>     Red Hat Enterprise Linux ES release 4
>         ruby 1.8.5 (2007-03-13 patchlevel 35) [x86_64-linux]
>     Mongrel Web Server 1.0.1
>
> In front of these mongrels, is Apache and the haproxy load balancer
>
> I am running several different ROR sites on the same server.
> after a few hours the rails application will become unresponsive.
>
> My log file sings this tune:
>
>     Server overloaded with 5 processors (5 max). Dropping connection.
>     Mon May 07 11:53:04 -0500 2007: Reaping 4 threads for slow  
> workers because of 'max processors'
>     Thread #<Thread:0x2a98447ab0 sleep> is too old, killing.
>     Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this  
> thread: max processorsThread #<Thread:0x2a98451740 sleep> is too  
> old, killing.
>     Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this  
> thread: max processorsThread #<Thread:0x2a98459990 sleep> is too  
> old, killing.
>     Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this  
> thread: max processorsThread #<Thread:0x2a984d9168 sleep> is too  
> old, killing.
>
>     Server overloaded with 5 processors (5 max). Dropping connection.
>     Mon May 07 11:53:06 -0500 2007: Reaping 5 threads for slow  
> workers because of 'max processors'
>
>     Mon May 07 13:29:29 -0500 2007: Reaping 3 threads for slow  
> workers because of 'shutdown'
>     Thread #<Thread:0x2a98472468 sleep> is too old, killing.
>     Mon May 07 13:29:29 -0500 2007: Error calling  
> Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed out this  
> thread: shutdown>Thread #<Thread:0x2a98597b68 sleep> is too old,  
> killing.
>
> A restart of the mongrel, fixes it, but it doesn't last.
> I have been trying to use the gdb to to gain some insight as the  
> the root cause.
> Using the examples I found on the web,, the following was suggested
>
>     (gdb) set $ary = (int)backtrace(-1)
>     (gdb) set $count = *($ary+8)
>     (gdb) set $index = 0
>     (gdb) while $index < $count
>     >  x/1s *((int)rb_ary_entry($ary, $index)+12)
>     >  set $index = $index + 1
>     >end
>
> However, I get an error on the second line
>     "(gdb) set $count = *($ary+8)
>     Cannot access memory at address 0xffffffff985779d8"
>
> Has anyone seen this before?
>
> Cheers,
> Nathan C.
>
>
> -- 
> Together we can solve any issue.
> _______________________________________________
> 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 eden at mojiti.com  Tue May  8 02:55:33 2007
From: eden at mojiti.com (Eden Li)
Date: Tue, 8 May 2007 14:55:33 +0800
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <463F73EB.5020105@ruckuswireless.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
	<463F6FEF.1030700@urbacon.net>
	<42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
	<463F73EB.5020105@ruckuswireless.com>
Message-ID: <1dd361e10705072355x1b7128b3j3f90b16a54d0e22d@mail.gmail.com>

One more reason -- in capistrano deployed setups, the log directory is
shared among all releases, but the rails tmp directory is not.  The
default mongrel restart recipes will complain that they can't find pid
files because the xxx/current/tmp will have been moved to a freshly
checked-out version of your which doesn't have the old tmp directory
from your previous deploy.

You'd probably have to mess with your recipes if you're using
capistrano, or make the tmp directory shared as well...

On 5/8/07, Matte Edens <matte at ruckuswireless.com> wrote:
> So just change your config files.  Easy peasy.
>
> Best practice, if using mongrel_cluster, is to throw it into a directory
> like what you're suggesting.  In the announcement thread for
> mongrel_cluster 1.0.1.1 it's recommended to config for using the
> /var/run directory.  But you can choose what you want.
>
> FYI
>
> matte - matte at ruckuswireless.com
>
> Doug Smith wrote:
> > I have thought this as well -- but it's not just Mongrel that does
> > this.  Ferret's DRb server also puts the .pid file into the logs
> > directory.   I'd prefer a dedicated location myself.
> >
> > Thanks,
> >
> > Doug
> >
> > On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
> >
> >> Just out of curiosity, why does mongrel_rails by default put its .pid
> >> files in the log directory rather than in tmp or tmp/pids? Putting them
> >> in the log directory seems to me like a strange decision, since they're
> >> not logs -- they're temporary state files.
> >>
> >>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From luislavena at gmail.com  Tue May  8 10:06:43 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 8 May 2007 11:06:43 -0300
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
Message-ID: <71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>

On 5/7/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Thanks for the tips Miles.  One of them really hit home:
>
> I love writing to stdout, and it's all over the place in my app.
> It's great because you can run your scripts / apps as foreground and
> get a live trace, or daemonized and it goes to the log file.  Your
> warning on this one sounds like the voice of experience, and I
> believe it.  But I'd like to understand the details.
>
> Any ideas why this is a dangerous thing to do?
>

Pete,

puts or anything that prints to stdout/stderr interfere with CGI
(Servlet dispatcher used by Rails).

Also, puts not being threadsafe (you cannot garantee "this line #1"
will get print fully form one thread and other text line from another
will without interfere eachother).


use RAILS_DEFAULT_LOGGER (or just 'logger' in your controllers, views
or models).

logger.debug (for debug level) is very helpful during development.


-- 
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  Tue May  8 11:15:43 2007
From: don at jibjab.net (Don Park)
Date: Tue, 8 May 2007 08:15:43 -0700
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <1dd361e10705072355x1b7128b3j3f90b16a54d0e22d@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
	<463F6FEF.1030700@urbacon.net>
	<42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
	<463F73EB.5020105@ruckuswireless.com>
	<1dd361e10705072355x1b7128b3j3f90b16a54d0e22d@mail.gmail.com>
Message-ID: <395299B8-6808-45CB-968A-5341513E2992@jibjab.net>

I beileve that pid files are release specific, as are the running  
mongrels.

the problem you describe is when the capistrano recipe does an svn  
update, shutdown, startup. the svn update replaces the directory tree  
under the running processes. i imagine the reasoning was to minimize  
downtime if the svn up is a time-consuming process.

a better order is to shutdown, svn up, startup. there is an  
association between the running mongrels and the tmp/pids of the  
release directory in which they started. let the running processes  
shutdown in their own release directory, then replace the release  
directory.

don

On May 7, 2007, at 11:55 PM, Eden Li wrote:

> One more reason -- in capistrano deployed setups, the log directory is
> shared among all releases, but the rails tmp directory is not.  The
> default mongrel restart recipes will complain that they can't find pid
> files because the xxx/current/tmp will have been moved to a freshly
> checked-out version of your which doesn't have the old tmp directory
> from your previous deploy.
>
> You'd probably have to mess with your recipes if you're using
> capistrano, or make the tmp directory shared as well...
>
> On 5/8/07, Matte Edens <matte at ruckuswireless.com> wrote:
>> So just change your config files.  Easy peasy.
>>
>> Best practice, if using mongrel_cluster, is to throw it into a  
>> directory
>> like what you're suggesting.  In the announcement thread for
>> mongrel_cluster 1.0.1.1 it's recommended to config for using the
>> /var/run directory.  But you can choose what you want.
>>
>> FYI
>>
>> matte - matte at ruckuswireless.com
>>
>> Doug Smith wrote:
>>> I have thought this as well -- but it's not just Mongrel that does
>>> this.  Ferret's DRb server also puts the .pid file into the logs
>>> directory.   I'd prefer a dedicated location myself.
>>>
>>> Thanks,
>>>
>>> Doug
>>>
>>> On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
>>>
>>>> Just out of curiosity, why does mongrel_rails by default put  
>>>> its .pid
>>>> files in the log directory rather than in tmp or tmp/pids?  
>>>> Putting them
>>>> in the log directory seems to me like a strange decision, since  
>>>> they're
>>>> not logs -- they're temporary state files.
>>>>
>>>>
>>
>>
>> _______________________________________________
>> 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  Tue May  8 11:21:36 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Tue, 8 May 2007 08:21:36 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
Message-ID: <257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>

Thanks for the explanation Luis.  This makes good sense.  It seems  
like Mongrel is intercepting the stdout + sterr (puts it all into  
mongrel.log), but it's not good to work with something that isn't  
threadsafe.

Makes me wonder if the rails logs are safe if you write to them from  
different mongrels in a cluster.  Any experience with this?

Thanks,
Pete



> Pete,
>
> puts or anything that prints to stdout/stderr interfere with CGI
> (Servlet dispatcher used by Rails).
>
> Also, puts not being threadsafe (you cannot garantee "this line #1"
> will get print fully form one thread and other text line from another
> will without interfere eachother).
>
>
> use RAILS_DEFAULT_LOGGER (or just 'logger' in your controllers, views
> or models).
>
> logger.debug (for debug level) is very helpful during development.
>
>
> -- 
> 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  Tue May  8 11:33:41 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 8 May 2007 12:33:41 -0300
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
	<257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
Message-ID: <71166b3b0705080833p1589094ak45fa9d9b503d755@mail.gmail.com>

On 5/8/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Thanks for the explanation Luis.  This makes good sense.  It seems
> like Mongrel is intercepting the stdout + sterr (puts it all into
> mongrel.log), but it's not good to work with something that isn't
> threadsafe.
>
> Makes me wonder if the rails logs are safe if you write to them from
> different mongrels in a cluster.  Any experience with this?
>

Are safe only under the following conditions:

2 Mongrels in the cluster don't get hit at the same time, with the
same request that takes the same time to parse and process...

That means: no :-)
(Even under labs conditions that couldn't be granted).

Page sharing of files opened between process is something difficult to
achieve, I'll suggest 1 log file per process on each port, which will
reduce chances of logfiles get corrupted.

> Thanks,
> Pete
>

You're welcome.

Good week,

-- 
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 wyhaines at gmail.com  Tue May  8 11:47:12 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 8 May 2007 08:47:12 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
	<257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
Message-ID: <f4cd26df0705080847p6441416dx17eb3310232c1a33@mail.gmail.com>

On 5/8/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Thanks for the explanation Luis.  This makes good sense.  It seems
> like Mongrel is intercepting the stdout + sterr (puts it all into
> mongrel.log), but it's not good to work with something that isn't
> threadsafe.

This probably begs some elaboration on just what puts() does.  It
writes your string in one write operation, and does the newline in a
second operation, which opens the possibility that Ruby can make a
context switch between them.  If the newline is already in the string,
though, it is just a single write operation.  You can also use write()
instead of puts() to explicitly make sure that everything is done in a
single write call.

Take a look at the code in io.c for the details.

> Makes me wonder if the rails logs are safe if you write to them from
> different mongrels in a cluster.  Any experience with this?

Even if it can be made "safe", contention from multiple processes
trying to write to one file can be a non-trivial performance hit.
This was one of my motivations for writing an async logger.  I want
all of my app logs in the same place, even if I have multiple backend
processes, without worrying about resource contention.  It's that, or
I have N log files, one for each backend process for my app.


Kirk Haines

From pete at nextengine.com  Tue May  8 11:55:31 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Tue, 8 May 2007 08:55:31 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <f4cd26df0705080847p6441416dx17eb3310232c1a33@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
	<257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
	<f4cd26df0705080847p6441416dx17eb3310232c1a33@mail.gmail.com>
Message-ID: <11DA6742-6DD4-4206-B3F4-1ECEAC4579DA@nextengine.com>

Thanks for the info Kirk, and for letting us know about your logger  
plugin.  It sounds like exactly what I need.

I think I'll override Kernel.puts to use your plugin.

-Pete


On May 8, 2007, at 8:47 AM, Kirk Haines wrote:

> On 5/8/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>> Thanks for the explanation Luis.  This makes good sense.  It seems
>> like Mongrel is intercepting the stdout + sterr (puts it all into
>> mongrel.log), but it's not good to work with something that isn't
>> threadsafe.
>
> This probably begs some elaboration on just what puts() does.  It
> writes your string in one write operation, and does the newline in a
> second operation, which opens the possibility that Ruby can make a
> context switch between them.  If the newline is already in the string,
> though, it is just a single write operation.  You can also use write()
> instead of puts() to explicitly make sure that everything is done in a
> single write call.
>
> Take a look at the code in io.c for the details.
>
>> Makes me wonder if the rails logs are safe if you write to them from
>> different mongrels in a cluster.  Any experience with this?
>
> Even if it can be made "safe", contention from multiple processes
> trying to write to one file can be a non-trivial performance hit.
> This was one of my motivations for writing an async logger.  I want
> all of my app logs in the same place, even if I have multiple backend
> processes, without worrying about resource contention.  It's that, or
> I have N log files, one for each backend process for my app.
>
>
> Kirk Haines
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From wyhaines at gmail.com  Tue May  8 12:17:14 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 8 May 2007 09:17:14 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <11DA6742-6DD4-4206-B3F4-1ECEAC4579DA@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
	<257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
	<f4cd26df0705080847p6441416dx17eb3310232c1a33@mail.gmail.com>
	<11DA6742-6DD4-4206-B3F4-1ECEAC4579DA@nextengine.com>
Message-ID: <f4cd26df0705080917h591e557aj37b2804a5ee418f0@mail.gmail.com>

On 5/8/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Thanks for the info Kirk, and for letting us know about your logger
> plugin.  It sounds like exactly what I need.
>
> I think I'll override Kernel.puts to use your plugin.

Let me know if there's anything I can bundle in the next release to
make Rails or Mongrel logging integration simpler.


Kirk Haines

From ehudros at gmail.com  Tue May  8 17:06:38 2007
From: ehudros at gmail.com (Ehud Rosenberg)
Date: Wed, 9 May 2007 00:06:38 +0300
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
Message-ID: <ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>

Hi everyone,
I am going crazy over here! :)
I just want to be able to use --clean with my mongrel_rails
cluster::start command.
I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
my config file is in /etc/mongrel_rails/config.yml
and contains:
---
log_file: log/mongrel.log
port: 8000
pid_file: /var/run/mongrel_cluster/mongrel.pid
servers: 2
address: 127.0.0.1
environment: production

in the following post it says the init.rb script from mongrel_cluster
should create the var/run directory itself, but it does not seem to do
so ( I get the message:
!!! Path to log file not valid: log/mongrel.8001.log
mongrel::start reported an error. Use mongrel_rails mongrel::start -h
to get help)

Also, when I manually set the pid file dir to what it used to be (the
log dir of my app)
it does not clean it up and still give the old message that a PID
already exists - i'm not sure if that's because it's not in /var/run
as I have seen different comments on this.

Any help would be appreciated...

Thanks!
Ehud.

PS - I have also tried running mongrel_rails cluster::configure -C /
etc/mongrel_rails/config.yml again but all it did was overwrite my
file...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070509/472910b0/attachment.html 

From ehudros at gmail.com  Tue May  8 17:10:17 2007
From: ehudros at gmail.com (Ehud Rosenberg)
Date: Wed, 9 May 2007 00:10:17 +0300
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
Message-ID: <ea839f150705081410k52ab42b5y9ee8b824f42daf3@mail.gmail.com>

Sorry for the quick double post, but the error message I pasted is wrong -
It says the log directory is wrong (and it was) but after fixing it I get
the message about the pid directory not valid: !!! Path to pid file not
valid: /var/run/mongrel_cluster/mongrel.8001.pid

I do not want to create this directory myself since I think something in my
installation is wrong and the init.rb file is not run.

On 5/9/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
>
> Hi everyone,
> I am going crazy over here! :)
> I just want to be able to use --clean with my mongrel_rails
> cluster::start command.
> I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
> my config file is in /etc/mongrel_rails/config.yml
> and contains:
> ---
> log_file: log/mongrel.log
> port: 8000
> pid_file: /var/run/mongrel_cluster/mongrel.pid
> servers: 2
> address: 127.0.0.1
> environment: production
>
> in the following post it says the init.rb script from mongrel_cluster
> should create the var/run directory itself, but it does not seem to do
> so ( I get the message:
> !!! Path to log file not valid: log/mongrel.8001.log
> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
> to get help)
>
> Also, when I manually set the pid file dir to what it used to be (the
> log dir of my app)
> it does not clean it up and still give the old message that a PID
> already exists - i'm not sure if that's because it's not in /var/run
> as I have seen different comments on this.
>
> Any help would be appreciated...
>
> Thanks!
> Ehud.
>
> PS - I have also tried running mongrel_rails cluster::configure -C /
> etc/mongrel_rails/config.yml again but all it did was overwrite my
> file...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070509/3b97fef5/attachment.html 

From jgeiger at gmail.com  Tue May  8 17:10:22 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 8 May 2007 16:10:22 -0500
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
Message-ID: <466af3440705081410j7ec0416et1d7a6478e99a3111@mail.gmail.com>

I created a startup script that just creates the
/var/run/mongrel_cluster on boot, since it's removed every time you
restart.


On 5/8/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
> Hi everyone,
> I am going crazy over here! :)
> I just want to be able to use --clean with my mongrel_rails
> cluster::start command.
> I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
> my config file is in /etc/mongrel_rails/config.yml
> and contains:
> ---
> log_file: log/mongrel.log
> port: 8000
> pid_file: /var/run/mongrel_cluster/mongrel.pid
> servers: 2
> address: 127.0.0.1
> environment: production
>
> in the following post it says the init.rb script from mongrel_cluster
> should create the var/run directory itself, but it does not seem to do
> so ( I get the message:
> !!! Path to log file not valid: log/mongrel.8001.log
> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
> to get help)
>
> Also, when I manually set the pid file dir to what it used to be (the
> log dir of my app)
> it does not clean it up and still give the old message that a PID
> already exists - i'm not sure if that's because it's not in /var/run
> as I have seen different comments on this.
>
> Any help would be appreciated...
>
> Thanks!
> Ehud.
>
> PS - I have also tried running mongrel_rails cluster::configure -C /
> etc/mongrel_rails/config.yml again but all it did was overwrite my
> file...
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From seanmichaelbrown at gmail.com  Tue May  8 17:28:26 2007
From: seanmichaelbrown at gmail.com (Sean Brown)
Date: Tue, 8 May 2007 17:28:26 -0400
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
Message-ID: <1086fb5f0705081428n5cacc679j4b4f56858ac780ac@mail.gmail.com>

On 5/8/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
>
> in the following post it says the init.rb script from mongrel_cluster
> should create the var/run directory itself, but it does not seem to do
> so ( I get the message:
> !!! Path to log file not valid: log/mongrel.8001.log
> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
> to get help)

Sounds like a ownership/permissions error.  Make sure that whatever
user you have running mongrel_cluster also has "write" permissions to
the log directory of your Rails app.  If you followed the instructions
on the Mongrel site, that user would be "mongrel".


-- 

Sean Brown

From bradley at railsmachine.com  Wed May  9 10:29:58 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Wed, 09 May 2007 10:29:58 -0400
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not
	create	/var/run/mongrel_cluster
In-Reply-To: <466af3440705081410j7ec0416et1d7a6478e99a3111@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
	<466af3440705081410j7ec0416et1d7a6478e99a3111@mail.gmail.com>
Message-ID: <4641DAE6.50408@railsmachine.com>

The new init.d script already does this. Look in 
resources/mongrel_cluster in the gem directory.

Bradley

Joey Geiger wrote:
> I created a startup script that just creates the
> /var/run/mongrel_cluster on boot, since it's removed every time you
> restart.
> 
> 
> On 5/8/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
>> Hi everyone,
>> I am going crazy over here! :)
>> I just want to be able to use --clean with my mongrel_rails
>> cluster::start command.
>> I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
>> my config file is in /etc/mongrel_rails/config.yml
>> and contains:
>> ---
>> log_file: log/mongrel.log
>> port: 8000
>> pid_file: /var/run/mongrel_cluster/mongrel.pid
>> servers: 2
>> address: 127.0.0.1
>> environment: production
>>
>> in the following post it says the init.rb script from mongrel_cluster
>> should create the var/run directory itself, but it does not seem to do
>> so ( I get the message:
>> !!! Path to log file not valid: log/mongrel.8001.log
>> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
>> to get help)
>>
>> Also, when I manually set the pid file dir to what it used to be (the
>> log dir of my app)
>> it does not clean it up and still give the old message that a PID
>> already exists - i'm not sure if that's because it's not in /var/run
>> as I have seen different comments on this.
>>
>> Any help would be appreciated...
>>
>> Thanks!
>> Ehud.
>>
>> PS - I have also tried running mongrel_rails cluster::configure -C /
>> etc/mongrel_rails/config.yml again but all it did was overwrite my
>> file...
>>
>>
>> _______________________________________________
>> 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 jgeiger at gmail.com  Wed May  9 13:06:37 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Wed, 9 May 2007 12:06:37 -0500
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <4641DAE6.50408@railsmachine.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
	<466af3440705081410j7ec0416et1d7a6478e99a3111@mail.gmail.com>
	<4641DAE6.50408@railsmachine.com>
Message-ID: <466af3440705091006u1b5e6c57p1987e4f7360a2c93@mail.gmail.com>

I had an issue with the /var/run/mongrel_cluster issue as I'm not
starting the cluster via the init.d script anymore. I'm using monit to
start up each of the mongrels by themselves. Due to that, I need to
create that directory via it's own init.d script so it exists before
monit tries to start them up...

kinda hacky, but it's working for me now.


On 5/9/07, Bradley Taylor <bradley at railsmachine.com> wrote:
> The new init.d script already does this. Look in
> resources/mongrel_cluster in the gem directory.
>
> Bradley
>
> Joey Geiger wrote:
> > I created a startup script that just creates the
> > /var/run/mongrel_cluster on boot, since it's removed every time you
> > restart.
> >
> >
> > On 5/8/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
> >> Hi everyone,
> >> I am going crazy over here! :)
> >> I just want to be able to use --clean with my mongrel_rails
> >> cluster::start command.
> >> I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
> >> my config file is in /etc/mongrel_rails/config.yml
> >> and contains:
> >> ---
> >> log_file: log/mongrel.log
> >> port: 8000
> >> pid_file: /var/run/mongrel_cluster/mongrel.pid
> >> servers: 2
> >> address: 127.0.0.1
> >> environment: production
> >>
> >> in the following post it says the init.rb script from mongrel_cluster
> >> should create the var/run directory itself, but it does not seem to do
> >> so ( I get the message:
> >> !!! Path to log file not valid: log/mongrel.8001.log
> >> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
> >> to get help)
> >>
> >> Also, when I manually set the pid file dir to what it used to be (the
> >> log dir of my app)
> >> it does not clean it up and still give the old message that a PID
> >> already exists - i'm not sure if that's because it's not in /var/run
> >> as I have seen different comments on this.
> >>
> >> Any help would be appreciated...
> >>
> >> Thanks!
> >> Ehud.
> >>
> >> PS - I have also tried running mongrel_rails cluster::configure -C /
> >> etc/mongrel_rails/config.yml again but all it did was overwrite my
> >> file...
> >>
> >>
> >> _______________________________________________
> >> 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 carl.lerche at gmail.com  Wed May  9 17:39:05 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Wed, 9 May 2007 14:39:05 -0700
Subject: [Mongrel] Tell me why my Shoutcase handler sucks!
In-Reply-To: <ab90312e0705042001ib61bfd3h5c35e11734ea88cb@mail.gmail.com>
References: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>
	<ab90312e0705042001ib61bfd3h5c35e11734ea88cb@mail.gmail.com>
Message-ID: <ab90312e0705091439r74646022o8536fc81e2ca1c8c@mail.gmail.com>

This sparks nobody's interest? That makes me a sad panda :(

On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> woops, the subject is supposed to be Shoutcast!!!
>
> On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> > So, I want to build the greatest online radio ever! (for my, currently
> > crappy, faderwave.net radio station. Right now, I'm running Icecast
> > straight up. The only problem is that managing different DJs and
> > keeping them off the air when they aren't supposed to be there is a
> > pain. There also is not one single management package that does
> > everything. My current system is a hacked together mess.
> >
> > So, I want to build a unified ruby based solution. No, I'm not going
> > to try to replace Icecast with a hacked pure ruby version, but I am
> > going to try to setup a proxy for DJs to connect to where I can manage
> > every small bit.
> >
> > To do all that, I really have to understand how Icecast works. So, I
> > hacked together a mongrel handler that can accept broadcasting clients
> > and send the stream to listeners... except I don't really know what
> > I'm doing. So, I would appreciate it if you could look over the code
> > and tell me why it sucks and how to improve it. It's really short,
> > under 100 lines with comments.
> >
> > Of course, this is just a really rough solution that I hacked together
> > to experiment with interfacing with broadcasting clients and audio
> > players. Anyway, here it is:
> >
> > http://pastie.caboo.se/59073
> >
> > Thanks,
> > -carl
> > --
> > EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> >
>
>
> --
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>


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

From ezmobius at gmail.com  Wed May  9 17:43:21 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Wed, 9 May 2007 14:43:21 -0700
Subject: [Mongrel] Tell me why my Shoutcase handler sucks!
In-Reply-To: <ab90312e0705091439r74646022o8536fc81e2ca1c8c@mail.gmail.com>
References: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>
	<ab90312e0705042001ib61bfd3h5c35e11734ea88cb@mail.gmail.com>
	<ab90312e0705091439r74646022o8536fc81e2ca1c8c@mail.gmail.com>
Message-ID: <0C5629D3-92E2-4789-BAB8-3AB1819F5587@brainspl.at>


	Hey Carl-- I thought it was cool ;)

Cheers-
-Ezra


On May 9, 2007, at 2:39 PM, Carl Lerche wrote:

> This sparks nobody's interest? That makes me a sad panda :(
>
> On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
>> woops, the subject is supposed to be Shoutcast!!!
>>
>> On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
>>> So, I want to build the greatest online radio ever! (for my,  
>>> currently
>>> crappy, faderwave.net radio station. Right now, I'm running Icecast
>>> straight up. The only problem is that managing different DJs and
>>> keeping them off the air when they aren't supposed to be there is a
>>> pain. There also is not one single management package that does
>>> everything. My current system is a hacked together mess.
>>>
>>> So, I want to build a unified ruby based solution. No, I'm not going
>>> to try to replace Icecast with a hacked pure ruby version, but I am
>>> going to try to setup a proxy for DJs to connect to where I can  
>>> manage
>>> every small bit.
>>>
>>> To do all that, I really have to understand how Icecast works. So, I
>>> hacked together a mongrel handler that can accept broadcasting  
>>> clients
>>> and send the stream to listeners... except I don't really know what
>>> I'm doing. So, I would appreciate it if you could look over the code
>>> and tell me why it sucks and how to improve it. It's really short,
>>> under 100 lines with comments.
>>>
>>> Of course, this is just a really rough solution that I hacked  
>>> together
>>> to experiment with interfacing with broadcasting clients and audio
>>> players. Anyway, here it is:
>>>
>>> http://pastie.caboo.se/59073
>>>
>>> Thanks,
>>> -carl
>>> --
>>> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>>>
>>
>>
>> --
>> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>>
>
>
> -- 
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

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



From veeraa.1 at gmail.com  Thu May 10 00:04:15 2007
From: veeraa.1 at gmail.com (veeraa bose)
Date: Thu, 10 May 2007 09:34:15 +0530
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.5
Message-ID: <1c22b00705092104m7ea1ed5avede22d01b4f6fbce@mail.gmail.com>

Dear  ALL,
I saw this in article from mongrel faq,

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..
Could anybody please tell me  in which  file I have to update this
"ActiveRecord::Base.verification_timeout = 14400"


Thanks and regards
veeraa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070510/16ca9146/attachment.html 

From luislavena at gmail.com  Thu May 10 00:07:08 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 10 May 2007 01:07:08 -0300
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.5
In-Reply-To: <1c22b00705092104m7ea1ed5avede22d01b4f6fbce@mail.gmail.com>
References: <1c22b00705092104m7ea1ed5avede22d01b4f6fbce@mail.gmail.com>
Message-ID: <71166b3b0705092107o3d8eecdag3e41d9494b366e4e@mail.gmail.com>

On 5/10/07, veeraa bose <veeraa.1 at gmail.com> wrote:
> Dear  ALL,
> I saw this in article from mongrel faq,
>
> 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..Could anybody please tell me  in which  file
> I have to update this "ActiveRecord::Base.verification_timeout = 14400"
>

config/environment.rb will do

--
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 secrectcode at gmail.com  Sat May 12 13:33:51 2007
From: secrectcode at gmail.com (Guy Nick)
Date: Sun, 13 May 2007 01:33:51 +0800
Subject: [Mongrel] Mongrel + Rails keep connecting DB
Message-ID: <1fae7c930705121033v52b086cfm24994c8ac38c6529@mail.gmail.com>

Hi,

I use apache2 + mongrel_cluster + rails + mysql  to run my website.
When I read mysql log, I found that rails will connect to mysql every sql
command.
And the connection will not be closed after the sql command is done.
I guess the connection cache will not be retrieved somehow.

It will not happened when I use either webrick or lighttpd.
Any idea about this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070513/69078e4e/attachment.html 

From pete at nextengine.com  Mon May 14 17:40:12 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Mon, 14 May 2007 14:40:12 -0700
Subject: [Mongrel] Timeout message
Message-ID: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>

Anybody seen this message before?  I see it over and over in one of  
my mongrel processes log files.  I've never seen it before today.

/usr/local/bin/mongrel_rails:16Mon May 14 20:44:30 +0000 2007: Error  
calling Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed  
out this thread: shutdown>Thread #<Thread:0x2ae6288dbc40 sleep> is  
too old, killing.

Thanks,
Pete

From nstlaurent at wantedtech.com  Tue May 15 09:27:25 2007
From: nstlaurent at wantedtech.com (Nicolas St-Laurent)
Date: Tue, 15 May 2007 09:27:25 -0400
Subject: [Mongrel] Timeout message
In-Reply-To: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>
References: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>
Message-ID: <D3AF054B-7351-40A0-B0C2-EA98D15849CE@wantedtech.com>


Le 07-05-14 ? 17:40, Pete DeLaurentis a ?crit :

> Anybody seen this message before?  I see it over and over in one of
> my mongrel processes log files.  I've never seen it before today.
>
> /usr/local/bin/mongrel_rails:16Mon May 14 20:44:30 +0000 2007: Error
> calling Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed
> out this thread: shutdown>Thread #<Thread:0x2ae6288dbc40 sleep> is
> too old, killing.
>
> Thanks,
> Pete
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

Hi Pete,

I've got the same issue here on one of my RoR application. I doesn't  
found the real cause nor the solution. Since this application makes  
complex  requests on big tables (>29M records), I guess that doesn't  
helps. For now, I restart mongrel servers each morning with a crontab  
(the timeout occurs after some running time) and timeout stop to occurs.

Nicolas



From john-subscribed at recaffeinated.com  Tue May 15 11:19:25 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Tue, 15 May 2007 11:19:25 -0400
Subject: [Mongrel] Timeout message
In-Reply-To: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>
References: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>
Message-ID: <b46641a0705150819u4e1345cep773e83469e0c3c3@mail.gmail.com>

Pete, i had a problem with mongrel sleeping and resulting in errors (I think
404).  It essentially made it look like the app wasn't running and then it
would (reluctantly) start  after a browser refresh.  I can't remember the
specific error.  Anyway, my solution was to create a script that polled my
rails apps every 15 minutes to an hour and kept them alive.

This might be something completely different, but it sounds somewhat
similar.

John

On 5/14/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>
> Anybody seen this message before?  I see it over and over in one of
> my mongrel processes log files.  I've never seen it before today.
>
> /usr/local/bin/mongrel_rails:16Mon May 14 20:44:30 +0000 2007: Error
> calling Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed
> out this thread: shutdown>Thread #<Thread:0x2ae6288dbc40 sleep> is
> too old, killing.
>
> Thanks,
> Pete
> _______________________________________________
> 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/20070515/9f3f74fb/attachment-0001.html 

From john-subscribed at recaffeinated.com  Tue May 15 11:28:50 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Tue, 15 May 2007 11:28:50 -0400
Subject: [Mongrel] AJAX File Uploads with Rails
Message-ID: <b46641a0705150828h5b48b160ybb06e778afc57143@mail.gmail.com>

Can someone clear up this issue with file uploads for me?  I have the code
from Mongrel Upload Progress (
http://mongrel.rubyforge.org/docs/upload_progress.html) running, but I'm a
little confused at how to integrate this into my app.  Should I roll the
controller methods in the controller I want to use or do you handle the file
uploads and then somehow push the rest of the form data to the other
controller?   Doing the first option sounds best, but then if there are
multiple views that need uploads, I would need to add more handlers to the
mongrel upload_progress conf file.

What's the best way to handle errors in this case?  Specifically, if there's
an error in the form, it would be much faster to find that error and send
back an error message, rather than waiting for files to upload then
processing the form.

Anyone have any ideas?


Thanks,

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

From todd.fisher at gmail.com  Tue May 15 13:10:28 2007
From: todd.fisher at gmail.com (Todd Fisher)
Date: Tue, 15 May 2007 13:10:28 -0400
Subject: [Mongrel] esi cache server built on mongrel
Message-ID: <e9a952090705151010w7f7d3090xd41cea305b9af97c@mail.gmail.com>

Hi all,

   I just wanted to share a project I've been working on now for a few
months.  It's still far from complete, but has already been very useful for
me and my coworkers.  I'm calling it mongrel-esi.  ESI stands for Edge Side
Include.  The specs live here, http://www.w3.org/TR/esi-lang.  I currently
only have support for <esi:include, <esi:try, <esi:attempt, and
<esi:except.    Also, it supports HTTP_COOKIES, so fragments can be
conditionally cached by a cookie.


I have implemented a few different parsers for ESI, one using hpricot to
process the whole document and another that uses Transfer-Encoding: chunked
to stream the fragments back to the browser as they are available.


I'm hoping this might be useful to others and am interested to get
feedback.
The project page is here => http://code.google.com/p/mongrel-esi/


Thanks,
Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070515/2e798ad8/attachment.html 

From zedshaw at zedshaw.com  Tue May 15 14:07:25 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 15 May 2007 14:07:25 -0400
Subject: [Mongrel] esi cache server built on mongrel
In-Reply-To: <e9a952090705151010w7f7d3090xd41cea305b9af97c@mail.gmail.com>
References: <e9a952090705151010w7f7d3090xd41cea305b9af97c@mail.gmail.com>
Message-ID: <20070515140725.d920ac61.zedshaw@zedshaw.com>

On Tue, 15 May 2007 13:10:28 -0400
"Todd Fisher" <todd.fisher at gmail.com> wrote:

> Hi all,
> 
>    I just wanted to share a project I've been working on now for a few
> months.  It's still far from complete, but has already been very useful for
> me and my coworkers.  I'm calling it mongrel-esi.  ESI stands for Edge Side
> Include.  The specs live here, http://www.w3.org/TR/esi-lang.  I currently
> only have support for <esi:include, <esi:try, <esi:attempt, and
> <esi:except.    Also, it supports HTTP_COOKIES, so fragments can be
> conditionally cached by a cookie.
> 
> 
> I have implemented a few different parsers for ESI, one using hpricot to
> process the whole document and another that uses Transfer-Encoding: chunked
> to stream the fragments back to the browser as they are available.
> 
> 
> I'm hoping this might be useful to others and am interested to get
> feedback.
> The project page is here => http://code.google.com/p/mongrel-esi/

That's really cool.  I'll check it out at railsconf if I'm not busy.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From Luke.Stark at mathworks.com  Wed May 16 09:02:44 2007
From: Luke.Stark at mathworks.com (Luke Stark)
Date: Wed, 16 May 2007 09:02:44 -0400
Subject: [Mongrel] Hit mongrel once...all is well,
	hit it again...stack level too deep?
Message-ID: <7224B63940F10F40A48AC423597ADE57133C03F0@MESSAGE-AH.ad.mathworks.com>

Hi there.

 

I've dropped a mongrel log item here:

 

http://pastie.caboo.se/62052

 

I can hit my app fine, once. Hitting it again gives me a 500 error and
this log entry. I think it's application code causing the problem as I
have a second app running that doesn't have this behavior, but I'm
unsure how to proceed finding root cause here.

 

Suggestions?

 

-L

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

From Luke.Stark at mathworks.com  Wed May 16 10:35:52 2007
From: Luke.Stark at mathworks.com (Luke Stark)
Date: Wed, 16 May 2007 10:35:52 -0400
Subject: [Mongrel] Ping. (Just testing.) - EOM.
Message-ID: <7224B63940F10F40A48AC423597ADE57133C074B@MESSAGE-AH.ad.mathworks.com>

 

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

From Luke.Stark at mathworks.com  Wed May 16 09:16:28 2007
From: Luke.Stark at mathworks.com (Luke Stark)
Date: Wed, 16 May 2007 09:16:28 -0400
Subject: [Mongrel] Hit mongrel once...all is well,
	hit it again...stack level too deep?
Message-ID: <7224B63940F10F40A48AC423597ADE57133C046A@MESSAGE-AH.ad.mathworks.com>

Is this related to the current stack size for the user mongrel is
running as?

 

Current stack is 10240k. fyi.

 

Any hints or page references are appreciated.

 

-L

 

________________________________

From: Luke Stark 
Sent: Wednesday, May 16, 2007 9:03 AM
To: 'mongrel-users at rubyforge.org'
Subject: Hit mongrel once...all is well, hit it again...stack level too
deep?

 

Hi there.

 

I've dropped a mongrel log item here:

 

http://pastie.caboo.se/62052

 

I can hit my app fine, once. Hitting it again gives me a 500 error and
this log entry. I think it's application code causing the problem as I
have a second app running that doesn't have this behavior, but I'm
unsure how to proceed finding root cause here.

 

Suggestions?

 

-L

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

From Luke.Stark at mathworks.com  Wed May 16 13:11:00 2007
From: Luke.Stark at mathworks.com (Luke Stark)
Date: Wed, 16 May 2007 13:11:00 -0400
Subject: [Mongrel] Hit mongrel once...all is well,
	hit it again...stack level too deep?
In-Reply-To: <7224B63940F10F40A48AC423597ADE57133C03F0@MESSAGE-AH.ad.mathworks.com>
Message-ID: <7224B63940F10F40A48AC423597ADE57133C0BAF@MESSAGE-AH.ad.mathworks.com>

Duh. Never mind...the user I was running as had an irbrc file that was
overriding Object. Gah!

 

-L

 

________________________________

From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luke Stark
Sent: Wednesday, May 16, 2007 9:03 AM
To: mongrel-users at rubyforge.org
Subject: [Mongrel] Hit mongrel once...all is well,hit it again...stack
level too deep?

 

Hi there.

 

I've dropped a mongrel log item here:

 

http://pastie.caboo.se/62052

 

I can hit my app fine, once. Hitting it again gives me a 500 error and
this log entry. I think it's application code causing the problem as I
have a second app running that doesn't have this behavior, but I'm
unsure how to proceed finding root cause here.

 

Suggestions?

 

-L

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070516/594d8390/attachment-0001.html 

From john-subscribed at recaffeinated.com  Wed May 16 13:48:42 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Wed, 16 May 2007 13:48:42 -0400
Subject: [Mongrel] Rails, Mongrel and Rmagick
Message-ID: <b46641a0705161048k3d54ebbwb23642d1449644e9@mail.gmail.com>

i have a rails app with a form that allows uploading an image file.  I take
the image file and read it into rmagick to verify that it's an image.  For
some reason I can't catch an exception thrown by rmagick inside the app.
After an invalid image file is uploaded the process just hangs.  I have to
kill mongrel and restart to use the app again.

img = Magick::Image::read(@uploaded_file.path).first

This line above should throw a Magick::ImageMagickError exception.  I've
confirmed this with a simple ruby script.

I've tried adding breakpoints and as soon as this line is reached there's no
coming back, even the breakpointer hangs.

I pasted the method from my active record class here:
http://pastie.caboo.se/62122 .

Does anyone have any ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070516/2c9c5cd6/attachment.html 

From john-subscribed at recaffeinated.com  Thu May 17 09:28:52 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Thu, 17 May 2007 09:28:52 -0400
Subject: [Mongrel] Rails, Mongrel and Rmagick
In-Reply-To: <b46641a0705161048k3d54ebbwb23642d1449644e9@mail.gmail.com>
References: <b46641a0705161048k3d54ebbwb23642d1449644e9@mail.gmail.com>
Message-ID: <b46641a0705170628s5ba2b56dv1dbbdf8ef22d9590@mail.gmail.com>

I figured out my problem here, but I don't think it explains the entire
issue.  The problem was that some files where not uploading as image files
and instead the @uploaded_file was a String.  If I check the class of the
file first I can work around the problem.  I still don't think it makes
sense that there are no exceptions thrown.

Here's a simplified look at the code in my rails model.

    if @uploaded_file.class == File || @uploaded_file.class == Tempfile
      begin
        img = Magick::Image::read(@uploaded_file.path).first
        self.data = @uploaded_file.read
        self.attributes = {:data_format => img.format, :height => img.rows,
:width => img.columns, :filesize => img.filesize}
        return true
      rescue
        # there was an error
      end
    end


On 5/16/07, John Lauck <john-subscribed at recaffeinated.com> wrote:
>
> i have a rails app with a form that allows uploading an image file.  I
> take the image file and read it into rmagick to verify that it's an image.
> For some reason I can't catch an exception thrown by rmagick inside the
> app.  After an invalid image file is uploaded the process just hangs.  I
> have to kill mongrel and restart to use the app again.
>
> img = Magick::Image::read(@uploaded_file.path).first
>
> This line above should throw a Magick::ImageMagickError exception.  I've
> confirmed this with a simple ruby script.
>
> I've tried adding breakpoints and as soon as this line is reached there's
> no coming back, even the breakpointer hangs.
>
> I pasted the method from my active record class here:
> http://pastie.caboo.se/62122 .
>
> Does anyone have any ideas?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070517/a9c0198c/attachment.html 

From craig at itpartners.co.nz  Thu May 17 23:25:15 2007
From: craig at itpartners.co.nz (Craig Box)
Date: Fri, 18 May 2007 15:25:15 +1200
Subject: [Mongrel] No return status from mongrel upload progress (and thus
	no updates on the bar)
Message-ID: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>

Hi all,

I'm using Boxroom (http://boxroom.rubyforge.org/) and trying to get
upload progress working.  I've also been testing the sample code at
http://itblog.mcgeecorp.com/2007/5/15/mongrel-upload-progress-demo/.

I run a Mongrel cluster, and so am using drb (as per
http://mongrel.rubyforge.org/docs/upload_progress.html).  Starting up
rails, I get lots of useful-sounding output:

** Starting Mongrel listening at 0.0.0.0:3000
** Loading script/../config/../config/mongrel_upload_progress.conf
external config script

The bar doesn't draw updates - if I connect with irb (as per the
upload_progress page)

irb(main):001:0> uploads = get_status
=> #<DRb::DRbObject:0xb7d1ef04 @ref=nil, @uri="druby://0.0.0.0:2999">
irb(main):002:0> uploads.list
=> []

Nice regular output in my development.log:

Processing UploadsController#upload_progress (for 127.0.0.1 at
2007-05-18 15:20:29) [POST]
  Parameters: {"action"=>"upload_progress", "controller"=>"uploads",
"upload_id"=>"aff07334-04ee-11dc-bd4b-000d608392b8"}
Completed in 0.00966 (103 reqs/sec) | Rendering: 0.00848 (87%) | 200 OK
[http://localhost/uploads/upload_progress?upload_id=aff07334-04ee-11dc-b
d4b-000d608392b8]


Processing UploadsController#upload_progress (for 127.0.0.1 at
2007-05-18 15:21:11) [POST]
  Parameters: {"action"=>"upload_progress", "controller"=>"uploads",
"upload_id"=>"aff07334-04ee-11dc-bd4b-000d608392b8"}
Completed in 0.00909 (109 reqs/sec) | Rendering: 0.00800 (88%) | 200 OK
[http://localhost/uploads/upload_progress?upload_id=aff07334-04ee-11dc-b
d4b-000d608392b8]

status is always nil.  It sounds like exactly the same problem as this
person is having: http://www.ruby-forum.com/topic/102380


The entire setup is running on Ubuntu Dapper, with mongrel 1.0.1,
cluster/upload_progress 0.2.1, rails 1.2.3 and rubygems 0.9.3.

Any ideas?  Should I (as per
http://rubyforge.org/pipermail/mongrel-users/2006-November/002237.html)
look at running something other than Mongrel for accepting uploads?


Regards,
Craig


From john-subscribed at recaffeinated.com  Fri May 18 10:05:18 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Fri, 18 May 2007 10:05:18 -0400
Subject: [Mongrel] No return status from mongrel upload progress (and
	thus no updates on the bar)
In-Reply-To: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>
References: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>
Message-ID: <b46641a0705180705q1d5d3217r1dc092d4e4fc43ea@mail.gmail.com>

Craig,

I have no experience with Boxroom, but I did just recently get the Mongrel
Upload Progress working using the instructions on mongrel's site.

I'm developing locally on OS X, haven't tested moving it to my Cent OS
production environment yet.

Anyway, are you running the upload.rb mentioned on the site?  I forgot to
execute that script along with mongrel a couple times and couldn't figure
out what was wrong.  I also changed all the 0.0.0.0 IPs  serving drb to
127.0.0.1 and it worked at that point.  It was hard to gauge the upload
progress because I only tested it on my local LAN so all uploads were at
100% within a second.  However, it seemed to be working fine.


John

On 5/17/07, Craig Box <craig at itpartners.co.nz> wrote:
>
> Hi all,
>
> I'm using Boxroom (http://boxroom.rubyforge.org/) and trying to get
> upload progress working.  I've also been testing the sample code at
> http://itblog.mcgeecorp.com/2007/5/15/mongrel-upload-progress-demo/.
>
> I run a Mongrel cluster, and so am using drb (as per
> http://mongrel.rubyforge.org/docs/upload_progress.html).  Starting up
> rails, I get lots of useful-sounding output:
>
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Loading script/../config/../config/mongrel_upload_progress.conf
> external config script
>
> The bar doesn't draw updates - if I connect with irb (as per the
> upload_progress page)
>
> irb(main):001:0> uploads = get_status
> => #<DRb::DRbObject:0xb7d1ef04 @ref=nil, @uri="druby://0.0.0.0:2999">
> irb(main):002:0> uploads.list
> => []
>
> Nice regular output in my development.log:
>
> Processing UploadsController#upload_progress (for 127.0.0.1 at
> 2007-05-18 15:20:29) [POST]
>   Parameters: {"action"=>"upload_progress", "controller"=>"uploads",
> "upload_id"=>"aff07334-04ee-11dc-bd4b-000d608392b8"}
> Completed in 0.00966 (103 reqs/sec) | Rendering: 0.00848 (87%) | 200 OK
> [http://localhost/uploads/upload_progress?upload_id=aff07334-04ee-11dc-b
> d4b-000d608392b8]
>
>
> Processing UploadsController#upload_progress (for 127.0.0.1 at
> 2007-05-18 15:21:11) [POST]
>   Parameters: {"action"=>"upload_progress", "controller"=>"uploads",
> "upload_id"=>"aff07334-04ee-11dc-bd4b-000d608392b8"}
> Completed in 0.00909 (109 reqs/sec) | Rendering: 0.00800 (88%) | 200 OK
> [http://localhost/uploads/upload_progress?upload_id=aff07334-04ee-11dc-b
> d4b-000d608392b8]
>
> status is always nil.  It sounds like exactly the same problem as this
> person is having: http://www.ruby-forum.com/topic/102380
>
>
> The entire setup is running on Ubuntu Dapper, with mongrel 1.0.1,
> cluster/upload_progress 0.2.1, rails 1.2.3 and rubygems 0.9.3.
>
> Any ideas?  Should I (as per
> http://rubyforge.org/pipermail/mongrel-users/2006-November/002237.html)
> look at running something other than Mongrel for accepting uploads?
>
>
> Regards,
> Craig
>
> _______________________________________________
> 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/20070518/a1701614/attachment.html 

From luislavena at gmail.com  Sat May 19 16:05:40 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 19 May 2007 17:05:40 -0300
Subject: [Mongrel] Warning: mongrel_service and users of mysql
Message-ID: <71166b3b0705191305j343990ccp9411ba9c0bddd96b@mail.gmail.com>

Hello Mongrels,

I know I've been promising an update to mongrel_service, I'm working
on it, and will shine, I promise.

Anyway, for those using mongrel_service with MySQL, 5.x community
series, I must inform:

There is a bug report at mysql (#25621) [1] that describe the
situation with sleeping threads that didn't respond in timely fashion.

That bug causes mongrel_service to stop abnormally (premature
termination, broken pipe and other errors describing the same
situation.

As far mongrel and ruby code is involved, mongrel_service send the
right things to stop them, but mysql driver add delays and take longer
in release these locks, making the service fail.

Wanted to share this with the list, for those without luck that
couldn't get into RailsConf this year ;-)

Good weekend everybody.

[1] http://bugs.mysql.com/25621

-- 
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 andrew at andrewloe.com  Sat May 19 18:45:09 2007
From: andrew at andrewloe.com (W. Andrew Loe III)
Date: Sat, 19 May 2007 18:45:09 -0400
Subject: [Mongrel] 100% CPU
Message-ID: <9007bd350705191545x3dddc836o33a571b365c7ef32@mail.gmail.com>

I'm running Mephisto on two mongrels behind Apache 2.2. I'm getting HUGE
spikes to 100% of CPU on uncached (not served by Apache) requests. These
requests also take an exorbitant amount of time, ~20 seconds when my
production.log reports the database responding in > .2 seconds and the
render time is > .002 seconds. I have no idea where to start with debugging
this. I have two other rails apps that are extremely snappy. Could it be an
issue generating cached pages?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070519/258210de/attachment.html 

From craig at itpartners.co.nz  Sat May 19 20:30:40 2007
From: craig at itpartners.co.nz (Craig Box)
Date: Sun, 20 May 2007 12:30:40 +1200
Subject: [Mongrel] No return status from mongrel upload progress
	(andthus no updates on the bar)
References: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>
	<b46641a0705180705q1d5d3217r1dc092d4e4fc43ea@mail.gmail.com>
Message-ID: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C360695@penfold.itpartners.co.nz>

> Anyway, are you running the upload.rb mentioned on the site?  I forgot to
> execute that script along with mongrel a couple times and couldn't figure
> out what was wrong.  I also changed all the 0.0.0.0 IPs  serving drb to
> 127.0.0.1 and it worked at that point.  It was hard to gauge the upload
> progress because I only tested it on my local LAN so all uploads were at
> 100% within a second.  However, it seemed to be working fine.

Yes, I am running all the right things, as far as I can tell.. a friend ran it on his machine and it all seemed to work for him.  There must be something subtle I'm missing.  Changing 0.0.0.0 to 127.0.0.1 didn't change anything.  (As an aside, if it matters, I'm starting mongrel on port 3000, and tunneling it to my web browser via SSH.)

I've just read through the thread at http://rubyforge.org/pipermail/mongrel-users/2007-February/003028.html - another similar problem.  Ultimately, a flash upload plugin would be the correct answer, but that will take a bit more time to implement (can anyone point me at a guide?) and the upload progress is the only part of the puzzle missing for me in the current version of the code.

Regards
Craig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3608 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070520/f047fd8e/attachment-0001.bin 

From craig at itpartners.co.nz  Sun May 20 00:48:47 2007
From: craig at itpartners.co.nz (Craig Box)
Date: Sun, 20 May 2007 16:48:47 +1200
Subject: [Mongrel] No return status from mongrel upload progress (and
	thus no updates on the bar)
References: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>
	<b46641a0705180705q1d5d3217r1dc092d4e4fc43ea@mail.gmail.com>
	<87ECFF3F9E2DBD4FBD1F74F9A80BBD1C360695@penfold.itpartners.co.nz>
Message-ID: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C360699@penfold.itpartners.co.nz>

To reply to my own message..

> Anyway, are you running the upload.rb mentioned on the site?  I forgot to
> execute that script along with mongrel a couple times and couldn't figure
> out what was wrong.  I also changed all the 0.0.0.0 IPs  serving drb to
> 127.0.0.1 and it worked at that point.  It was hard to gauge the upload
> progress because I only tested it on my local LAN so all uploads were at
> 100% within a second.  However, it seemed to be working fine.

Running with or without DRb doesn't matter.

If I manually connect to where the log suggests my 200 OKs are coming from, I get similar output to http://rubyforge.org/pipermail/mongrel-users/2006-December/002584.html - 

try {

} catch (e) { alert('RJS error:\n\n' + e.toString()); alert(''); throw e }

with no JS to actually change the content of the bar.

I don't have any routes to change (as per http://rubyforge.org/pipermail/mongrel-users/2007-February/002995.html) and I am not using it behind a proxy.

Any of this jog any memories with anyone?

Craig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3557 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070520/b3d51059/attachment.bin 

From andrew at geni.com  Mon May 21 18:52:03 2007
From: andrew at geni.com (Andrew Arrow)
Date: Mon, 21 May 2007 15:52:03 -0700
Subject: [Mongrel] swifty fly?
Message-ID: <46522293.5050100@geni.com>

I heard about a new mongrel plugin or version that's single threaded and 
uses non-blocking IO with events.  It's called something like "swifty 
fly".  Anyone have a link for it?

Thanks.


From wyhaines at gmail.com  Mon May 21 19:11:39 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Mon, 21 May 2007 17:11:39 -0600
Subject: [Mongrel] swifty fly?
In-Reply-To: <46522293.5050100@geni.com>
References: <46522293.5050100@geni.com>
Message-ID: <f4cd26df0705211611i660f5de0y4bf10a4ec54a92be@mail.gmail.com>

On 5/21/07, Andrew Arrow <andrew at geni.com> wrote:
> I heard about a new mongrel plugin or version that's single threaded and
> uses non-blocking IO with events.  It's called something like "swifty
> fly".  Anyone have a link for it?

Swiftiply.

http://swiftiply.swiftcore.org


Swiftiply itself is a clustering proxy server for web apps with a
twist; it runs as a server, but the backends are clients to it,
instead of standalone servers.  It is bundled with two hotpatches to
mongrel to make two different flavors of mongrel.

One is swiftiplied_mongrel.  It is an event based mongrel that is
intended to be used with Swiftiply.

The other is evented_mongrel.  This was sort of a step on the way to
implementing swiftiplied_mongrel, and is just a mongrel that runs in
an event loop instead of using threads.

The intention with both is that the patches are transparent to any
Mongrel handlers, so the Rails or Camping or Merb or Ramaze or
whatever handlers just work.


Kirk Haines

From kordova at gmail.com  Mon May 21 19:11:31 2007
From: kordova at gmail.com (Kordova)
Date: Mon, 21 May 2007 19:11:31 -0400
Subject: [Mongrel] swifty fly?
In-Reply-To: <46522293.5050100@geni.com>
References: <46522293.5050100@geni.com>
Message-ID: <D92CA9A5-53DD-42B6-9848-96B19692BE0C@gmail.com>

Swiftiply? http://swiftiply.swiftcore.org/index.html

On May 21, 2007, at 6:52 PM, Andrew Arrow wrote:

> I heard about a new mongrel plugin or version that's single  
> threaded and
> uses non-blocking IO with events.  It's called something like "swifty
> fly".  Anyone have a link for it?
>
> Thanks.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From luislavena at gmail.com  Mon May 21 19:12:58 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 21 May 2007 20:12:58 -0300
Subject: [Mongrel] swifty fly?
In-Reply-To: <46522293.5050100@geni.com>
References: <46522293.5050100@geni.com>
Message-ID: <71166b3b0705211612k6f926278gf184552259c38b11@mail.gmail.com>

On 5/21/07, Andrew Arrow <andrew at geni.com> wrote:
> I heard about a new mongrel plugin or version that's single threaded and
> uses non-blocking IO with events.  It's called something like "swifty
> fly".  Anyone have a link for it?
>

http://swiftiply.swiftcore.org/

Post form Ezra:

http://brainspl.at/articles/2007/05/12/event-driven-mongrel-and-swiftiply-proxy

-- 
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 faisal at faisal.com  Mon May 21 19:22:57 2007
From: faisal at faisal.com (Faisal N Jawdat)
Date: Mon, 21 May 2007 19:22:57 -0400
Subject: [Mongrel] swifty fly?
In-Reply-To: <46522293.5050100@geni.com>
References: <46522293.5050100@geni.com>
Message-ID: <95D0B9FB-7DA4-4380-A9C1-083A0E4B66BA@faisal.com>

I'm very interested in this thing but am not going to touch it until  
Zed blesses it.  I'll probably also wind up benchmarking it against  
everything else (nginx, lighty 1.5, apache), but if someone else does  
it first please post here and all that.

-faisal

On May 21, 2007, at 6:52 PM, Andrew Arrow wrote:

> I heard about a new mongrel plugin or version that's single  
> threaded and
> uses non-blocking IO with events.  It's called something like "swifty
> fly".  Anyone have a link for it?
>
> Thanks.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From luislavena at gmail.com  Mon May 21 19:40:42 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 21 May 2007 20:40:42 -0300
Subject: [Mongrel] swifty fly?
In-Reply-To: <95D0B9FB-7DA4-4380-A9C1-083A0E4B66BA@faisal.com>
References: <46522293.5050100@geni.com>
	<95D0B9FB-7DA4-4380-A9C1-083A0E4B66BA@faisal.com>
Message-ID: <71166b3b0705211640s4c70fd25ma83e852ab24932af@mail.gmail.com>

On 5/21/07, Faisal N Jawdat <faisal at faisal.com> wrote:
> I'm very interested in this thing but am not going to touch it until
> Zed blesses it.

I don't know if Zed will "bless it", (the evented_mongrel patch).

Event-Driven socket programming is a good thing, but ruby support for it isn't.

As far as my tests goes, a few things float into the "nebulossa"
regarding re-entrant points in Ruby VM (the whole event-machine).

I use Events as programming model in lots of projects, including ones
with sockets, but none of them in ruby.

Guess Zed evaluated the same problem when creating Mongrel.

> I'll probably also wind up benchmarking it against
> everything else (nginx, lighty 1.5, apache), but if someone else does
> it first please post here and all that.
>

Benchmarks? statistics? If anyone do that please:

- Run the test across the network, not locally (to actually use the
network card).
- Don't run these a few minutes, but a week will provide a good result
of application behavior across time.
- Measure everything, at least 5 times prior calculating "means" ;-)

-- 
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 david at vrensk.com  Mon May 21 20:00:40 2007
From: david at vrensk.com (David Vrensk)
Date: Tue, 22 May 2007 02:00:40 +0200
Subject: [Mongrel] swifty fly?
In-Reply-To: <46522293.5050100@geni.com>
References: <46522293.5050100@geni.com>
Message-ID: <81b453920705211700j572b52e5kc70498dcbefba96c@mail.gmail.com>

On 5/22/07, Andrew Arrow <andrew at geni.com> wrote:
>
> I heard about a new mongrel plugin or version that's single threaded and
> uses non-blocking IO with events.  It's called something like "swifty
> fly".  Anyone have a link for it?


Well, with the caveats from Faisal and Luis, enjoy:

http://swiftiply.swiftcore.org/index.html

(by way of
http://www.rubyinside.com/swiftiply-a-step-forward-in-rails-serving-489.html
)

/David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070522/93f097ad/attachment.html 

From faisal at faisal.com  Mon May 21 20:17:27 2007
From: faisal at faisal.com (Faisal N Jawdat)
Date: Mon, 21 May 2007 20:17:27 -0400
Subject: [Mongrel] swifty fly?
In-Reply-To: <71166b3b0705211640s4c70fd25ma83e852ab24932af@mail.gmail.com>
References: <46522293.5050100@geni.com>
	<95D0B9FB-7DA4-4380-A9C1-083A0E4B66BA@faisal.com>
	<71166b3b0705211640s4c70fd25ma83e852ab24932af@mail.gmail.com>
Message-ID: <05DB8C26-7363-4EF3-8C75-1F482975936F@faisal.com>

On May 21, 2007, at 7:40 PM, Luis Lavena wrote:
> I don't know if Zed will "bless it", (the evented_mongrel patch).

If Zed thinks it's probably a reasonable thing to use even if he  
doesn't want to incorporate it, it's probably a reasonable thing to  
use.  If Zed looks at it, gags, and points out that the entire system  
will break as of Mongrel 1.02, it's probably a bad idea to go near.   
There's a range in between, obviously...

-faisal




From zedshaw at zedshaw.com  Mon May 21 20:29:44 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 21 May 2007 20:29:44 -0400
Subject: [Mongrel] swifty fly?
In-Reply-To: <46522293.5050100@geni.com>
References: <46522293.5050100@geni.com>
Message-ID: <20070521202944.623e2466.zedshaw@zedshaw.com>

On Mon, 21 May 2007 15:52:03 -0700
Andrew Arrow <andrew at geni.com> wrote:

> I heard about a new mongrel plugin or version that's single threaded and 
> uses non-blocking IO with events.  It's called something like "swifty 
> fly".  Anyone have a link for it?

There's was quite a few announced "mongrel needs some help" kind of
proxies:

* Swiftiply by Kirk Haines (as he mentioned)
 http://swiftiply.swiftcore.org/index.html

* Fuzed by Dave Fayram and Tom Preston-Warner (which is actually F U Zed
if Rumor is right) http://code.google.com/p/fuzed/

* drproxy by Lucas Carlson which will have a project page soon, but you
can grab super alpha code at http://rufy.com/drproxy.tgz

The interesting thing is all three have different approaches to the
same problem, but Fuzed and drproxy use Erlang rather than Ruby.

Fuzed is using Yaws (an Erlang web server) so it can do smarter HTTP
level load balancing and other goodies for a web app.

drproxy is doing just TCP level routing and clustering so it could work
for just about any protocol, but might not be so smart.

A big thing about all three solutions is they are auto-configurable in
that you fire up mongrel nodes and they tell the proxy about their
existence.  In a shared hosting environment this is a total disaster
for security (since anyone would just join your proxy without proper
encryption and security involved).  BUT, for people doing deployed apps
like most of the above authors, this is a really useful feature.

Finally, I'm holding judgement and not going to "bless" any of them.
None of the solutions will be put into Mongrel directly since I don't
think that's really needed.  The whole point of Mongrel is people can
modify it very easily to do what they need, rather than waiting for me
to be some kind of gate keeper.  That let's people use GPL code all
they want, write commercial solutions, do their own coding style, and
use any enhancers they feel like without having to be "blessed".

Another point I'd like to make is there's some great work coming from
the virtual machine camp.  I'm not going to try using EventMachine
stuff until I see how well or poorly Mongrel does on some of these new
VMs.  I'm hoping that the JRuby and Rubinius folks just fix threads,
IO, and GC once and for all and then everyone can live in a happy
loving land without relying on tons of nasty C++ to fix things.

I'll be posting a few more highlights and thoughts from railsconf2007
soon.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From zedshaw at zedshaw.com  Mon May 21 20:38:55 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Mon, 21 May 2007 20:38:55 -0400
Subject: [Mongrel] swifty fly?
In-Reply-To: <05DB8C26-7363-4EF3-8C75-1F482975936F@faisal.com>
References: <46522293.5050100@geni.com>
	<95D0B9FB-7DA4-4380-A9C1-083A0E4B66BA@faisal.com>
	<71166b3b0705211640s4c70fd25ma83e852ab24932af@mail.gmail.com>
	<05DB8C26-7363-4EF3-8C75-1F482975936F@faisal.com>
Message-ID: <20070521203855.3be248c2.zedshaw@zedshaw.com>

On Mon, 21 May 2007 20:17:27 -0400
Faisal N Jawdat <faisal at faisal.com> wrote:

> On May 21, 2007, at 7:40 PM, Luis Lavena wrote:
> > I don't know if Zed will "bless it", (the evented_mongrel patch).
> 
> If Zed thinks it's probably a reasonable thing to use even if he  
> doesn't want to incorporate it, it's probably a reasonable thing to  
> use.  If Zed looks at it, gags, and points out that the entire system  
> will break as of Mongrel 1.02, it's probably a bad idea to go near.   
> There's a range in between, obviously...

That's not really my attitude or approach.  Mongrel will stay core and
usable in the way it is now.  The thing I like about Mongrel is it's
simple and flexible enough that people can *finally* take charge and
just write what they need for their situation rather than rely on me
(or bitch and whine that I won't implement their great features :-)

My approach is, if it works, and you're comfortable with the code, then
go for it.  The more solutions the better, as long as there's good
information so people can make great decisions.  In fact, I try to just
be upfront about my opinions and research on these solutions as they
adapt so that people can make educated decisions.

But, I also tell people never believe the hype.  Always, always,
always, go test things people tell you and double check what they say.
Then, don't believe your own tests in the same way you don't believe
what people tell you.  Really make an effort to validate claims every
time you are doing something new.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From ezmobius at gmail.com  Tue May 22 00:58:13 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Mon, 21 May 2007 21:58:13 -0700
Subject: [Mongrel] swifty fly?
In-Reply-To: <20070521203855.3be248c2.zedshaw@zedshaw.com>
References: <46522293.5050100@geni.com>
	<95D0B9FB-7DA4-4380-A9C1-083A0E4B66BA@faisal.com>
	<71166b3b0705211640s4c70fd25ma83e852ab24932af@mail.gmail.com>
	<05DB8C26-7363-4EF3-8C75-1F482975936F@faisal.com>
	<20070521203855.3be248c2.zedshaw@zedshaw.com>
Message-ID: <43649C67-C0FA-4162-A889-2E8F15D1D70E@brainspl.at>


On May 21, 2007, at 5:38 PM, Zed A. Shaw wrote:

> On Mon, 21 May 2007 20:17:27 -0400
> Faisal N Jawdat <faisal at faisal.com> wrote:
>
>> On May 21, 2007, at 7:40 PM, Luis Lavena wrote:
>>> I don't know if Zed will "bless it", (the evented_mongrel patch).
>>
>> If Zed thinks it's probably a reasonable thing to use even if he
>> doesn't want to incorporate it, it's probably a reasonable thing to
>> use.  If Zed looks at it, gags, and points out that the entire system
>> will break as of Mongrel 1.02, it's probably a bad idea to go near.
>> There's a range in between, obviously...
>
> That's not really my attitude or approach.  Mongrel will stay core and
> usable in the way it is now.  The thing I like about Mongrel is it's
> simple and flexible enough that people can *finally* take charge and
> just write what they need for their situation rather than rely on me
> (or bitch and whine that I won't implement their great features :-)
>
> My approach is, if it works, and you're comfortable with the code,  
> then
> go for it.  The more solutions the better, as long as there's good
> information so people can make great decisions.  In fact, I try to  
> just
> be upfront about my opinions and research on these solutions as they
> adapt so that people can make educated decisions.
>
> But, I also tell people never believe the hype.  Always, always,
> always, go test things people tell you and double check what they say.
> Then, don't believe your own tests in the same way you don't believe
> what people tell you.  Really make an effort to validate claims every
> time you are doing something new.
>
> -- 
> Zed A. Shaw


	I agree that this all does not belong in Mongrel core. Mongrel core  
is already tight as hell. That's what makes it possible to add  
features you want by building on top of mongrel. Merb gets really  
good perf because it's tightly integrated with mongrel. The event  
driven stuff does bench really well but like Zed said, don't just  
blindly go using shit you read of teh intarwebs ;) Test it for  
yourself and decide.


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



From wyhaines at gmail.com  Tue May 22 13:25:32 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 22 May 2007 10:25:32 -0700
Subject: [Mongrel] swifty fly?
In-Reply-To: <20070521202944.623e2466.zedshaw@zedshaw.com>
References: <46522293.5050100@geni.com>
	<20070521202944.623e2466.zedshaw@zedshaw.com>
Message-ID: <f4cd26df0705221025gae65ee2qfbc610e906e413d7@mail.gmail.com>

On 5/21/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:

> There's was quite a few announced "mongrel needs some help" kind of
> proxies:
>
> * Swiftiply by Kirk Haines (as he mentioned)
>  http://swiftiply.swiftcore.org/index.html

Really, when I started writing this code, it had nothing at all to do
with Mongrel needing anything.  It was simply about building a fast
clustering proxy that would work well with IOWA's implicit session
capability and would be available before Swiftcore IOWA 1.0 is
released.

I only came back and added the swiftiplied_mongrel because Mongrel is
a target for all of the current existing Ruby frameworks, so it was a
path of least resistance for making Swiftiply available to those
frameworks, too, and I actually included evented_mongrel kind of as an
afterthought.  I had to implement it, anyway, to get to
swiftiplied_mongrel, and there had been talk elsewhere about what a
Mongrel that ran in an event loop might look like and work like.
Turns out it was pretty simple, and it works pretty well.

> A big thing about all three solutions is they are auto-configurable in
> that you fire up mongrel nodes and they tell the proxy about their
> existence.  In a shared hosting environment this is a total disaster
> for security (since anyone would just join your proxy without proper
> encryption and security involved).  BUT, for people doing deployed apps
> like most of the above authors, this is a really useful feature.

Analogger (async logging service) handles this by requiring a client
to authenticate itself immediately after connecting.  If there's any
demand for it, that's an easy thing to add to Swiftiply, too.

> to be some kind of gate keeper.  That let's people use GPL code all
> they want, write commercial solutions, do their own coding style, and
> use any enhancers they feel like without having to be "blessed".

EM's license is actually the same as Ruby's license.

> Another point I'd like to make is there's some great work coming from
> the virtual machine camp.  I'm not going to try using EventMachine
> stuff until I see how well or poorly Mongrel does on some of these new
> VMs.  I'm hoping that the JRuby and Rubinius folks just fix threads,
> IO, and GC once and for all and then everyone can live in a happy
> loving land without relying on tons of nasty C++ to fix things.

Agreed.  The upcoming crop of vms have potential.  I'm building apps
today, though, and jruby just isn't a viable option right now.  The
RAM usage alone is a crippling factor.

The C++ issue is a red herring.  Factor the comments out of the code,
and it's not particularly large.  Somewhat larger than the C code in
Mongrel, but not out of line for the work that it does, and it is a
mature, stable body of code in use in a variety of places for a lot
more applications than just HTTP traffic, on Solaris, Windows, OSX,
and Linux (at least).

All of that aside, though, the central thing for me with regard to
Mongrel is that since I have chosen to support a patched Mongrel as a
mechanism for using Ruby frameworks with Swiftiply, and I have chosen
to release the evented_mongrel, my intention with those two pieces of
the package is for them to be as transparent as possible to any
Mongrel handlers.  They should just work.  If they don't, I have bugs
to fix.  Swiftiply and Mongrel are not married to each other, though.
Mongrel is just the one of the first of the supported platforms, and
the evented_mongrel is a nice extra component that we get basically
for free out of the deal.

I have setup a mailing list to use for discussion of anything specific
to Swiftiply.  It is swiftiply-users at rubyforge.org and can be reached
here:

http://rubyforge.org/mailman/listinfo/swiftiply-users

Questions that are specific to Swiftiply or Swiftiply's Mongrel
support are better off over there, I think.  I don't want to pollute
Zed's list here with things that aren't really about Mongrel itself.
I hope this clears up some misimpressions that people may have.


Thanks,

Kirk Haines

From zedshaw at zedshaw.com  Tue May 22 13:57:40 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 22 May 2007 13:57:40 -0400
Subject: [Mongrel] swifty fly?
In-Reply-To: <f4cd26df0705221025gae65ee2qfbc610e906e413d7@mail.gmail.com>
References: <46522293.5050100@geni.com>
	<20070521202944.623e2466.zedshaw@zedshaw.com>
	<f4cd26df0705221025gae65ee2qfbc610e906e413d7@mail.gmail.com>
Message-ID: <20070522135740.aabccd7f.zedshaw@zedshaw.com>

On Tue, 22 May 2007 10:25:32 -0700
"Kirk Haines" <wyhaines at gmail.com> wrote:

> On 5/21/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:

> > to be some kind of gate keeper.  That let's people use GPL code all
> > they want, write commercial solutions, do their own coding style, and
> > use any enhancers they feel like without having to be "blessed".
> 
> EM's license is actually the same as Ruby's license.

I wasn't referring to EM but now that you bring it up, if that's true
then why do I get this:

eventmachine-0.7.0> grep -lr "GPL" *

lib/em/deferrable.rb
lib/em/eventable.rb
lib/pr_eventmachine.rb
lib/eventmachine_version.rb
lib/eventmachine.rb
lib/protocols/header_and_content.rb
lib/protocols/tcptest.rb
lib/protocols/httpclient.rb
lib/protocols/line_and_text.rb
README
tests/test_hc.rb
tests/test_ud.rb
tests/test_ltp.rb
tests/test_httpclient.rb
tests/test_basic.rb
tests/test_eventables.rb

As well as the giant COPYING file with the whole GPL license in it.

Until every last one of those statements is gone, it's GPL licensed.
Even worse is the README says LGPL, the license statements on these
files says GPLv2, and then everyone thinks it's Ruby licensed.

You folks should do more homework before you use this stuff.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From wyhaines at gmail.com  Tue May 22 14:22:32 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 22 May 2007 11:22:32 -0700
Subject: [Mongrel] swifty fly?
In-Reply-To: <20070522135740.aabccd7f.zedshaw@zedshaw.com>
References: <46522293.5050100@geni.com>
	<20070521202944.623e2466.zedshaw@zedshaw.com>
	<f4cd26df0705221025gae65ee2qfbc610e906e413d7@mail.gmail.com>
	<20070522135740.aabccd7f.zedshaw@zedshaw.com>
Message-ID: <f4cd26df0705221122p7ab95efdr5134eeb56a72c700@mail.gmail.com>

On 5/22/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:

> As well as the giant COPYING file with the whole GPL license in it.
>
> Until every last one of those statements is gone, it's GPL licensed.
> Even worse is the README says LGPL, the license statements on these
> files says GPLv2, and then everyone thinks it's Ruby licensed.
>
> You folks should do more homework before you use this stuff.

Thanks for the advice.

"It will be a disjunctive Ruby/LGPL license. The various source files which
indicate pure GPL are in error."

I already spoke with Francis Cianfrocca about making sure that an
update is done, ASAP, which clears the issue up.


Kirk Haines

From mrmargolis at wisc.edu  Tue May 22 17:33:46 2007
From: mrmargolis at wisc.edu (Matthew Margolis)
Date: Tue, 22 May 2007 16:33:46 -0500
Subject: [Mongrel] Process safe log files with multiple mongrels
Message-ID: <19434BA2-3813-4D29-A770-7728625DF80A@wisc.edu>

I have a rails application that runs on multiple mongrels and I would  
like to make the log files non-interlacing.  Are there any logging  
modifications/other loggers out there that I could use to create  
process safe logging?

Thank you,
Matt Margolis

From zedshaw at zedshaw.com  Tue May 22 18:47:23 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 22 May 2007 18:47:23 -0400
Subject: [Mongrel] Process safe log files with multiple mongrels
In-Reply-To: <19434BA2-3813-4D29-A770-7728625DF80A@wisc.edu>
References: <19434BA2-3813-4D29-A770-7728625DF80A@wisc.edu>
Message-ID: <20070522184723.32df4b6e.zedshaw@zedshaw.com>

On Tue, 22 May 2007 16:33:46 -0500
Matthew Margolis <mrmargolis at wisc.edu> wrote:

> I have a rails application that runs on multiple mongrels and I would  
> like to make the log files non-interlacing.  Are there any logging  
> modifications/other loggers out there that I could use to create  
> process safe logging?

For your rails logs, you could probably use this:

http://seattlerb.rubyforge.org/SyslogLogger/

Or similar.  For your mongrel logs, just use the options to start that
set the name of the file to the host-port of that mongrel.  Mongrel
cluster should already do this.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From wyhaines at gmail.com  Tue May 22 18:50:13 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 22 May 2007 15:50:13 -0700
Subject: [Mongrel] Process safe log files with multiple mongrels
In-Reply-To: <19434BA2-3813-4D29-A770-7728625DF80A@wisc.edu>
References: <19434BA2-3813-4D29-A770-7728625DF80A@wisc.edu>
Message-ID: <f4cd26df0705221550i5173e736o92ed598dd62dda46@mail.gmail.com>

On 5/22/07, Matthew Margolis <mrmargolis at wisc.edu> wrote:
> I have a rails application that runs on multiple mongrels and I would
> like to make the log files non-interlacing.  Are there any logging
> modifications/other loggers out there that I could use to create
> process safe logging?

You could try my asynchronous logger, Analogger --
http://analogger.swiftcore.org

It will take logging input from N clients (where N is currently a
number up to about 1000) and write it to logging destinations quickly
and efficiently.

Mongrel itself can be told to write log files to different log files,
depending on the hostname and port it is running on, though, if it's
mongrel logs that you are asking about.


Kirk Haines

From miles at pixar.com  Tue May 22 18:55:17 2007
From: miles at pixar.com (Miles Egan)
Date: Tue, 22 May 2007 15:55:17 -0700
Subject: [Mongrel] Process safe log files with multiple mongrels
In-Reply-To: <f4cd26df0705221550i5173e736o92ed598dd62dda46@mail.gmail.com>
References: <19434BA2-3813-4D29-A770-7728625DF80A@wisc.edu>
	<f4cd26df0705221550i5173e736o92ed598dd62dda46@mail.gmail.com>
Message-ID: <8E2270AF-C132-4E0C-BE24-211E3E6379D9@pixar.com>

On May 22, 2007, at 3:50 PM, Kirk Haines wrote:
> You could try my asynchronous logger, Analogger --
> http://analogger.swiftcore.org

I can just see myself explaining that name to my boss now...

--
miles


From wyhaines at gmail.com  Tue May 22 19:00:07 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 22 May 2007 16:00:07 -0700
Subject: [Mongrel] Process safe log files with multiple mongrels
In-Reply-To: <8E2270AF-C132-4E0C-BE24-211E3E6379D9@pixar.com>
References: <19434BA2-3813-4D29-A770-7728625DF80A@wisc.edu>
	<f4cd26df0705221550i5173e736o92ed598dd62dda46@mail.gmail.com>
	<8E2270AF-C132-4E0C-BE24-211E3E6379D9@pixar.com>
Message-ID: <f4cd26df0705221600l6e9181fbm31f39c7eb9ba234b@mail.gmail.com>

On 5/22/07, Miles Egan <miles at pixar.com> wrote:
> On May 22, 2007, at 3:50 PM, Kirk Haines wrote:
> > You could try my asynchronous logger, Analogger --
> > http://analogger.swiftcore.org
>
> I can just see myself explaining that name to my boss now...

Pour "analog" into a tumbler with "asyncronous logger" and shake.
Pour into a frosted mug and enjoy.


Kirk Haines

From jeff at zilkey.com  Tue May 22 21:25:24 2007
From: jeff at zilkey.com (Jeff Dean)
Date: Tue, 22 May 2007 21:25:24 -0400
Subject: [Mongrel] mongrel_cluster + mongrel_upload_progress + drb +
	capistrano + docs
Message-ID: <6586e070705221825v54aec870y69148658ef8d143c@mail.gmail.com>

I just got the mongrel_upload_progress set up with drb and the setup was
quick and easy, thanks to the good documentation on
http://mongrel.rubyforge.org/docs/upload_progress.html

I'd like to get this set up with capistrano, but there are 3 things I can't
figure out:

   - First, I can't get lib/upload.rb to run in the background - I'm not
   familiar with setting services or daemons up on *nix, so this could be very
   easy and I just don't know how to do it
   - Second, once I've started it as a daemon or service, how would I
   stop it?
   - Last, I don't know how to add the -S flag to the mongrel_cluster
   command at startup

Once I get those two things figured out, I'll be able to get the whole thing
on capistrano.

Anyone know how to get upload.rb running in the background and the cluster
to call the -S flag?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070522/a427a956/attachment.html 

From craig at itpartners.co.nz  Tue May 22 22:51:10 2007
From: craig at itpartners.co.nz (Craig Box)
Date: Wed, 23 May 2007 14:51:10 +1200
Subject: [Mongrel] mongrel_cluster + mongrel_upload_progress + drb
	+capistrano + docs
In-Reply-To: <6586e070705221825v54aec870y69148658ef8d143c@mail.gmail.com>
References: <6586e070705221825v54aec870y69148658ef8d143c@mail.gmail.com>
Message-ID: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DF024@penfold.itpartners.co.nz>

> First, I can't get lib/upload.rb to run in the background...

The version at
http://itblog.mcgeecorp.com/2007/5/15/mongrel-upload-progress-demo uses
the 'daemons' rubygem to do this for you...

> Second, once I've started it as a daemon or service, how would I stop
it?

... as per
http://www.mcgeecorp.com/downloads/upload-progress-demo.README.txt, all
you need to do is

ruby lib/upload_progress_server.rb start
ruby lib/upload_progress_server.rb stop

> Last, I don't know how to add the -S flag to the 
> mongrel_cluster command at startup

In your mongrel_cluster.yml file, add this line:
config_script: config/mongrel_upload_progress.conf

Craig

(P.S. I hope upload progress updates for you.. doesn't for me *sniff*)

From lists at kikobu.com  Wed May 23 03:45:56 2007
From: lists at kikobu.com (Morten)
Date: Wed, 23 May 2007 09:45:56 +0200
Subject: [Mongrel] Troubleshooting unresponsive mongrel
Message-ID: <f30rfn$edv$1@sea.gmane.org>


Hi. I have mongrel 1.0.1 running a really simple application and found 
to lock up (rarely, but still). There's nothing in the logs, it just 
stops responding. When I mongrel_rails stop it, I get lots of entries like:

Waiting for 3 requests to finish, could take 60 seconds
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:675:in `process'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:618:in 
`process_client'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in 
`process_client'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `run'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in 
`run'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in 
`run'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in `run'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in 
`run'
/usr/lib64/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
/usr/bin/mongrel_rails:18Wed May 23 08:58:18 CEST 2007: Error calling 
Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed out this 
thread: shutdown>Thread #<Thread:0x2a9859a570 sleep> is too old, killing.

Any tips on how to determine the cause of this? I'm running CentOS 4, 
Ruby 1.8.4.

Br,

Morten




From alexey.verkhovsky at gmail.com  Wed May 23 11:21:36 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 23 May 2007 09:21:36 -0600
Subject: [Mongrel] Troubleshooting unresponsive mongrel
In-Reply-To: <f30rfn$edv$1@sea.gmane.org>
References: <f30rfn$edv$1@sea.gmane.org>
Message-ID: <3945c4270705230821g18c7a41ao52d0be518f11a763@mail.gmail.com>

On 5/23/07, Morten <lists at kikobu.com> wrote:
> Hi. I have mongrel 1.0.1 running a really simple application and found
> to lock up (rarely, but still).

Does it lock up after a period of inactivity? Are you using MySQL pure
Ruby driver there? If the answer is yes and yes, it's a known MySQL
driver bug. Quoting from Mongrel FAQ:

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.

--
Alex Verkhovsky

From christian.rivasseau at gmail.com  Thu May 24 06:58:01 2007
From: christian.rivasseau at gmail.com (Christian)
Date: Thu, 24 May 2007 12:58:01 +0200
Subject: [Mongrel] Mongrel problem
Message-ID: <937c67530705240358m28f35e43r52361db70cb8276c@mail.gmail.com>

Hello mongrel list
Does somebody know the answer to this problem when using mongrel_rails:


/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require__': no
such file to load -- http11 (LoadError)
        from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in
`require'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:11
        from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require__'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:9
        from /usr/bin/mongrel_rails:18:in `load'
        from /usr/bin/mongrel_rails:18



I am getting mad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070524/9bd4544e/attachment.html 

From kraemer at webit.de  Thu May 24 07:29:41 2007
From: kraemer at webit.de (Jens Kraemer)
Date: Thu, 24 May 2007 13:29:41 +0200
Subject: [Mongrel] Mongrel problem
In-Reply-To: <937c67530705240358m28f35e43r52361db70cb8276c@mail.gmail.com>
References: <937c67530705240358m28f35e43r52361db70cb8276c@mail.gmail.com>
Message-ID: <20070524112941.GD8909@cordoba.webit.de>

On Thu, May 24, 2007 at 12:58:01PM +0200, Christian wrote:
> Hello mongrel list
> Does somebody know the answer to this problem when using mongrel_rails:
> 
> 
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require__': no
> such file to load -- http11 (LoadError)

http11.so is mongrel's native library which should have been built when
you installed the gem.

if you're on Debian/Ubuntu make sure you have the ruby1.8-dev and
build-essential packages installed before installing the gem.

Jens

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

From rancor at mindspring.com  Thu May 24 07:47:25 2007
From: rancor at mindspring.com (Jim Powers)
Date: Thu, 24 May 2007 07:47:25 -0400
Subject: [Mongrel] Mongrel problem
In-Reply-To: <937c67530705240358m28f35e43r52361db70cb8276c@mail.gmail.com>
References: <937c67530705240358m28f35e43r52361db70cb8276c@mail.gmail.com>
Message-ID: <20070524074725.12f38d0b@nomadII.powershouse.bogus>

On Thu, 24 May 2007 12:58:01 +0200 Christian
<christian.rivasseau at gmail.com> wrote:
> Hello mongrel list
> Does somebody know the answer to this problem when using
> mongrel_rails:

The key line in the error is here:

> from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:9

But, looking in the file I see:

 7: require 'rubygems'
 8: require 'yaml'
 9: require 'mongrel'
10: require 'mongrel/rails'
11: require 'etc'
12: require 'cgi_multipart_eof_fix' rescue nil

Guesses:

 - your install of gems is broken
 - your install of mongrel is broken

I would try a re-install of one or both of these.

I've had other problem in the past getting mongrel setup, but nothing
like this, sorry.

Jim Powers

From purestorm at ggnore.net  Thu May 24 16:00:41 2007
From: purestorm at ggnore.net (Manuel Holtgrewe)
Date: Thu, 24 May 2007 22:00:41 +0200
Subject: [Mongrel] Logging Exceptions
Message-ID: <20DE1113-9392-483B-B7AE-B92D1A3A3D18@ggnore.net>

Hi,

I am using Mongrel with my own XmlRpcHandler and I get sporadic "500"  
errors from Mongrel. The handler wraps around the xmlrpc/server  
module and I am pretty sure that the error is mine and neither in  
mongrel or xmlrpc/server.

I catch all exceptions in my xmlrpc/server handler and do not send  
out 500 http answers from there. Thus, I expect the problem is in my  
handler.

Now to my question: Is it possible to hook into the place where  
Mongrel itself catches the exceptions so I can log an exception trace  
when this happens?

Any help is appreciated.

Thanks in advance,

Manuel Holtgrewe

From eden at mojiti.com  Thu May 24 23:05:30 2007
From: eden at mojiti.com (Eden Li)
Date: Fri, 25 May 2007 11:05:30 +0800
Subject: [Mongrel] Logging Exceptions
In-Reply-To: <20DE1113-9392-483B-B7AE-B92D1A3A3D18@ggnore.net>
References: <20DE1113-9392-483B-B7AE-B92D1A3A3D18@ggnore.net>
Message-ID: <1dd361e10705242005p3b06c84bgce78f3122bf0ee41@mail.gmail.com>

Mongrel logs exceptions it catches to stderr, have you looked at the
output there?  It just logs the exception message but not the full
backtrace.  You can have it include the backtrace if you send the
mongrel process the USR1 signal (`killall -USR1 mongrel_rails` or
something similar).

On 5/25/07, Manuel Holtgrewe <purestorm at ggnore.net> wrote:
> I catch all exceptions in my xmlrpc/server handler and do not send
> out 500 http answers from there. Thus, I expect the problem is in my
> handler.
>
> Now to my question: Is it possible to hook into the place where
> Mongrel itself catches the exceptions so I can log an exception trace
> when this happens?

From evan at cloudbur.st  Fri May 25 14:26:27 2007
From: evan at cloudbur.st (Evan Weaver)
Date: Fri, 25 May 2007 14:26:27 -0400
Subject: [Mongrel] deadlock issue: 1.8.6/fastthread/memcached-client/mongrel
Message-ID: <b6f68fc60705251126x50470711vfa875723d7ecb230@mail.gmail.com>

Hi all,

I'm getting a strange, intermittent Thread deadlock in production:

deadlock 0x2a988d7008: sleep:F(3) -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:723

CPU usage spikes to a full core and Apache 502's on requests that got
handed to that particular listener each time. I tried attaching with
gdb, and gdb twisted itself into a knot.

Anyone have any clues? The memcached-client reference seems suspicious.

Full backtrace, gdb log, and system information is here:
http://pastie.caboo.se/64610 , and also attached below.

Thanks

Evan

-- 
Evan Weaver
Cloudburst, LLC

****************************

## mongrel error log

** Starting Mongrel listening at 0.0.0.0:8225
** Changing group to app.
** Changing user to app.
** Starting Rails with production environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It
might not work well.
** Mongrel available at 0.0.0.0:8225
** Writing PID file to /opt/rails/chow/production/current/log/mongrel.8225.pid
deadlock 0x2a988d7008: sleep:F(3)  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:723
deadlock 0x2a9a18d700: sleep:-  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76
deadlock 0x2a9a349ad0: sleep:-  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76
deadlock 0x2a9ac10f60: sleep:-  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76
deadlock 0x2a9a87c4a8: sleep:-  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76
deadlock 0x2a9a705a70: sleep:-  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76
deadlock 0x2a9aebf9f0: sleep:-  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76
deadlock 0x2a9a600210: sleep:-  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76
deadlock 0x2a9a4fc0a8: sleep:-  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76
deadlock 0x2a9ad415b0: sleep:-  -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76
deadlock 0x2a9aec5d28: sleep:S  -
/opt/rails/chow/production/releases/20070516172704/vendor/gems/memcache-client-1.3.0/lib/memcache.rb:473
deadlock 0x2a9a7c71c0: sleep:S  - (eval):3
deadlock 0x2a955bde10: sleep:J(0x2a988d7008) (main) -
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:293
/opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:274:in
`join': Thread(0x2a988d6f40): deadlock (fatal)
        from /opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:293:in
`each'
        from /opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:293:in
`join'
        from /opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:136:in
`run'
        from /opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in
`run'
        from /opt/ruby/default/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
        from /opt/ruby/default/bin/mongrel_rails:16:in `load'
        from /opt/ruby/default/bin/mongrel_rails:16

[process exited]

## gdb attach attempt

Loaded symbols for /opt/ruby/default/lib/ruby/1.8/x86_64-linux/digest/sha1.so
0x00000000004130bc in match_fds (dst=0x7fbfff7520, src=0xf45bdc0, max=1025)
    at eval.c:10527
10527   eval.c: No such file or directory.
        in eval.c
(gdb) source ruby-gdb
(gdb) redirect_stdout
$1 = 2
(gdb) eval "caller"

Program received signal SIGPIPE, Broken pipe.
0x0000003add5b7ee2 in __write_nocancel () from /lib64/tls/libc.so.6
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (rb_p) will be abandoned.
(gdb) eval "caller()"

[weavere at c13-chd-app1 tools]$
Program received signal SIGINT, Interrupt.
0x00000000004132d9 in rb_thread_schedule () at eval.c:10618
10618   in eval.c
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function
(rb_eval_string_protect) will be abandoned.
(gdb) [A

[gdb hung at this point, force-killed, and mongrel died]

## system environment:

[weavere at c13-chd-app1 ~]$ ruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [x86_64-linux]

[weavere at c13-chd-app1 ~]$ gem list | grep '^\w'
cgi_multipart_eof_fix (2.1)
daemons (1.0.5)
fastthread (1.0)
gem_plugin (0.2.2)
hpricot (0.5)
mongrel (1.0.1)
mongrel_cluster (1.0.1.1)
mysql (2.7)
rake (0.7.3)
sources (0.0.1)
unicode (0.1)

[weavere at c13-chd-app1 chow]$ ls -1 vendor/gems/
crypt-1.1.4
image_science-1.1.1
memcache-client-1.3.0
RedCloth-3.0.4
RubyInline-3.6.3
session-2.4.0
sphinx-0.9.7-rc2
test-spec-0.3.0

[weavere at c13-chd-app1 ~]$ uname -r
2.6.9-5.0.3.ELsmp

System is RHEL 4, quad-core Opteron. Error occurs in production mode
very intermittently.

From craig at itpartners.co.nz  Sun May 27 20:04:12 2007
From: craig at itpartners.co.nz (Craig Box)
Date: Mon, 28 May 2007 12:04:12 +1200
Subject: [Mongrel] No return status from mongrel upload progress (and
	thus no updates on the bar)
In-Reply-To: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C360699@penfold.itpartners.co.nz>
References: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>
	<b46641a0705180705q1d5d3217r1dc092d4e4fc43ea@mail.gmail.com>
	<87ECFF3F9E2DBD4FBD1F74F9A80BBD1C360695@penfold.itpartners.co.nz>
	<87ECFF3F9E2DBD4FBD1F74F9A80BBD1C360699@penfold.itpartners.co.nz>
Message-ID: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DF14A@penfold.itpartners.co.nz>

Hi again,

I've summarised methods to get upload progress in a Rails application:
http://craig.dubculture.co.nz/blog/2007/05/27/ways-to-get-an-upload-prog
ress-bar-in-a-ruby-on-rails-application/

My original problem went away - I'm not 100% sure how or why, but it
seems that it may have been cleared up by a combination of not running
the app or DRb server as root (which seems odd), or running 'gem
cleanup'.

However, I'm now stuck with the problem that I'm using Apache 2.2 as my
load balancer, and I assume it buffers the upload before passing it to
Mongrel: I don't get anything in the Uploads.list, so again, no
progress.  Works fine if I connect directly to the Mongrel it's
proxying.

My options here seem to be "find a way to break Apache's upload
performance", or "run a Mongrel instance on a different port, and
instruct the app to connect to this to do its uploads".  The second
method seems widely advocated here, but I've not seen any suggestions on
how to actually do this.  Is it as "simple" as hard-coding the location
(urgh!) in the view?   If I run a cluster of Mongrels for the listener
and one for the uploads, will that be suitable?  Or does anyone know the
incantation for Apache to allow me to do what I want?  The site isn't
high traffic, so I doubt it will be a huge performance hit.

Thanks in advance,
Craig

From jonahfox at gmail.com  Mon May 28 10:19:54 2007
From: jonahfox at gmail.com (Jonah Fox)
Date: Mon, 28 May 2007 15:19:54 +0100
Subject: [Mongrel] vista on mongrel
Message-ID: <fb9f28500705280719o39d934ban3d4c66fd33185b0@mail.gmail.com>

Hi,

I have installed mongrel on Vista and my app runs *really* slowly. Checking
Net stats in firebug shows each html request for the assets taking ~1s.
Running same app on XP is fine and running as webrick on vista is fine too.

There is also a strange pattern : each of the http requests to mongrel take
marginally more than 1s, e.g. 1.04, 1.05
on webrick each request takes ~ 4-40ms.

Very odd behaviour - any ideas ?

weepy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070528/9f6a414b/attachment.html 

From luislavena at gmail.com  Mon May 28 12:33:56 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 28 May 2007 13:33:56 -0300
Subject: [Mongrel] vista on mongrel
In-Reply-To: <fb9f28500705280719o39d934ban3d4c66fd33185b0@mail.gmail.com>
References: <fb9f28500705280719o39d934ban3d4c66fd33185b0@mail.gmail.com>
Message-ID: <71166b3b0705280933k5c55397eqc4bf4910c6ae3ee@mail.gmail.com>

On 5/28/07, Jonah Fox <jonahfox at gmail.com> wrote:
> Hi,
>
> I have installed mongrel on Vista and my app runs *really* slowly. Checking
> Net stats in firebug shows each html request for the assets taking ~1s.
> Running same app on XP is fine and running as webrick on vista is fine too.
>
> There is also a strange pattern : each of the http requests to mongrel take
> marginally more than 1s, e.g. 1.04, 1.05
> on webrick each request takes ~ 4-40ms.
>
> Very odd behaviour - any ideas ?
>

Are you working with edge rails? Since new edge version default to
cookie for sessio storage, mongrel behave a bit "slower" in that area,
taking like 4 seconds (Core 2 Duo) just to refresh its first page, and
without high CPU load.

I reverted that to pstore for development, and active_record for
production until figure out what is wrong with cookie based storage,
and of course, windows.

-- 
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 jonahfox at gmail.com  Mon May 28 13:47:09 2007
From: jonahfox at gmail.com (Jonah Fox)
Date: Mon, 28 May 2007 18:47:09 +0100
Subject: [Mongrel] vista on mongrel
In-Reply-To: <71166b3b0705280933k5c55397eqc4bf4910c6ae3ee@mail.gmail.com>
References: <fb9f28500705280719o39d934ban3d4c66fd33185b0@mail.gmail.com>
	<71166b3b0705280933k5c55397eqc4bf4910c6ae3ee@mail.gmail.com>
Message-ID: <fb9f28500705281047l6114781fxb3b3a5343b2c16bc@mail.gmail.com>

no it's 1.2.3

and using file store for sessions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070528/ea06c6b5/attachment.html 

From jgubman at looksmart.net  Tue May 29 15:01:56 2007
From: jgubman at looksmart.net (Jon Gubman)
Date: Tue, 29 May 2007 12:01:56 -0700
Subject: [Mongrel] Headers munged into RAW_POST_DATA
Message-ID: <77E8F350-BAC2-43CF-8327-3549DBAF0620@looksmart.net>

Hi,
we're seeing a really weird problem in our production environment.  
"Connection: Keep-Alive\r\n" is being pre-pended to the  
RAW_POST_DATA, which makes requests error out. This bug is seen  
infrequently and *seems* to be browser-related, although I can't  
reproduce it using the browser reported in HTTP_USER_AGENT.

Set up is a hardware load balancer (NetScaler) -> mongrel_cluster  
0.2.1/mongrel 1.0

Has anyone else seen this or have any advice? I'm thinking I'll  
cobble together a kludge that inspects @head['RAW_POST_DATA'] and  
just sub out "Connection: Keep-Alive\r\n", but I'd really like to  
avoid doing that.


Here are two recent examples of the bug. Output is  
@request.env.keys.sort.each { |key| puts key: @request.env 
[key].to_s.strip }:

Parameters: {"ad"=>"5", "action"=>"new", "ct"=>nil,  
"controller"=>"ad_keywords", "Connection: Keep-Alive\r\nad_keyword"=> 
{"smart_keywords"=>"Non Emergency Transport \r\nNon Emergency  
Transportation\r\nTransportation for Disabled\r\nTransport for  
Disabled\r\nHandicap Transportation\r\nHandicap Transport\r 
\nDisability Transportation\r\nDisability Transport\r\nMedical  
Transportation Service\r\nMedical Transport Service\r\nMedical  
Transportation \r\nMedical Transport \r\nMedical Transportation Vans\r 
\nMedical Transport Vans\r\nMedical Patient Transportation \r 
\nMedical Patient Transport"}, "cid"=>"7"}
   * Rails root: /prod/amp/current


   * CONTENT_LENGTH          : 582
   * CONTENT_TYPE            : application/x-www-form-urlencoded
   * GATEWAY_INTERFACE       : CGI/1.2
   * HTTP_ACCEPT             : text/xml,application/xml,application/ 
xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   * HTTP_ACCEPT_CHARSET     : ISO-8859-1,utf-8;q=0.7,*;q=0.7
   * HTTP_ACCEPT_ENCODING    : gzip,deflate
   * HTTP_ACCEPT_LANGUAGE    : en-us,en;q=0.5
   * HTTP_CONTENT_LENGTH     : 582
   * HTTP_CONTENT_TYPE       : application/x-www-form-urlencoded
   * HTTP_COOKIE             : accepting=1;
   * HTTP_HOST               : foo.com
   * HTTP_MAX_FORWARDS       : 10
   * HTTP_REFERER            : https://foo.com/ad_keywords/new? 
ad=5&cid=7
   * HTTP_USER_AGENT         : Mozilla/5.0 (Windows; U; Windows NT  
5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
   * HTTP_VERSION            : HTTP/1.0
   * HTTP_X_BROWSER_TIMESTAMP: 386789
   * HTTP_X_FORWARDED_FOR    : xx.xxx.xxx.xxx
   * HTTP_X_FORWARDED_HOST   : foo.com
   * HTTP_X_FORWARDED_PROTO  : https
   * HTTP_X_FORWARDED_SERVER : foo.com
   * HTTP_X_NAVID            : f5c-50cfb
   * PATH_INFO               : /ad_keywords/new
   * QUERY_STRING            : cid=7&ad=5&ct=
   * RAW_POST_DATA           : Connection: Keep-Alive
   ad_keyword%5Bsmart_keywords%5D=Non+Emergency+Transport+%0D%0ANon 
+Emergency+Transportation%0D%0ATransportation+for+Disabled%0D% 
0ATransport+for+Disabled%0D%0AHandicap+Transportation%0D%0AHandicap 
+Transport%0D%0ADisability+Transportation%0D%0ADisability+Transport%0D 
%0AMedical+Transportation+Service%0D%0AMedical+Transport+Service%0D% 
0AMedical+Transportation+%0D%0AMedical+Transport+%0D%0AMedical 
+Transportation+Vans%0D%0AMedical+Transport+Vans%0D%0AMedical+Patient 
+Transportation+%0D%0AMedical+Patient+Transport%0D%0A&ad_keyword% 
5Bbroad_keywords%5D=
   * REMOTE_ADDR             : xx.xxx.xxx.xxx
   * REQUEST_METHOD          : POST
   * REQUEST_PATH            : /ad_keywords/new
   * REQUEST_URI             : /ad_keywords/new?cid=7&ad=5&ct=
   * SCRIPT_NAME             : /
   * SERVER_NAME             : foo.com
   * SERVER_PORT             : 80
   * SERVER_PROTOCOL         : HTTP/1.1
   * SERVER_SOFTWARE         : Mongrel 1.0





Parameters: {"Connection: Keep-Alive\r\ncoupon_code"=>"",  
"action"=>"deposit_funds", "controller"=>"accounts",  
"deposit_amount"=>""}

   * CONTENT_LENGTH         : 52
   * CONTENT_TYPE           : application/x-www-form-urlencoded
   * GATEWAY_INTERFACE      : CGI/1.2
   * HTTP_ACCEPT            : image/gif, image/x-xbitmap, image/jpeg,  
image/pjpeg, application/x-ms-application, application/vnd.ms- 
xpsdocument, application/xaml+xml, application/x-ms-xbap, application/ 
msword, application/vnd.ms-excel, application/vnd.ms-powerpoint,  
application/x-shockwave-flash, */*
   * HTTP_ACCEPT_ENCODING   : gzip, deflate
   * HTTP_ACCEPT_LANGUAGE   : en-us
   * HTTP_CACHE_CONTROL     : no-cache
   * HTTP_CONTENT_LENGTH    : 52
   * HTTP_CONTENT_TYPE      : application/x-www-form-urlencoded
   * HTTP_COOKIE            : accepting=1;
   * HTTP_HOST              : foo.com
   * HTTP_MAX_FORWARDS      : 10
   * HTTP_REFERER           : https://foo.com/accounts/deposit_funds? 
aid=6
   * HTTP_UA_CPU            : x86
   * HTTP_USER_AGENT        : Mozilla/4.0 (compatible; MSIE 7.0;  
Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET  
CLR 3.0.04506; .NET CLR 1.1.4322)
   * HTTP_VERSION           : HTTP/1.0
   * HTTP_X_FORWARDED_FOR   : xxx.xxx.xxx.xxx
   * HTTP_X_FORWARDED_HOST  : foo.com
   * HTTP_X_FORWARDED_PROTO : https
   * HTTP_X_FORWARDED_SERVER: foo.com
   * PATH_INFO              : /accounts/deposit_funds
   * RAW_POST_DATA          : Connection: Keep-Alive
   coupon_code=&deposit_amount=
   * REMOTE_ADDR            : xxx.xxx.xxx.xxx
   * REQUEST_METHOD         : POST
   * REQUEST_PATH           : /accounts/deposit_funds
   * REQUEST_URI            : /accounts/deposit_funds
   * SCRIPT_NAME            : /
   * SERVER_NAME            : foo.com
   * SERVER_PORT            : 80
   * SERVER_PROTOCOL        : HTTP/1.1
   * SERVER_SOFTWARE        : Mongrel 1.0

From jeremy at bitsweat.net  Tue May 29 19:48:19 2007
From: jeremy at bitsweat.net (Jeremy Kemper)
Date: Tue, 29 May 2007 16:48:19 -0700
Subject: [Mongrel] Headers munged into RAW_POST_DATA
In-Reply-To: <77E8F350-BAC2-43CF-8327-3549DBAF0620@looksmart.net>
References: <77E8F350-BAC2-43CF-8327-3549DBAF0620@looksmart.net>
Message-ID: <69a2885c0705291648j5f5d2b1fse5ccd58c070ef73e@mail.gmail.com>

On 5/29/07, Jon Gubman <jgubman at looksmart.net> wrote:
> we're seeing a really weird problem in our production environment.
> "Connection: Keep-Alive\r\n" is being pre-pended to the
> RAW_POST_DATA, which makes requests error out. This bug is seen
> infrequently and *seems* to be browser-related, although I can't
> reproduce it using the browser reported in HTTP_USER_AGENT.

Hi Jon, could you bring this up on the rubyonrails-core list? It's
related to a recent change in svn trunk, not Mongrel.

Thanks,
jeremy