similar to: Debugging high CPU with Mongrel

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

We tried to give Mongrel a go running our application which has moderate traffic. We got mongrel up and running easy enough but 3 times in a short period(2hours) mongrel just died with the following error when we went live to production with it. As you can see we are running mongrel-0.3.13.3. /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:576:in`peeraddr'': Transport endpoint

Hello Everyone, We''re hard at work getting the hot new win32 service Luis wrote out and ready for production. We''re hoping to have that included in the 1.0 RC1 release we make very soon. This pre-release is just to make sure that we didn''t step on any toes. Install it with: $ gem install fastthread --source=http://mongrel.rubyforge.org/releases $ gem install

Hi list, I''m seeing a couple of issues with Mongrel. I''m running FreeBSD 6.1 and have previously been told that there are known conflicts between this and Mongrel, yet I hope these issues will be resolved with time. I''m overloading Mongrel with httperf on my local workstation. Mongrel is started directly with the mongrel_rails command and there is only one mongrel

So I have updated to the latest mongrel and fastthread and my environment is as follows: Debian 3.1 Rails 1.1.6 Ruby 1.8.5 Mongrel 0.3.18 Fastthread 0.4 Mongrel Cluster 0.2.1 Apache 2.2.3 I again woke up this morning to my disappointment of seeing the strange Status: 500 Internal Server error. It happens the same every morning, I have three mongrels running, two give the error, one

Hello all, For the past couple of weeks I have been spending some time debugging a couple of issues I was having with Mongrel when I put load on it. I have seen two distinct issues: 1. Mongrel stopped responding as if in an endless loop. 2. Mongrel crashed when severely loaded. I believe to have resolved these two issues and have attached patches which shows the resolution (simple as it is).

Alright folks, I put in a fix for camping and added the patch by Thomas Hurst for the accf_http deferred accept settings for FreeBSD. As usual, please test this release out and let me know if it has any additional problems. I''ll be working on win32 builds today and tomorrow with Luis. Install with: sudo gem install fastthread --source=http://mongrel.rubyforge.org/releases sudo gem

Hey guys, I''m running the mongrel server that comes with rails-1.2rc1 for development on a winxp box, anticipating taking it into production on a win2k3 box in the next few weeks. I''ve had a couple of crashes occur during development that give me pause, however. I made a ticket for the last one here: http://dev.rubyonrails.org/ticket/6841 I know, or at least believe, that

I''m setting up a Rails app for a client that uses Windows. I''m getting this error: c:/ruby/lib/ruby/gems/1.8/gems/mongrel-0.3.18/lib/mongrel/rails.rb: 32: uninitial ized constant Mongrel::HttpHandler (NameError) from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/ custom_require.rb:21:in `re quire'' from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-0.3.18/bin/

With Mongrel 0.3.18, I have not seen a single one of the hangs that I have been grousing about for the past N weeks. Thanks MenTaLguY and Zed! Q: Mongrel loads fastthread, Mongrel loads Rails, Rails loads OCI8, OCI8 requires ''thread''. That means OCI8 is using fastthread too, right? Steve

== NOW A new version of fastthread, the library providing better implementations of the classes in thread.rb, has been released. Please note that fastthread is only for Ruby 1.8, not JRuby or any other Ruby implementation (most of them don''t need it anyway!). == WHY The existing implementation of Mutex, Queue, etc. in thread.rb is slow. fastthread''s is faster (and bypasses

Hello Minions! It''s *finally* here. Mongrel 1.0 RC1 for everyone to test, even the win32 folks. I managed to get everything to build on windows, including fastthread, and even cleaned up the "releases source":http://mongrel.rubyforge.org/releases/ so that it should install cleaner. Win32 will have to try and report problems, as it seems rubygems is real finicky on win32.

I have a Rails 1.2.3 app (due for an update, I know) running on a Mongrel 1.1.4 behind Apache 2.2.3 mod_proxy on Debian 4.0. It keeps hanging up for no reason I can tell. I have tried everything that anyone has ever hinted at being a solution for this problem: - The application doesn''t use MySQL, so setting the connection timeout won''t help. - Using AR not PStore for sessions. -

I''m going to make a change to how Mongrel is versioned to help out folks packaging it and tracking it as a pre-release. Previously I just did whatever was simplest, but now I''m going to do a slightly different approach. This is open for comment and suggestions. Here''s the new rules: 1) There are only official and pre-releases. This doesn''t change. 2) The

Is anybody testing mongrel on ruby 1.9. I just tried installing mongrel on trunk 1.9 and trunk rubygems and got this error compiling fastthread: /Users/stephen/dev/ruby/1.9_trunk/bin/ruby extconf.rb install mongrel --no-rdoc creating Makefile make gcc -I. -I/Users/stephen/dev/ruby/1.9_trunk/include/ruby-1.9/i686-darwin8.10.1 -I/Users/stephen/dev/ruby/1.9_trunk/include/ruby-1.9 -I.

Morning Folks, As most of you know there were a few people who had the following three bugs: * CLOSE_WAIT: Lots of sockets in CLOSE_WAIT state. * 99% CPU: Mongrel''s getting "stuck" pegged at 99% CPU. * LEAK: Memory leak. I''ve successfully fixed these bugs or attributed them to one main cause: pstore. First, the memory leak was because of a bug in how the GC in Ruby

I''ve just committed fastthread 0.5.3, which finally gives us a working SizedQueue (which hadn''t really ever worked in previous versions). Mostly it was just a matter of refactoring Queue and SizedQueue into a single class behind the scenes, so I could move the signalling of the SizedQueue-specific condition variable inside the queue''s critical section. Failing to do so

Well, just when I thought I was out of the fastthread business... Okay, in brief: fastthread is a Ruby extension which re-implements the primitives in Ruby''s thread.rb in C. It was merged into 1.8.6, replacing the old thread.rb implementation, but the version that was merged had a couple serious bugs. So -- now I release fastthread 1.0, which is basically the Ruby 1.8.6 version with

It looks like I got too creative in 0.6.1 and consequently ran afoul of a bug in the Ruby interpreter. 0.6.2 works around the bug and should be entirely stable at this point. Thanks to Young Hyun for his help in coming up with test cases. == what? fastthread is a Ruby library which provides a faster (and non-memory-leaking) C implementation of the concurrency primitives from stdlib''s

Hello Mongrels, Building on the last messages about Fastthread, can we get a detailed survey of the different ways people are deploying their applications? It will help with near-future Mongrel development. Please include the following things: * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, Rack...) * Mongrel version * Mongrel handlers used (rails, dirhandler, camping,