similar to: The (Potentially) New Maintainers

Hello Everyone, I''d like to just officially announce that the new volunteers are in charge and given control of the project. I won''t be doing anything more than helping them get ramped up, but they''ll be in charge of doing all the stuff you folks want and are basically the owners from now on. Everyone in the new volunteer list will probably do a little announce, but

Hopefully that gets everyone''s attention. Evan Weaver has whined enough to make me do a release to change the requirements on the Mongrel gem so that it doesn''t need the cgi_multipart_eof_fix anymore. *************************** THIS ALSO MEANS THAT MONGREL WILL HAVE TO REQUIRE RUBY 1.8.6 OR GREATER! NO EXCEPTIONS! *************************** I know Debian guys like to hack

Hey folks, I''m falling behind in my Mongrel duties and seriously need to recruit an enterprising individual to take on the patch queue and help push out a new release with some minor fixes. The goal would be to just get patches that are currently languishing, pull them together, put them in the source, write some tests to try them, and then one slight design change. If this works out

Hello Guys, I''m reviewing the code for 1.9, and forgot about this when we first spoke on this subject. The current way we stop threads is using Thread#raise to spread StopServer exception, which will not work as expected in 1.9. 1.9 will treat raised exceptions as #kill, like JRuby does, so the worker threads will not finish serving the client and _then_ exiting, but will be

Hi, As many of you know I also wrote the SCGI connector for Ruby on Rails before I worked on Mongrel. I eventually stopped working on it since it was kind of pointless, but Jeremy Evans has stepped up and offered to maintain it. He''s now the official maintainer and will be managing the SCGI project: http://rubyforge.org/projects/scgi/ If anyone is interested in helping out then let

Hi I posted this to the Ruby on Rails Talk group but I thought I''d post it here too as it''s probably a more appropriate group. Hope this is ok. I''m running a 2-instance Mongrel cluster behind Apache 2.2.4 with Rails 1.2.3. If no requests are received by the application for several hours (this usually happens overnight) then Mongrel stops responding and no requests are

Ok, my little experiment proved my point. Ruby 1.8.6 is not viable for production. Requiring it and dropping the cgi fix back patch isn''t an option. It''s not even clear whether the latest 1.8.6 has any remaining fixes. So, crisis averted. Mongrel WILL NOT require 1.8.6 and now I''m going to dig out where these security fixes are coming from and how to host this kind

Hi list, I downloaded and tried to install Mongrel (latest stable version) from the -win32 gem. Platform is Win2K. It said it needed daemons so got and installed that. Then it said it needed cgi_multipart_eol_fix (I think that was the name, not at my machine now, can confirm later and repost if needed). Googled for that but couldn''t find it. (Don''t have net connectivitity for a

Hey so, People are asking about Mongrel Ruby 1.9 compatibility. Isn''t the point of 1.9 for library developers to have time to get ready for 2.0? It''s not like 1.9 is a production release. Evan -- Evan Weaver Cloudburst, LLC

Dear Mongrels, The same questions keep coming up over and over on the list, which is ok, but not really optimal. If we added a wiki to the Mongrel site to handle FAQs, what wiki should it be? Required features would be: * Spam protection * Doesn''t look shitty I would probably spring for Trac (and also migrate the bugtracker) if noone else has opinions, but I''m sure some of

This is a proposed patch for the security hole reported today. You can just add the test for @path being at index 0 in the exanded req_path as shown below. Take heed of the comment I''ve added too, and there was a test for this very attack in the unit test suite, so it was removed by someone as well. I didn''t test this but I''m pretty sure it''s the fix. ===

This is stupid, I made Luis, Wayne, Evan, and Filipe admins. Make anyone else admins that you want and do all the changes you need. Especially since you guys are mostly running the show anyway. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/

Hi Zed, I checked in a pure-Ruby URI classifier to Mongrel trunk. Ola''s Java port of the TST had some bug, and I don''t think it''s necessary in the first place. The Ruby classifier is around 25 lines instead of the 400-odd lines for the C extension and the 200-odd for the Java extension. It uses a Regexp which is perhaps shady: @matcher = Regexp.new(routes.map do

I''m trying to figure out a possible memory leak problem I have in my application. I''ve tested both with mongrel and webrick and the problem remains. So I think it''s not a mongrel problem, but I''m posting here to see if anybody can help me. The RAILS application is quite simple, no special plugins ( no RMagick that has the memory problem ),

Hello Guys, I''ll like to suggest a small release fix before we start doing big changes: platform fixes. Current we''re setting MSWIN32 (mswin32) as platform for Windows gem, but we should be using Gem::Platform::CURRENT instead (i386-mswin32 as current Ruby windows implementation). Also, the jruby/java platform need to be defined. That change will ease the compatibility path

Hi all, i im using Capistrano2 to deploy my rails app and Apache/Mongrel as it''s env. All is well except deploy:rollback task. the following is log messages when running cap deploy:rollback : [DEPRECATION] Capistrano.configuration is deprecated. Use Capistrano:: Configuration.instance instead * executing `deploy:rollback'' * executing `deploy:rollback_code'' *

Guys, Just for fun, I tried to see (I know, a silly way to test it) how much overhead we have calling the C functions of the extensions. the benchmark script and the results: http://pastie.caboo.se/128646 The naive C extension: http://pastie.caboo.se/128647 I compared 1.8.6 (VC6 and mingw builds) against a fresh checkout of ruby trunk. What I understand from that is 1.9 is slower than 1.8

I am using rvm installed on Ubuntu 10.04 as recommended in the rvm docs (including changes to .bashrc) and all is working well with several versions of Rails, and Ruby 1.8.7 and 1.9.2. If I run rvm use 1.9.2 it says Using /home/colinl/.rvm/gems/ruby-1.9.2-p0 and if I run rvm info It shows exactly what I would expect for 1.9.2 and I can start the rails server and all is well. The problem arises if

Hi, I just did a clean install of Ruby 1.8.5 Rubygems 0.9.0 and the Mongrel and Mongrel_Cluster gems. I used only the Debian Etch package manager, nothing compiled myself. Now, on a testapp when I do a script/server, I get the: ** Ruby version is not up-to-date; loading cgi_multipart_eof_fix warning. But it''s not serving my app. Ruby is immediately on 100% CPU load (and 0.7%

hi. apologies if this has been asked before... my configs: ruby -v 1.8.5 mongrel 1.0.1 rails 1.2.3 i do a mongrel_rails start -e production -p 4000 -d it''ll say: ''** Ruby version is not up-to-date; loading cgi_multipart_eof_fix'' but that shouldn''t be the problems, since i see that all the time and my clusters work.. ( oh yeah, does it matter i have other