Hi all, Both the rails book (1st Ed) and the docs on the rails site (*and* the Mongrel FAQ) tell me that rails (& ActionPack /ActiveRecord) is not threadsafe. Since I need lots of worker threads in the app I''m working on (details at the end of this mail) this poses quite a problem for me. Is the lack of thread safety a conscious design decision (kind of understandable for rails as such, but IMHO strange for ActiveRecord) or just something nobody has found the time to take care of yet? Is there any documentation on what exactly lacks thread safety? From http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads I got the impression that it''s mainly a lack of connection pooling in ActiveRecord, which (in theory) shouldn''t be too difficult to fix.. Some details on my project: It''s a tool taking care of (in the future) most of the administrative work at http://dotsrc.org/ -- setting up mirrors, handling their automatic updates, setting up hosted projects, adding / modifying users etc. The "down to the metal" functionality is done in a distributed daemon (one instance per server, one of them a designated "master" containing stuff like an internal cron and channeling all requests from the frontend). The frontend is basically a normal rails application. Since both of these parts share a large part of the code (e.g. the complete database model), I''m implementing them as "2-in-1" rails app, i.e. same lib/, app/models, etc, but different app/(frontend|backend)/(controller,view,helper) and different startup scripts. Works fine so far, and allows me to make good use of rails (like using it (with ActionWebService) also for the frontend <-> backend communication). I''m porting the app from a custom-baked framework over to rails. -- Christian Reiniger ...10001000110101011010101101011110111010113...???? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060530/222cf3ed/attachment.bin
On 30/05/06, Christian Reiniger <creinig@dotsrc.org> wrote:> Hi all, > > Both the rails book (1st Ed) and the docs on the rails site (*and* the > Mongrel FAQ) tell me that rails (& ActionPack /ActiveRecord) is not > threadsafe. Since I need lots of worker threads in the app I''m working on > (details at the end of this mail) this poses quite a problem for me. > > Is the lack of thread safety a conscious design decision (kind of > understandable for rails as such, but IMHO strange for ActiveRecord) or > just something nobody has found the time to take care of yet? Is there > any documentation on what exactly lacks thread safety? From > http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads I got the > impression that it''s mainly a lack of connection pooling in ActiveRecord, > which (in theory) shouldn''t be too difficult to fix..Zed posted on this subject recently on the mongrel-users list: http://rubyforge.org/pipermail/mongrel-users/2006-May/000302.html
On Tuesday 30 May 2006 15:42, Paul Wright wrote:> On 30/05/06, Christian Reiniger <creinig@dotsrc.org> wrote: > > Hi all, > > > > Both the rails book (1st Ed) and the docs on the rails site (*and* > > the Mongrel FAQ) tell me that rails (& ActionPack /ActiveRecord) is > > not threadsafe. Since I need lots of worker threads in the app I''m > > working on (details at the end of this mail) this poses quite a > > problem for me. > > > > Is the lack of thread safety a conscious design decision (kind of > > understandable for rails as such, but IMHO strange for ActiveRecord) > > or just something nobody has found the time to take care of yet? Is > > there any documentation on what exactly lacks thread safety? From > > http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads I got the > > impression that it''s mainly a lack of connection pooling in > > ActiveRecord, which (in theory) shouldn''t be too difficult to fix.. > > Zed posted on this subject recently on the mongrel-users list: > > http://rubyforge.org/pipermail/mongrel-users/2006-May/000302.htmlHmm, ok. If there''s really a fix for ActiveRecord already, that would solve most of my problems (my worker threads don''t need controller/view magic). Thanks. -- Christian Reiniger ...10001000110101011010101101011110111010113...???? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060530/0faa9735/attachment.bin
On May 30, 2006, at 8:04 AM, Christian Reiniger wrote:> On Tuesday 30 May 2006 15:42, Paul Wright wrote: >> On 30/05/06, Christian Reiniger <creinig@dotsrc.org> wrote: >>> Hi all, >>> >>> Both the rails book (1st Ed) and the docs on the rails site (*and* >>> the Mongrel FAQ) tell me that rails (& ActionPack /ActiveRecord) is >>> not threadsafe. Since I need lots of worker threads in the app I''m >>> working on (details at the end of this mail) this poses quite a >>> problem for me. >>> >>> Is the lack of thread safety a conscious design decision (kind of >>> understandable for rails as such, but IMHO strange for ActiveRecord) >>> or just something nobody has found the time to take care of yet? Is >>> there any documentation on what exactly lacks thread safety? From >>> http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads I got >>> the >>> impression that it''s mainly a lack of connection pooling in >>> ActiveRecord, which (in theory) shouldn''t be too difficult to fix.. >> >> Zed posted on this subject recently on the mongrel-users list: >> >> http://rubyforge.org/pipermail/mongrel-users/2006-May/000302.html > > Hmm, ok. If there''s really a fix for ActiveRecord already, that would > solve most of my problems (my worker threads don''t need controller/ > view > magic). Thanks. > > -- > Christian Reiniger > > ...10001000110101011010101101011110111010113...????Christian- You also might want to take a look at my BackgrounDRb plugin. it is written for exactly this kind of managed background task work and has hooks for ajax progress bars for showing status or progress in the browser while the worker tasks run in a separate daemon. I am using it for sysadmin stuff very similar to what you describe. You can find out more information or subscribe to the mailing list here: # Mailing List http://rubyforge.org/mailman/listinfo/backgroundrb-devel # rubyforge project http://rubyforge.org/projects/backgroundrb/ # README http://backgroundrb.rubyforge.org # Blog http://brainspl.at Cheers- -Ezra
Paul Wright wrote:> On 30/05/06, Christian Reiniger <creinig@dotsrc.org> wrote: >> Hi all, >> >> Both the rails book (1st Ed) and the docs on the rails site (*and* the >> Mongrel FAQ) tell me that rails (& ActionPack /ActiveRecord) is not >> threadsafe. Since I need lots of worker threads in the app I''m working on >> (details at the end of this mail) this poses quite a problem for me. >> >> Is the lack of thread safety a conscious design decision (kind of >> understandable for rails as such, but IMHO strange for ActiveRecord) or >> just something nobody has found the time to take care of yet? Is there >> any documentation on what exactly lacks thread safety? From >> http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads I got the >> impression that it''s mainly a lack of connection pooling in ActiveRecord, >> which (in theory) shouldn''t be too difficult to fix.. > > Zed posted on this subject recently on the mongrel-users list: > > http://rubyforge.org/pipermail/mongrel-users/2006-May/000302.htmlPaul, and Zed, thank you so much. I''ve been interested in the answer to this for the best part of a year, and there has never been a proper explanation on the Rails list. From what Zed wrote, this comment in action_controller/base.rb: # Controls whether the application is thread-safe, so multi-threaded servers like WEBrick know whether to apply a mutex # around the performance of each action. Action Pack and Active Record are by default thread-safe, but many applications # may not be. Turned off by default. @@allow_concurrency = false cattr_accessor :allow_concurrency should be taken with a large pinch of salt (or something stronger) :-) regards Justin