Mongrel Pre-Release 0.3.13 -- Katana Suicide Concurrency

We are days away from the official 0.3.13 release, which will be
followed quickly by 0.4 code named Enterprisey Edition 1.2. This latest
pre-release update closes off the last of the annoying bugs, and adds
one very nasty feature people should check out before we release. Read
about Katanas below.

** This release doesn’t have win32 yet. That’ll be uploaded Monday. **

WHAT IS MONGREL

It’s a web server that runs Ruby web applications. Currently supports
Rails, Camping and Nitro. You can check it out at:

http://mongrel.rubyforge.org/

GETTING IT

Best thing to do is this:

$ gem install daemons
$ gem install mongrel --source=http://mongrel.rubyforge.org/releases/

WHAT’S FIXED

  • Fixes a failure of -P to find PID files.
  • Changes the RailsHandler so that only passes GET or HEAD requests to
    the DirHandler for page caching.
  • Confirms that the new send_file and upload to tempfile works on win32.
    More tests with big files uploaded on win32 are needed.
  • Lots of documentation on installing, with more to come. Full Apache
    documentation and information on writing your own snazzy handlers and
    filters.
  • François SIMOND suggested a check for allow_concurrency and to avoid
    locking Rails if that’s set to true. I tried it, had to change the
    patch but I left it in. Read below.
  • Moved some of the “change to user/group” code around so that any
    Mongrel command can use it.
  • Various code clean-ups and big improvements on the unit test coverage
    and reporting. Check out http://mongrel.rubyforge.org/coverage/
  • Lots of thrashing and code review, not much more will come for 0.3.13
    unless an obviously broken piece needs work.

KATANA SUICIDE CONCURRENCY

I resisted doing this, but it’s going to come down sooner or later now
that François SIMOND figured it out. Mongrel was protecting the world
from the allow_concurrency “feature” but now it lets you kill yourself
in obscenely horrible ways.

If you set ActionController::Base.allow_concurrency=true in your
config/environments/* then Mongrel will NOT guard the Rails
Dispatcher. This means that you’ll get full threaded madness thrashing
your Rails controllers until they die horribly slicing themselves into
tiny little bits leaving you breathless with the destruction.

Mongrel will obnoxiously warn you about this, and people who try it will
NOT get support from me without mad amounts of dough. If you turn this
on, and your world comes crashing around your head, then I warned you.
Otherwise, go ahead and give it a try and see if that improves things
for you.

Enjoy the release, and get those bugs in so we can fix them:

http://rubyforge.org/tracker/?atid=5145&group_id=1306&func=browse

And we still want documentation authors:

http://mongrel.rubyforge.org/docs/contrib.html

Pick a blank page and write it up.


Zed A. Shaw

http://mongrel.rubyforge.org/

Zed S. wrote:

KATANA SUICIDE CONCURRENCY

I resisted doing this, but it’s going to come down sooner or later now
that François SIMOND figured it out. Mongrel was protecting the world
from the allow_concurrency “feature” but now it lets you kill yourself
in obscenely horrible ways.

If you set ActionController::Base.allow_concurrency=true in your
config/environments/* then Mongrel will NOT guard the Rails
Dispatcher. This means that you’ll get full threaded madness thrashing
your Rails controllers until they die horribly slicing themselves into
tiny little bits leaving you breathless with the destruction.

Mongrel will obnoxiously warn you about this, and people who try it will
NOT get support from me without mad amounts of dough. If you turn this
on, and your world comes crashing around your head, then I warned you.
Otherwise, go ahead and give it a try and see if that improves things
for you.

Hey Zed,

Do you know in what ways these obscenely horrible ways might manifest
themselves? I’m not at all aware of what parts of Ruby/Rails may be
thread-safe and where the danger may lie. With PHP, for example, the
thread-safety of various third party libraries is unknown, but
supposedly core PHP is thread-safe. What benefits are there to turning
on concurrency? Somewhat better performance?

You 'da man!
Joe

On Mon, 2006-06-05 at 23:19 +0200, Joe wrote:

Zed S. wrote:

Hey Zed,

Do you know in what ways these obscenely horrible ways might manifest
themselves? I’m not at all aware of what parts of Ruby/Rails may be
thread-safe and where the danger may lie. With PHP, for example, the
thread-safety of various third party libraries is unknown, but
supposedly core PHP is thread-safe. What benefits are there to turning
on concurrency? Somewhat better performance?

I may list out the things that can go horribly wrong in the near future,
but this is kind of a catch-22. I know of things that go wrong, but
they are only in my testing and when I’ve examined the code. They’re
not really bugs in rails, just usage patterns that people have which
don’t work in rails (like firing up popen).

What will most likely happen is people will start using this feature,
they’ll have weird problems with it on that they don’t have with it off,
and then we’ll start to find out what you can and can’t do.

As a side note I’m looking to add a feature for 0.4 that will let you
give a list of “locked URIs” to a special guard handler. This will let
you lock stuff that needs it and leave the rest alone.


Zed A. Shaw

http://mongrel.rubyforge.org/

Zed S. wrote:

As a side note I’m looking to add a feature for 0.4 that will let you
give a list of “locked URIs” to a special guard handler. This will let
you lock stuff that needs it and leave the rest alone.

It might be neat to allow the reverse as well – a set of thread-safe
URIs that don’t lock. It might be easier to identify a handful of
high-volume URIs that are known (and can be proven) to be safe, rather
than presume that all but a set of URIs are safe.