Support

delynn · #1 08-06-2006, 12:18 PM

I'm having trouble getting LiteSpeed to properly display the maintenance page that Capistrano creates while performing an update. The 404.html page that is found in my RAILS_ROOT/public directory is always served unless I specifically make a request for /system/maintenance.html.

Here is what I have for Rewrite Rules for my Virtual Host:

Code:

RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /system/maintenance.html [L]

Here is the logging info for a request to the Virtual Host:

Code:

[REWRITE] Rule: Match '/' with pattern '^.*$', result: 1
[REWRITE] Cond: test '/var/www/rails_project/releases/20060806174920/public/system/maintenance.html' with pattern '-f', result: 0
[REWRITE] Cond: Match '/var/www/rails_project/releases/20060806174920/public/' with pattern 'maintenance.html', result: -1
[REWRITE] Source URI: '/' => Result URI: '/system/maintenance.html'
[REWRITE] Last Rule, stop!

As you can see, things appear to be working correctly, but the maintenance.html page is still not displayed. I have verified that the Allow Override HTAccess option on my Virtual Host's General tab is set to "N/A". I have also commented out all the lines in the .htaccess file that exists in RAILS_ROOT/public thinking that might still be getting in the way.

Does anyone have any ideas what might be going on here? Thanks in advance!

--
DeLynn Berry
delynn@gmail.com
http://delynnberry.com

mistwang · #2 08-06-2006, 07:12 PM

That's strange.

Is "File not found" logged after the rewrite log entries in the error.log? You should be able to verify whether that file exists or not.

It does looks like that the rewrite rule has been executed properly. If you can get to the maintenance page with "/system/maintenance.html" then you should get that page when you access "/".

I think maybe Capistrano replaced the document root during the update, so "/system/maintenance.html" does not exist. However, in the manually crafted test environment, it should work fine.

delynn · #3 08-06-2006, 07:49 PM

Quote:

Originally Posted by mistwang

That's strange.

Strange indeed. I did a double check on the VHOST log file as well as the server error log file and in both instances the last entry when making a request to "/" is:

Code:

[REWRITE] Last Rule, stop!

Quote:

Originally Posted by mistwang

I think maybe Capistrano replaced the document root during the update, so "/system/maintenance.html" does not exist. However, in the manually crafted test environment, it should work fine.

I'm not aware of Capistrano doing anything to change the document root, but if I get some time tomorrow, I'll look into it. I know that "/system/maintenance.html" does exist (both physically as well as being able to be accessed via that URI). To troubleshoot this issue, I've manually run the "disable_web" Capistrano task to ensure that the file exists permanently until I manually run the "enable_web" task. What has me so puzzled is that the RAILS_ROOT/public/400.html file is what is being displayed instead of a more generic Litespeed 400 or 500 page.

Just as an experiment, I renamed the RAILS_ROOT/public/404.html and 500.html files and now I'm getting the following:

Code:

Status: 500 Internal Server Error Content-Type: text/html
Application error (Rails)

Color me stumped.

--
DeLynn Berry
delynn@gmail.com
http://delynnberry.com

mistwang · #4 08-06-2006, 08:22 PM

Quote:

Just as an experiment, I renamed the RAILS_ROOT/public/404.html and 500.html files and now I'm getting the following:
Code:

Status: 500 Internal Server Error Content-Type: text/html
Application error (Rails)

Color me stumped.

Looks lite rails did that, as LiteSpeed has no idea about using 404.html, and will not produce a 500 response.

Are you using rewrite rule or 404 handler to dispatch request to rails dispatcher?
I guess that the rewritten url "/system/maintance.html" has been redirected to Rails dispatcher instead of being served by web server itself. You can turn on debug logging to finit it out.
Also, you can try changing the rewrite rule from

Code:

RewriteRule ^.*$ /system/maintenance.html [L]

to

Code:

RewriteRule ^.*$ /system/maintenance.html [L,R]

to perform a redirect, maybe that can help.

delynn · #5 08-07-2006, 01:44 PM

mistwang, thanks for all your help so far. I may be on to something here on my end though.

