Mongrel users - Nov 2006 - Mongrel 0.3.17 PR -- Big Work Day, 1.0 RC1 Very Close

Hello Everyone,

We''re hard at work getting the hot new win32 service Luis wrote out and
ready for production.  We''re hoping to have that included in the 1.0
RC1 release we make very soon.

This pre-release is just to make sure that we didn''t step on any toes.
Install it with:

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

The fastthread gem implements mentalguy''s fastthread set of Thread
locking alternatives.  It is optional, so if it causes you problems, remove it
from your gems:

 $ gem uninstall fastthread

Restart Mongrel and all will be as it was before.  The fastthread stuff will
hopefully make Mongrel a little quicker and also reduce it''s memory
leakage potential.

CHANGES

This release features preliminary support for fastthread, the fixing of all the
bugs reported that could be fixed, and a small change to how headers go out so
Rails 1.2 RC1 is good.  This change makes it so that headers only go out once,
first come first served.

Read the ChangeLog: http://mongrel.rubyforge.org/releases/ChangeLog

I also removed the proposed new multipart mime parsing since it was too
experimental.

SITE

There were a bunch of changes to the site, but mostly just corrections.  New
pages that people can access are:

A joke page about Mongrel MUDCRAP certification that hasn''t changed but
is now accesible from the site menu: http://mongrel.rubyforge.org/certified.html

A page pimping books: http://mongrel.rubyforge.org/books.html

And there''s now an Atom feed at http://mongrel.rubyforge.org/feed.atom
which you can subscribe to and get notified of updates to *any* pages.  Let me
know how this works out.

BOOKS

You''ll notice the books page mentions my book, as well as one by Fabio
Akita, but I want to mention any books that mention Mongrel as well.  The more
information about Mongrel there is the better.  If you''ve got a book
that available for purchase then let me know and I''ll put it on the
site promptly.


LINKS

News: http://mongrel.rubyforge.org/news.html
Atom: http://mongrel.rubyforge.org/feed.atom
ChangeLog: http://mongrel.rubyforge.org/releases/ChangeLog
Books: http://mongrel.rubyforge.org/books.html
Certified: http://mongrel.rubyforge.org/certified.html

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

Hello Zed,

Just wanted to let you know that from the testing I''ve done this
release
seems to be very stable on my setup. So far I have been unable to crash
mongrel when using 512 or 128 processors. I''m still experiencing
lockups
with 1024 processors though. Additionally it seems something is
still leaking memory when threads get killed. I am seeing processes
eating up to ~95MB with 512 processors and ~170MB with 1024. It does
seem to only grow to somewhere around these sizes and then it stops
leaking. Unfortunately the memory is not freed again as far as I can
tell. But keeping the number of processors low will also keep the memory
usage acceptable.

Anyways, I''m really excited to have a stable mongrel, so thank you very
much!

-- 
Cheers,
- Jacob Atzen

128, 512, and 1024 Processors (hardware)?  Do you perhaps mean processes 
(software)?

You either have some serious SERIOUS Enterprisey Hardware, or you''re 
spawning an (IMHO) ridiculous number of Mongrels...

Jacob Atzen wrote:
> Hello Zed,
> 
> Just wanted to let you know that from the testing I''ve done this
release
> seems to be very stable on my setup. So far I have been unable to crash
> mongrel when using 512 or 128 processors. I''m still experiencing
lockups
> with 1024 processors though. Additionally it seems something is
> still leaking memory when threads get killed. I am seeing processes
> eating up to ~95MB with 512 processors and ~170MB with 1024. It does
> seem to only grow to somewhere around these sizes and then it stops
> leaking. Unfortunately the memory is not freed again as far as I can
> tell. But keeping the number of processors low will also keep the memory
> usage acceptable.
> 
> Anyways, I''m really excited to have a stable mongrel, so thank you
very
> much!
>

On Sat, Nov 25, 2006 at 07:49:35PM +0100, Jacob Atzen
wrote:
> eating up to ~95MB with 512 processors and ~170MB with 1024. It does
> seem to only grow to somewhere around these sizes and then it stops
> leaking. Unfortunately the memory is not freed again as far as I can
> tell.
It appears this is only a problem when Rails is in development mode. In
production mode all memory is nicely deallocated as far as I can tell.

-- 
Cheers,
- Jacob Atzen

On Sat, 2006-11-25 at 01:11 -0500, Zed A. Shaw wrote:
> Restart Mongrel and all will be as it was before.  The fastthread
> stuff will hopefully make Mongrel a little quicker and also reduce
> it''s memory leakage potential.
Incidentally, in 0.4 I think I''ve finally taken care of all of the
issues Luis identified as blocking a Win32 build of fastthread.  I guess
the main remaining thing is to write the Win32 gemspec magic.

-mental
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url :
http://rubyforge.org/pipermail/mongrel-users/attachments/20061125/55f229d5/attachment.bin

On Sat, Nov 25, 2006 at 02:01:02PM -0500, Will Green
wrote:
> 128, 512, and 1024 Processors (hardware)?  Do you perhaps mean processes 
> (software)?
> 
> You either have some serious SERIOUS Enterprisey Hardware, or
you''re
> spawning an (IMHO) ridiculous number of Mongrels...
I was refering to the -n parameter. From the output of mongrel_rails
start -h:

  -n, --num-procs INT              Number of processors active before
        clients denied

-- 
Cheers,
- Jacob Atzen