On 1/3/08, Will Green <[EMAIL PROTECTED]> wrote: > >From http://blog.codefront.net/2008/01/02/whats-new-on-edge-rails-the-pilot/ > > A native Mongrel handler has been introduced. This is so that it can be > worked on independent of Mongrel's release cycle (the Rails handler is > currently in the Mongrel codebase). Jeremy Kemper (bitsweat) has already made > a minor performance improvement by moving the mutex from the handler itself > into the dispatcher. This means that as Rails gets more threadsafe, the Rails > team can push the mutex further down so that it's not a (scary) giant lock > (the existing Mongrel Rails handler has a synchronized block around Rails' > dispatcher). > > Here's the relevant Changeset URL: http://dev.rubyonrails.org/changeset/8488
Note, this is still an experiment, not the default. You can use the native handler on Rails trunk using script/server new_mongrel. For starters, I imported a pared-down Rails handler and mongrel_rails' GemPlugin commands so they'll work with script/server directly. I mount a DirHandler before the Rails handler and pass through missing files rather than handling both in the Rails handler. This needs a small DirHandler change to pass through missing files instead of sending 404. I think importing the GemPlugins may be overkill, but I couldn't see how to massage Start#run into setting up the listener how I'd like, otherwise. I think a lot of the goodies in there, like pidfile management and debug handling, could be extracted. It'd make building your own mongrel runner easier. Next steps. On the Mongrel handler side: wean Rails off the CGI wrapper. On the Rails side: work directly with Mongrel request + response; use a wrapper to cajole CGI::Session into compatibility; move route recognition and sending response body out of the mutex. jeremy _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
