So I added Kernel#daemonize yesterday thinking that I was going to summon one for a book store application I''ve been getting real with, but it did not go too well. Basically, as soon as I daemonize, I loose the right to rely on auto-class instantiation and the database connection is fuxored. Could anyone have a look at this? It''d be real swell if it was easy to make daemons in Rails. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
David Heinemeier Hansson wrote:> So I added Kernel#daemonize yesterday thinking that I was going to > summon one for a book store application I''ve been getting real with, > but it did not go too well. Basically, as soon as I daemonize, I loose > the right to rely on auto-class instantiation and the database > connection is fuxored. > > Could anyone have a look at this? It''d be real swell if it was easy to > make daemons in Rails.I''ve used a similar code for daemonized refreshers on http://suprglu.com, and once more for sending out background emails. True these where all hackish in a certain way: I''ve loaded the classes before forking, by setting a in a central model class before any db calls are made. Also the RAILS_ROOT will be useless after you''ve chdir()-ed to root. Zsombor -- Company - http://primalgrasp.com Thoughts - http://deezsombor.blogspot.com
> True these where all hackish in a certain way: I''ve loaded the classes > before forking, by setting a in a central model class before any db calls > are made. Also the RAILS_ROOT will be useless after you''ve chdir()-ed to > root.Verdammt. Is there no way to make a daemon without doing all this evil? And if not, we should create something like ActiveDaemon that''ll set it all up for someone in a predictable way. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
David Heinemeier Hansson wrote:>> True these where all hackish in a certain way: I''ve loaded the classes >> before forking, by setting a in a central model class before any db calls >> are made. Also the RAILS_ROOT will be useless after you''ve chdir()-ed to >> root. > > Verdammt. Is there no way to make a daemon without doing all this > evil? And if not, we should create something like ActiveDaemon that''ll > set it all up for someone in a predictable way.Cant we just reset RAILS_ROOT to be an absolute path? This way paths will be still valid after chdir(). Bit late for me here for such experiments but will try it tomorrow. Zsombor -- Company - http://primalgrasp.com Thoughts - http://deezsombor.blogspot.com
> Cant we just reset RAILS_ROOT to be an absolute path? This way paths will > be still valid after chdir(). Bit late for me here for such experiments > but will try it tomorrow.Please do give it a shot. It''d be great to have a no-brain easy way of getting daemons running with Rails. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
I''ve set the RAILS_ROOT to absolute path inside boot.rb, for older apps this needs to be done manually replacing RAILS_ROOT = root_path with RAILS_ROOT = File.expand_path(root_path) And class auto loading will work after chdir() too. I''ve submited this in ticket #4045. As for mysql: new database connection is needed after forking. My refresher.rb now looks: Kernel.daemonize ActiveRecord::Base.establish_connection The second line can be avoided if no AR class was encountered till that point. But it cant hurt to write it down anyway. Does this qualify for a no-brain solution? Or should it be more creative, letting AR reconnect automatically once after fork? I think this could be perhaps too much magic. Mysql handles are just one kind of resources that cannot be shared. Zsombor -- Company - http://primalgrasp.com Thoughts - http://deezsombor.blogspot.com
> The second line can be avoided if no AR class was encountered till that > point. But it cant hurt to write it down anyway. Does this qualify for a > no-brain solution?Not entirely.> Or should it be more creative, letting AR reconnect automatically once > after fork? I think this could be perhaps too much magic. Mysql handles > are just one kind of resources that cannot be shared.We already do magic for threads. Actually, a lot of magic. Some magic to make it work with forks wouldn''t be bad. BTW, we can''t just force RAILS_ROOT to expand_path as that as issues on some shared host servers with links and what not. But what we can do is look for this constant in Kernel.daemonize, if it exists, rewrite it to expand. And then just have a caveat on top of daemonize that it won''t work in if expand_path won''t work. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
On Wed, Mar 01, 2006 at 10:37:01AM -0600, David Heinemeier Hansson wrote:> So I added Kernel#daemonize yesterday thinking that I was going to > summon one for a book store application I''ve been getting real with, > but it did not go too well. Basically, as soon as I daemonize, I loose > the right to rely on auto-class instantiation and the database > connection is fuxored. > > Could anyone have a look at this? It''d be real swell if it was easy to > make daemons in Rails. > -- > David Heinemeier Hansson > http://www.loudthinking.com -- Broadcasting Brain > http://www.basecamphq.com -- Online project management > http://www.backpackit.com -- Personal information manager > http://www.rubyonrails.com -- Web-application framework > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-coreWe''ve moved to creating drb instances which mirror our AWS api. These run well under a supervisor such as launchd, runit, daemontools, etc. All of our rails application instances (fastcgi listeners) are able to communicate through this for synchronization of, in our case, managed queues. I played with starting the Drb instance along with one of the fastcgi listeners, but too many issues came around to lead us to feel the separate and self-contained drb instance was a better solution in our case. -- TJ Vanderpoel GCIA,GCIH tj@rapidreporting.com _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core