I pulled all the Rewrite Rules out of my LiteSpeed Virtual Host configuration, and since I'm still seeing the same results, I'm beginning to think that the problem must have something to do with my setup. I failed to mention last night that I'm proxying all my requests through a Load Balancer to a cluster of Mongrel processes. Might this be the cause of my problem?

As an aside question, while looking through the LiteSpeed Wiki this morning, I noticed the article on LSAPI. Since I only just started playing around with LiteSpeed and have been happy with Mongrel, I made note of the article but decided to hold off implementing it. I'm beginning to wonder if ditching Mongrel and going with LSAPI might not be a better solution though. My first question here with regard to LSAPI is, how easy is it to scale LSAPI up from one listener on one box to mulitple listeners on one or more machines?

Thanks again for your help and input.

--
DeLynn Berry
delynn@gmail.com
http://delynnberry.com

mistwang · #6 08-07-2006, 02:16 PM

Ok, that's more clear now. The request must be forwarded to mongrel, when request get forwarded through proxy, the original request URL is used instead of the written URL.

Using LSAPI will fix this problem for sure. It is better than proxy to mongrel as well. At least for a single machine setup, no need to bother mongrel cluster and load balancing, and performance should be better.

To scale beyond one server, I recommend to install LSWS + LSAPI on each cluster node and have a instance of LSWS load balancing to those cluster nodes. This configuration should be faster than a mongrel cluster setup.

In the future, we may come up with a better solution to have LSAPI integrated with Capistrano, so the cluster can be easily managed via capistrano.

We will release a dedicate load balancer soon if you need more than the stateless load balancer in LSWS.

delynn · #7 08-07-2006, 02:40 PM

Quote:

Originally Posted by mistwang

Ok, that's more clear now. The request must be forwarded to mongrel, when request get forwarded through proxy, the original request URL is used instead of the written URL.

Using LSAPI will fix this problem for sure. It is better than proxy to mongrel as well. At least for a single machine setup, no need to bother mongrel cluster and load balancing, and performance should be better.

Yeah, this makes a ton more sense. Sorry I didn't think of that last night, but it had been a long day dealing with Capistrano and I just wasn't thinking.

Quote:

Originally Posted by mistwang

In the future, we may come up with a better solution to have LSAPI integrated with Capistrano, so the cluster can be easily managed via capistrano.

Hmm, that answers my next question. Do you know if anyone has attempted using the Spinner/Spawner/Reaper scripts with the LSAPI dispatcher?

Quote:

Originally Posted by mistwang

We will release a dedicate load balancer soon if you need more than the stateless load balancer in LSWS.

Cool! I look forward to the release.

Thanks again for the help!

--
DeLynn Berry
delynn@gmail.com
http://delynnberry.com

mistwang · #8 08-07-2006, 03:00 PM

Quote:

Originally Posted by delynn

Hmm, that answers my next question. Do you know if anyone has attempted using the Spinner/Spawner/Reaper scripts with the LSAPI dispatcher?

Our knowledge regarding Capistrano is still pretty limited at this moment. If it can handle FCGI deployment well, it can do the same thing with LSAPI Ruby, as LSAPI works in the similar way as FCGI, just the underlying protocol is different.

If LSWS + LSAPI is used on each node, you only need to find a way to let Capistrano run command "lswsctrl restart" to apply the code change, NO DOWNTIME at all during the restart.

delynn · #9 08-07-2006, 03:15 PM

Quote:

Originally Posted by mistwang

Our knowledge regarding Capistrano is still pretty limited at this moment. If it can handle FCGI deployment well, it can do the same thing with LSAPI Ruby, as LSAPI works in the similar way as FCGI, just the underlying protocol is different.

If LSWS + LSAPI is used on each node, you only need to find a way to let Capistrano run command "lswsctrl restart" to apply the code change, NO DOWNTIME at all during the restart.

Cool. I'll give it a shot tonight or tomorrow and report back here with my findings!

mistwang · #10 08-23-2006, 12:54 PM

Any chance to try it out? Any update?

Thanks!