I have this problem with a real application, but here's a simple test case that's failing the same way. (using ruby 1.8.7p249) New app: $ rails rails3 create ... $ cd rails3 Add 'mongrel' to Gemfile $ bundle install Fetching source index from http://rubygems.org/ ... $ rails server => Booting Mongrel => Rails 3.0.0.beta3 application starting in development on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server Starts with mongrel. But the following crashes: $ mongrel_rails start ** Starting Mongrel listening at 0.0.0.0:3000 ** Starting Rails with development environment... /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/railties-3.0.0.beta3/lib/rails/engine.rb:122:in `delegate': wrong argument type Symbol (expected Proc) (TypeError) from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/activesupport-3.0.0.beta3/lib/active_support/core_ext/module/delegation.rb:121:in `each' from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/activesupport-3.0.0.beta3/lib/active_support/core_ext/module/delegation.rb:121:in `delegate' from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/railties-3.0.0.beta3/lib/rails/engine.rb:127 from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/railties-3.0.0.beta3/lib/rails/plugin.rb:1:in `require' from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/railties-3.0.0.beta3/lib/rails/plugin.rb:1 from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/railties-3.0.0.beta3/lib/rails/application.rb:3:in `require' from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/railties-3.0.0.beta3/lib/rails/application.rb:3 from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/railties-3.0.0.beta3/lib/rails.rb:7:in `require' ... 19 levels... from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/mongrel-1.2.0.pre2/bin/../lib/mongrel/command.rb:210:in `run' from /Volumes/Users/renn/.rvm/gems/ruby-1.8.7-p249@rails3/gems/mongrel-1.2.0.pre2/bin/mongrel_rails:282 from /usr/bin/mongrel_rails:19:in `load' from /usr/bin/mongrel_rails:19 Not sure where to go from here. Any help would be appreciated.
on 2010-04-29 03:45
on 2010-04-29 06:12
On Wed, Apr 28, 2010 at 10:38 PM, Doug Renn <email@example.com> wrote: > Add 'mongrel' to Gemfile > => Ctrl-C to shutdown server > > Not sure where to go from here. Any help would be appreciated. > There are substantial changes in the way Rails 3 bootstrap that differ considerably from what mongrel_rails is trying to perform. The problem is that mongrel_rails needs to work with older versions of Rails and newer too. I haven't played enough with Rails 3 to actually use mongrel with it, but due the changes in rails 3 bootstrap, I would rather use rack or rails server directly instead of mongrel_rails. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry
on 2010-04-29 17:30
Luis Lavena wrote: > > I haven't played enough with Rails 3 to actually use mongrel with it, > but due the changes in rails 3 bootstrap, I would rather use rack or > rails server directly instead of mongrel_rails. > Or passenger. I get the feeling that most developers have abandoned mongrel for passenger, and mongrel no longer has very many developers working on improving/maintaining mongrel itself either. Jonathan
on 2010-04-29 17:44
On Thu, Apr 29, 2010 at 11:19 AM, Jonathan Rochkind <firstname.lastname@example.org> wrote: > Well, I might be biased on my response. I've been working on bring new changes to mongrel to ease the development of it and set the ground to bring better rack integration from Unicorn. You can see all these changes here: http://github.com/fauna/mongrel/commits So is not fair to say that is abandoned. While I use passenger in some server, I still use mongrel in more than 75% of all my production environments, even locally. I'm cleaning up JRuby support for a new 1.2.0 release and new ones will follow. What I have suggested about using "rails server" instead of mongrel_rails is because mongrel_rails needs to be compatible with previous version of Rails, and I'm not a 100% Rails user to explore that. See this ticket: http://github.com/fauna/mongrel/issues#issue/2 That said, if anyone work on that would happily integrate it back. Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry
on 2010-04-29 18:00
Passenger might be the way to go long term but right now I have some production machines that I can't take the time to upgrade/test/debug. I can't use rails server in production because I need to launch them specifying --user and --group (plus it would mean changing the whole request dispatch / process scheme I'm using). I'll try to dig deeper into this over the weekend. Any pointers would be welcomed.
on 2010-04-29 19:03
Awesome, good to know that you're working on mongrel! If you're suggesting rack or rails server directly in Rails3... ah, but still with mongrel, just not wtih mongrel_rails? Curious what reasons you have to prefer mongrel to passenger? Jonathan
on 2010-04-29 20:19
It's more inertia than preference. I've been running passenger on one of our test servers, but our production environment consists of a pool of servers that run a bunch of low volume rails apps. The life cycle of these apps are managed through custom code that launches them via mongrel_rails (this setup pre-dates passenger). Passenger would be a fine solution (although I wish it provided better control over how many of which app were running), but requires a lot of testing before releasing to production. One possibility is to install passenger on the production machines but not run it in "auto-detect" mode. That way one app at a time could be moved to passenger. I need to do some more testing of that configuration. Still in the short term the shortest path for me to get a rails 3 app on our production servers is to be able to launch it via mongrel_rails.