Forum: Ruby on Rails A nicer and gentler form of spawner

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Just S. (Guest)
on 2006-03-05 12:23
(Received via mailing list)
I was working on deploying an app with switchtower, and I really
dislike the way spawner is implemented. The way it will relaunch the
dispatcher all the time just to let it die if the port is in use is
too brute force for my taste.

As we're in a ruby script, why not let ruby find out if the port is in
use? Using the TCPServer class we can try and bing to the port. If we
succeed, it means the process died and we can launch the dispatcher.
But if an exception is raised, we can skip even trying to launch the
dispatcher.

Here's the change to the spawn method (and remember to add require
'socket' at the top):
def spawn(port)
  print "Checking if something is already running on port #{port}..."
  begin
    srv = TCPServer.new('0.0.0.0', port)
    srv.close
    srv = nil
    print "NO\n "
    print "Starting FCGI on port: #{port}\n  "
    system("#{OPTIONS[:spawner]} -f #{OPTIONS[:dispatcher]} -p #{port}")
  rescue
    print "YES\n"
  end
end

More details in my blog: http://devblog.famundo.com/

Bye,

Guy

Family management on rails: http://www.famundo.com - coming soon!
Norman T. (Guest)
on 2006-03-05 16:31
(Received via mailing list)
Am Sonntag, den 05.03.2006, 02:21 -0800 schrieb Just S.:
>
>     system("#{OPTIONS[:spawner]} -f #{OPTIONS[:dispatcher]} -p #{port}")
>   rescue
>     print "YES\n"
>   end
> end

I don't see the benefit. It is the same brute force as in the spawner
script,
with the only difference that the test is done inside the script. Why do
you
want to check if the port is in use if spawn-fcgi will do it anyway?

There is even a disadvantage: If you test with TCPServer.new and the
port is not in use, it may be in use at the point spawn-fcgi is trying
to bind it. Am i missing something?
--
Norman T.

http://blog.inlet-media.de
Just S. (Guest)
on 2006-03-05 16:53
(Received via mailing list)
It's a much lower effort resource wise. Launching another process (the
dispatcher is actually a call to another process), that then loads and
does a few things before even attempting to open the port, can't be
compared to openning a port in one single process.

On anything but a high load site this will be a non-issue anyway. But
when you have lots of FastCGI processes, and the computer is under
load already, the difference is big.

Another way to do that is to wait on each process to see if it
finished/died with Process.wait or one of the other similar functions.
But this complicates the spawner and I didn't see a reason after
lowering the effort enough.

Bye,

Guy.

On 3/5/06, Norman T. <removed_email_address@domain.invalid> wrote:
> > dispatcher.
> >     print "Starting FCGI on port: #{port}\n  "
> There is even a disadvantage: If you test with TCPServer.new and the
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


Family management on rails: http://www.famundo.com - coming soon!
Norman T. (Guest)
on 2006-03-05 17:26
(Received via mailing list)
Am Sonntag, den 05.03.2006, 06:52 -0800 schrieb Just S.:
> It's a much lower effort resource wise. Launching another process (the
> dispatcher is actually a call to another process), that then loads and
> does a few things before even attempting to open the port, can't be
> compared to openning a port in one single process.

> On anything but a high load site this will be a non-issue anyway. But
> when you have lots of FastCGI processes, and the computer is under
> load already, the difference is big.

You are right. I did some tests and found out that your adjustment is
about 2000-4000 times faster on my machine. Maybe you should submit a
patch and announce it on the core mailinglist.
--
Norman T.

http://blog.inlet-media.de
Andreas S. (Guest)
on 2006-03-05 17:51
Norman T. wrote:
> Am Sonntag, den 05.03.2006, 06:52 -0800 schrieb Just S.:
>> It's a much lower effort resource wise. Launching another process (the
>> dispatcher is actually a call to another process), that then loads and
>> does a few things before even attempting to open the port, can't be
>> compared to openning a port in one single process.
>
>> On anything but a high load site this will be a non-issue anyway. But
>> when you have lots of FastCGI processes, and the computer is under
>> load already, the difference is big.
>
> You are right. I did some tests and found out that your adjustment is
> about 2000-4000 times faster on my machine. Maybe you should submit a
> patch and announce it on the core mailinglist.

Yes, please do.
Just S. (Guest)
on 2006-03-05 19:00
(Received via mailing list)
I'll post a patch in trac.

On 3/5/06, Andreas S. <removed_email_address@domain.invalid> wrote:
> >
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Family management on rails: http://www.famundo.com - coming soon!
This topic is locked and can not be replied to.