Search results

I am pretty surprised that poll() fails. Looks like need to check the universal poll event dispatcher. :-) devpoll has better scalability when you deal concurrent connections >1000.

Looks like something wrong with the event dispatcher, the server does not get the event from OS regarding the blocked request at all. Are you using devpoll(), if so, please give plain poll() a try, see if it help. Thank you very much for the debug information. :-)

Sorry about that, ktrace probably is a BSD thing. Usually, you can use "truss -d <pid>" to attach to a running process to trace system calls made by that process. This way, you can get a rough idea about what a process was doing.

Which version of solaris 10 are you using? The admin interface made a connection back to web server and tell it to restart. Do not use kill. If you don't mind, can you please post the the trace result of "ktrace" of the admin_php when it stop working? Also, debug logging can be turned on for...

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...

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...

For the PHP socket connect problem, you can try it manually, the admin port is logged at the beginning of the log file, do 'netstat -an | grep <admin_port>", if you see a line contain "LISTEN", the admin port is in good shape, then do "telnet 127.0.0.1 <admin_port>", if you get connection...

the 404 handler in lsws-2.1.18 cannot process post request properly, will be fixed in 2.1.19, please use rewrite rules to dispatch request to rails, for now.

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...

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"...

That pretty strange. Do you mean that admin stop working completely once a php page of a normal site was accessed? Not even able to load any admin page? Is there any "admin_php" process running? You can try to replace "lsws/admin/fcgi-bin/admin_php" with your customized lsphp binary, but I am...

At least, dispatch.lsapi works properly now. :-) The "File not found" error is normal. Have you set "Auto Start" to "yes" for the "RubyRailsLSAPI" application? Your "initial request timeout" should be increased, maybe like "60". Please check if the file "/tmp/lshttpd/rubyrailslsapi.sock"...

Something wrong with the dispatch.lsapi, can you run it from command line?

Templated vhost configurations are in lsws/conf/httpd_config.xml, templates can be stored anywhere you like, the default location is under lsws/conf/templates/.

FreeBSD6 needs a special build, please try http://www.litespeedtech.com/packages/2.1/lsws-2.1.17-std-i386-freebsd6.tar.gz That's the latest FreeBSD6 we built.

Your problem is that another web server is using port 80, so litespeed cannot listen on port 80 again, change to another port like 81 if you cannot turn off the other web server. There are file/directory permission problem for the admin log files. A default installation should set permissions...

Yes, no need to restart LSWS, web server can detect it automatically, close the older file then create a new one. :-)

The gem version will be updated a little while later if there is no bug reported on the version. You probably need to uninstall the gem version first when you try the new version.

The first one might be MIME type syntax validation problem in admin interface. Will check. The second one is beause "application/atom+xml" must be defined as a MIME type first.

Please try ruby-lsapi 1.4 release, the maximum number of children process is limited to twice of the configured value, the children process can stays alive as well.