[Nitro] Nitro on Apache

[Robert Mela]

Arne Brasseur wrote:
> Well FastCGI should be good, but actually using CGI with Nitro isn't 
> that easy. Nitro assumes that it handles the complete document-root, 
> while CGI scripts normally just handle a single URL. It takes some 
> clever server configuration to make this work the way it should. I 
> tried with Lighttpd, aliasing "/" to the nitro app script. This works 
> for the root, but not for other URL's. I suppose with apache and 
> mod_rewrite it should be possible.
>
I find the routing works fine if you use this the cgi adapter before 
handing the work off to AdapterHandlerMixin#handle_context:

     uri = ENV['REQUEST_URI']
     script_name = ENV['SCRIPT_NAME']
     context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '')

Somewhere inside  @application.dispatcher.dispatch_context(context) -- 
called from handle_context -- everything is magically generated from  
REQUEST_URI.

Question for George:

It looks to me like Cgi::Http::process in the current CgiAdapter could 
be replaced by a little setup, leaving the heaving lifting to 
AdapterHandlerMixin#handle_context.  I suspect that handle_context is 
likely to be better maintained, since it's what MongrelAdapter uses.

This CGI adapter thing seems a little thing, but who knows -- it might 
hook that one 14-year old developer in Mozambique who only has CGI via a 
friend's account, and latches on to Nitro because it works with CGI... 
then later turns into a super coder....


> With FastCGI the configuration is different, there it's quite easy to 
> set things up.
>> As for Dreamhost --
>>
>> Which fcgi watchdog are you using?  Or is it their determination?  If 
>> so, do you know which one it is?   IIRC, there's  a mode wherein 
>> mod_fastcgi will do the process management/watchdog work internally, 
>> within the Apache process.   If they've got full control over that 
>> configuration you're out of luck.  Otherwise, it's worth 
>> experimenting -- given the financial constraints -- to see whether 
>> you place and name your fastcgi process in a way that it's handled by 
>> mod_fastcgi's internal process manager.
> I don't have much to decide about this, and there's not much 
> information available on the exact workings of their watchdogs. 
> Apparently processes get killed when they take up too much memory, or 
> they run too long. So people have come up with solutions like stopping 
> all fastcgi processes in a cron job or running the garbage collector 
> after every few pages. One guy I just discovered made an alternate 
> rails FastCGI handler that captures SIGTERM and finishes rendering the 
> current page before exiting. This way the watchdogs do no real harm. 
> He's also on Dreamhost :). This would be very useful to me and 
> probably others as well, so I'll look at it again and try to 
> incorporate this in our FastCGI adapter.
>
> I didn't know much about all this adapter business and this has been 
> very educational. I figured since nobody seemed to really care here 
> about (F)CGI I could just go ahead and see what gives.
>
> I tested with Lighttpd and will do some more testing with Apache. 
> Reports on using this both positive and negative are very appreciated.
>
> (ab)
>>
>>
>> Arne Brasseur wrote:
>>> They run on debian. I don't have access to the main apache config. I 
>>> can only use a web panel to select a directory as document root, the 
>>> version of PHP and if I want to enable FastCGI on that domain. 
>>> That's it. The rest has to be done with .htaccess files.
>>>
>>> They make a big thing out of supporting Ruby/Rails, but in the end 
>>> the support totally sucks. They have a watchdog process that 
>>> seemingly randomly kills user processes, so every few pages you get 
>>> a "server 500" because the fcgi process got killed.
>>>
>>> But they're cheap and I payed two years in advance so I'll have to 
>>> live with it a little longer. It's Dreamhost BTW, don't go there if 
>>> you're serious about using Ruby stuff.
>>>
>>> I've been looking at it the last few days and have more or less 
>>> functioning CGI/FastCGI adapters. They need more testing. After that 
>>> I'll send a patch and write something on oxywtf about deploying with 
>>> fcgi.
>>>
>>> Thanks for responding!
>>>
>>> (ab)
>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071019/8dcea953/attachment-0001.vcf