Forum: Ruby on Rails Mongrel Pre-Release 0.3.13 -- Katana Suicide Concurrency

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Zed S. (Guest)
on 2006-06-05 14:10
(Received via mailing list)
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=1...

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://www.zedshaw.com/
http://mongrel.rubyforge.org/
Joe (Guest)
on 2006-06-06 01:19
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
Zed S. (Guest)
on 2006-06-06 02:44
(Received via mailing list)
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://www.zedshaw.com/
http://mongrel.rubyforge.org/
Michael A. Schoen (Guest)
on 2006-06-06 03:58
(Received via mailing list)
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.
This topic is locked and can not be replied to.