search for: a6ba423

Can''t install the latest mongrel (1.1.5) in JRuby (jruby revisions ranging from 6600 to 6750[trunk] checked) -- the platform is not being identified and it''s trying to do native compilation. I''m not sure it''s actually a problem with Mongrel or JRuby however -- perhaps there isn''t a mongrel-1.1.5-java.gem on rubyforge? Some investigation below: $

The find_pid method no longer returns a nil by default which causes some breakage in cases where the pid can''t be found since the local variable ''pid'' becomes the entire output of the ''ps'' command. Can you add this return back in so that it behaves the way it did earlier? thanks, eric

Just as I was composing an elaborate email illustrating that capistrano version detection was broken, I realized that 1.0.5 fixed the problem :) While we''re on the topic of code changes-- where is the mongrel_cluster subversion repository? I looked all over the mongrel site, sorry if I''m missing something obvious. Thanks, John -- John Joseph Bachir http://lyceum.ibiblio.org

Please note this message is not related to my previous one from yesterday, this is on a different server (textdrive server). I have only one mongrel application running but ''randomly'' it will go down, the mongrel.log file shows: ERROR: undefined method ''request_uri'' for #<URI::Generic:0x5383948 URL:*> ERROR: bad URI(is not URI?): c:\boot.ini [FATAL]

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 all, There is a bug with Mongrel on JRuby 1.0.3 that the JRuby guys want fixed before they release it. If it''s ok with people I''d like to fix that, revert (at least for now) the proxy response change, and tag that as 1.1.2 and release it. Anything wrong with this plan? Evan -- Evan Weaver Cloudburst, LLC

Guys, Subject says everything: http://www.frederico-araujo.com/2007/12/18/my-first-successful-booting-rails-2-0-2-ruby-1-9-attempt Even ActionView uses Proc.binding (which isn''t correctly supported in 1.9) it appears that lot of folks will try to put their hands in Ruby 1.9 when it comes out, and of course, try to get Rails with Mongrel running in it. Zed, Wayne, Evan and ry: maybe we

...grel.rubyforge.org/) was written by Zed Shaw. This manual page was written for the Debian system by Filipe Lautert <filipe at icewall.org>. It might be used and redistributed under the same terms as the program itself. --- Thanks, filipe lautert filipe { AT ] icewall.org GPG 1024D/A6BA423E Jabber lautert at jabber.ru

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%

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

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

Hi, I''m able to run a ROR application in a Red Hat Enterprise Linux 4.4 environment, as long as I start my mongrel_cluster via the command line: [chris at localhost ~]$ mongrel_cluster_ctl start I take a look at the two mongrel_rails processes that were just created: [chris at localhost log]$ ps -ef | grep mongrel chris 4781 1 5 05:55 ? 00:00:02 /usr/local/bin/ruby

Hello all. I too found out that I sometimes have some action that can take up to 10 seconds in my rails application. I''ve read all arguments Zed made about polling/and inbox strategies, and I think I just can''t work around my feeling that a "wrong" request that takes up too much time should be able to lock subsequent requests in mongrels queue. That''s what

I seem to have a (recent) problem with mongrel on NetBSD. I''m running a development release of NetBSD (called NetBSD-current 4.99.34). When I start mongrel, it listens on the IPv6 wildcard address, but not on the IPv4 wildcard: => Booting Mongrel (use ''script/server webrick'' to force WEBrick) => Rails application starting on http://0.0.0.0:3000 => Call with

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

Hey, I''m working on a project, and mongrel may be part of the stack, but I''ve got some more general questions and ideas I''m hoping to run by this list. The people on this list have a broader knowledgebase and more experience than any place else I know - plus a general friendliness and willingness to help! I''m working with a company who has a really antique