Script/server lighttpd on Windows

Rails
1

Has anyone been able to get script/server to successfully use lighttpd
on a Windows box? When I try to start the server I get:

PROBLEM: Lighttpd is not available on your system (or not in your path)

So then I add “C:\lighttpd\sbin” to the path for the console session,
and it still fails with the same error.

If anyone has some success with this I sure would like to know. Webrick
is slow and single threaded, neither of which are working for me.

2

On 4/26/06, Alex W. [email protected] wrote:

The lighttpd server script has this code in it:
unless RUBY_PLATFORM !~ /mswin/ && !silence_stderr { lighttpd -version }.blank?
puts “PROBLEM: Lighttpd is not available on your system (or not in
your path)”
exit 1
end

…which means it will always fail on Win32.

Have you tried Mongrel? It’s very fast, and very well-supported on
Windows.

3

Wilson B. wrote:

On 4/26/06, Alex W. [email protected] wrote:

The lighttpd server script has this code in it:
unless RUBY_PLATFORM !~ /mswin/ && !silence_stderr { lighttpd -version }.blank?
puts “PROBLEM: Lighttpd is not available on your system (or not in
your path)”
exit 1
end

…which means it will always fail on Win32.

Have you tried Mongrel? It’s very fast, and very well-supported on
Windows.

Dang, I just want to use lighty for development, not serve an app
publicly.

Is mongrel easy to start and stop like script/server and will work well
for developing a rails app?

4

This might be of interest… found on the lighttpd on Windows as a
service using FireDaemon

I am also interested in Mongrel and Lighttpd. I run Apache on Windows
with a lot of PHP stuff installed, and it appears right now the best way
to run rails apps is to pass rail app requests past Apache to Mongrel or
replace Apache with Lighttpd, then make all my existing PHP stuff work
on Lighttpd. Which I am not enthused about. Am I quoting the best
current Windows options correctly? (aside from getting off Windows of
course…)

Alex W. wrote:

Wilson B. wrote:

On 4/26/06, Alex W. [email protected] wrote:

The lighttpd server script has this code in it:
unless RUBY_PLATFORM !~ /mswin/ && !silence_stderr { lighttpd -version }.blank?
puts “PROBLEM: Lighttpd is not available on your system (or not in
your path)”
exit 1
end

…which means it will always fail on Win32.

Have you tried Mongrel? It’s very fast, and very well-supported on
Windows.

Dang, I just want to use lighty for development, not serve an app
publicly.

Is mongrel easy to start and stop like script/server and will work well
for developing a rails app?

5

On 4/26/06, Alex W. [email protected] wrote:

Yep.
“mongrel_rails start” is all you need, and there are command-line
options to enable very nice debugging output.

6

I’m curious. What’s your reason for wanting to use lighty for
development?

Well not specifically lighty I guess, just something faster than
webrick. And not only is webrick slow but single threaded, and my app
has a few long running actions that report their progress via ajax
calls. The problem is that since Webrick is single threaded it cant
process the ajax calls while the long running action is working.
Currently I actually have to upload it the server in order to test it,
causing unnecesary svn commits.

I’ll see if mongrel can tickle my fancy.

7

Alex W. wrote:

I’ll see if mongrel can tickle my fancy.

WEBrick itself isn’t single threaded (and I’m not sure that it’s slow,
either). Running Rails under WEBrick is single threaded, and the same is
true of running Rails under Mongrel. To get concurrency you need
multiple server processes - whether FastCGI, SCGI, or Mongrel - running
behind Apache, lighty, or something else.

regards

Justin

8

Hi Alex,

Alex W. wrote:

Dang, I just want to use lighty for development,
not serve an app publicly.

I’m curious. What’s your reason for wanting to use lighty for
development?

Is mongrel easy to start and stop like script/server
and will work well for developing a rails app?

Yes. Mongrel is just as easy as WEBrick. Rather than ‘ruby
script\server’,
to use Mongrel

9

On 4/26/06 3:38 PM, “Alex W.” [email protected] wrote:

I’ll see if mongrel can tickle my fancy.

Sorry Alex, not matter what Rails has to get locked. If you have very
long
running processes and need to give updated status, there’s a pattern you
should probably look into. Basically, you offload the real work to a
DRb
server (they’re trivial to write). The DRb server then gives you status
on
the job which you report via Ajax. When the work is done you collect
the
result from the DRb server and display it.

Here’s a basic kind of pseudo code (which I’ve got to write up soon):

def setup_work
worker = WorkerClient.new(host, port) # you write this client with
DRb
ticket = worker.dowork(“blah”)
session[:ticket] = ticket
end

def ajaxy_worker_done_check
worker = WorkerClient.new(host, port)

if worker.is_done(session[:ticket])
render :partial => “worker_done”
else
render :partial => “worker_not_done”
end
end

def work_done
results = worker.get_results(session[:ticket])
end

None of that will work out of the box, just kind of there to give you an
idea. WorkerClient would be a simple DRb client that you’d connect to a
DRb
server that receives work commands. DRb is ultra easy so don’t be
afraid.

In setup_work you get the worker to dowork and it returns a little
ticket
(probably just a simple integer ID) that you can use later to poll for
results.

You browser then uses some nifty ajax to hit the
ajaxy_worker_done_check.
All this action does is fire up a WorkerClient and ask the worker if the
job
with the given ticket is done yet. When it’s not you return the right
partial to keep the ajax going. If it is you return the partial that
makes
the ajax progress go to the work_done action.

At the work_done action you simply take the ticket and get the results.

There’s about a billion variants of this technique, but the idea is that
the
setup_work action gets out right away, the work is offloaded to another
server to do the waiting and crunching, and the results are collected
later.
This keeps your Rails nice and snappy.

But, the real benefit of this is that you can actually move all of
this
code out to a snazzy ultra fast Mongrel handler and not even use Rails.
You
might have to use rails in the setup_worker and most definitely in
work_done, but in the ajaxy_worker_done_check it would only be using DRb
so
no need to hook up rails. Only change you’d have to make is to pass the
ticket in via a Mongrel Handler’s request params rather than using the
session (which also makes this stateless).

Well, good luck.

Zed A. Shaw

http://mongrel.rubyforge.org/