Rails - Jun 2006 - 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://www.zedshaw.com/
http://mongrel.rubyforge.org/

Zed Shaw 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

-- 
Posted via http://www.ruby-forum.com/.

On Mon, 2006-06-05 at 23:19 +0200, Joe wrote:
> Zed Shaw 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/

Zed Shaw 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.