Using a worker for a different purpose

Using a worker for a different purpose

[Iñaki Baz Castillo]

Hi, I'm thinking in using a worker (i.e: "worker.nr == 0") to accomplish a 
diferent task than binding in the Unicorn socket.

It would behave as a different process which binds in a different socket as 
daemon, so the other workers would notify it after processing data.

Of course I could have a separate process but why not using an Unicorn worker 
for this? in this way it's automatically reaped by master process if it 
crashes and I don't need to manage two different services.

Is is suitable? The main question is: how to tell a worker not to bind in the 
Unicorn configured socket(s)? is it possible?

Thanks a lot.

-- 
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Using a worker for a different purpose

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> Hi, I'm thinking in using a worker (i.e: "worker.nr == 0") to accomplish a 
> diferent task than binding in the Unicorn socket.
> 
> It would behave as a different process which binds in a different socket as 
> daemon, so the other workers would notify it after processing data.
> 
> Of course I could have a separate process but why not using an Unicorn worker 
> for this? in this way it's automatically reaped by master process if it 
> crashes and I don't need to manage two different services.
> 
> Is is suitable? The main question is: how to tell a worker not to bind in the 
> Unicorn configured socket(s)? is it possible?

Hi Iñaki,

You could _try_ something like:

  after_fork do |server, worker|
    if worker.nr == 0
      # new app
      server.app = Rack::Builder.new { ... }

      # clear the local listener set
      server.listeners = []

      # new listeners
      server.listen another_socket, socket_options
    end
  end

I make no guarantees that it'll work, though, and I'm hesitant
to support/encourage it even if it does.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Using a worker for a different purpose

[Iñaki Baz Castillo]

El Jueves, 7 de Enero de 2010, Eric Wong escribió:
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > Hi, I'm thinking in using a worker (i.e: "worker.nr == 0") to accomplish
> > a diferent task than binding in the Unicorn socket.
> >
> > It would behave as a different process which binds in a different socket
> > as daemon, so the other workers would notify it after processing data.
> >
> > Of course I could have a separate process but why not using an Unicorn
> > worker for this? in this way it's automatically reaped by master process
> > if it crashes and I don't need to manage two different services.
> >
> > Is is suitable? The main question is: how to tell a worker not to bind in
> > the Unicorn configured socket(s)? is it possible?
> 
> Hi Iñaki,
> 
> You could _try_ something like:
> 
>   after_fork do |server, worker|
>     if worker.nr == 0
>       # new app
>       server.app = Rack::Builder.new { ... }
> 
>       # clear the local listener set
>       server.listeners = []
> 
>       # new listeners
>       server.listen another_socket, socket_options
>     end
>   end
> 
> I make no guarantees that it'll work, though, and I'm hesitant
> to support/encourage it even if it does.

It seems interesting. Just a doubt: would it work with "preload_app true"?
I use preload_app since in case he config.ru is wrong then it raises in the 
master (instead of raising each worker and being reaped again and again).

Thanks, I'll try it. 


-- 
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Using a worker for a different purpose

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Jueves, 7 de Enero de 2010, Eric Wong escribió:
> > Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > > Hi, I'm thinking in using a worker (i.e: "worker.nr == 0") to accomplish
> > > a diferent task than binding in the Unicorn socket.
> > >
> > > It would behave as a different process which binds in a different socket
> > > as daemon, so the other workers would notify it after processing data.
> > >
> > > Of course I could have a separate process but why not using an Unicorn
> > > worker for this? in this way it's automatically reaped by master process
> > > if it crashes and I don't need to manage two different services.
> > >
> > > Is is suitable? The main question is: how to tell a worker not to bind in
> > > the Unicorn configured socket(s)? is it possible?
> > 
> > Hi Iñaki,
> > 
> > You could _try_ something like:
> > 
> >   after_fork do |server, worker|
> >     if worker.nr == 0
> >       # new app
> >       server.app = Rack::Builder.new { ... }
> > 
> >       # clear the local listener set
> >       server.listeners = []
> > 
> >       # new listeners
> >       server.listen another_socket, socket_options
> >     end
> >   end
> > 
> > I make no guarantees that it'll work, though, and I'm hesitant
> > to support/encourage it even if it does.
> 
> It seems interesting. Just a doubt: would it work with "preload_app true"?
> I use preload_app since in case he config.ru is wrong then it raises in the 
> master (instead of raising each worker and being reaped again and again).

It should work, but you won't be saving memory/spawning time with
"preload_app true" since you're replacing the app with a new one.

It's really dirty and smelly.  Processes are a great OS-level
abstraction to separate distinct services from each other.  IMHO it's
saner to just run another Unicorn instance.

Unicorn is not a VM, after all :)

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Using a worker for a different purpose

[Iñaki Baz Castillo]

El Jueves, 7 de Enero de 2010, Eric Wong escribió:

> > It seems interesting. Just a doubt: would it work with "preload_app
> > true"? I use preload_app since in case he config.ru is wrong then it
> > raises in the master (instead of raising each worker and being reaped
> > again and again).
> 
> It should work, but you won't be saving memory/spawning time with
> "preload_app true" since you're replacing the app with a new one.
> 
> It's really dirty and smelly.  Processes are a great OS-level
> abstraction to separate distinct services from each other.  IMHO it's
> saner to just run another Unicorn instance.
> 
> Unicorn is not a VM, after all :)

Yes, you are right. In fact the purpose of such worker would not be a Rack 
handler (http server) but a different one.
Humm, I think I'll keep it simple and run an external process :) 


-- 
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying