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 at aliax.net>
I?aki Baz Castillo <ibc at 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
El Jueves, 7 de Enero de 2010, Eric Wong escribi?:> I?aki Baz Castillo <ibc at 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 at aliax.net>
I?aki Baz Castillo <ibc at aliax.net> wrote:> El Jueves, 7 de Enero de 2010, Eric Wong escribi?: > > I?aki Baz Castillo <ibc at 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
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 at aliax.net>