First of all, I''d like to do what I''ve seen several others here do: thank Ezra and any other contributors for producing a really great plugin. Even though I''m having some minor problems, this is all so approachable and easy to work with and dig into... I hate to think of the hoops you''d need to jump through (both as creator of such a system and as a user) to do something similar in Java. Now then... I''ve stumbled across the problem described here: http://rubyforge.org/pipermail/backgroundrb-devel/2006-August/000299.html wherein the native Ruby adaptor for Postgres causes Backgroundrb to crap out with messages like this: ActiveRecord::StatementInvalid: NoMethodError: undefined method `async_query'' for #<PGconn:0x22ed648>: The author''s suggested solutions were to either use the compiled ruby-postgres, or set ActiveRecord::Base.allow_concurrency to false in a start script. Well, the first option seems tricky to me; I haven''t succeeded in getting that compiled for Mac OS X yet (granted, I haven''t given it too much effort yet), so I figured I''d try the second option. I couldn''t find any start script where I could actually make that setting have any effect, and eventually I realized that it''s being set to true at worker_rails.rb:21. If I comment out that line, suddenly I''m back in business! What I wonder is if I''m setting myself up for future catastrophe with that change. I figure it''s got to be in there for *some* reason. I think I read somewhere that Backgroundrb changed from a multi-thread to a multi-process architecture not too long ago; Is that line, setting allow_concurrency to true, a holdover from the multi-threaded days that''s no longer needed? -- // jack // http://www.nuthole.com
Hi-
Yeah with the new multi process bdrb you probably need to set
allow_concurrency to false. I don''t think you will have a problem
with it like that. If you do run into a problem then you may have to
put a mutex around the calls to your database:
@mymutex = Mutex.new
@mymutex.synchronize {
# calls to database in here.
}
-Ezra
On Mar 5, 2007, at 2:13 PM, Jack Nutting wrote:
> First of all, I''d like to do what I''ve seen several
others here do:
> thank Ezra and any other contributors for producing a really great
> plugin. Even though I''m having some minor problems, this is all
so
> approachable and easy to work with and dig into... I hate to think of
> the hoops you''d need to jump through (both as creator of such a
system
> and as a user) to do something similar in Java.
>
> Now then... I''ve stumbled across the problem described here:
>
> http://rubyforge.org/pipermail/backgroundrb-devel/2006-August/
> 000299.html
>
> wherein the native Ruby adaptor for Postgres causes Backgroundrb to
> crap out with messages like this:
>
> ActiveRecord::StatementInvalid: NoMethodError: undefined method
> `async_query'' for #<PGconn:0x22ed648>:
>
> The author''s suggested solutions were to either use the compiled
> ruby-postgres, or set ActiveRecord::Base.allow_concurrency to false in
> a start script.
>
> Well, the first option seems tricky to me; I haven''t succeeded in
> getting that compiled for Mac OS X yet (granted, I haven''t given
it
> too much effort yet), so I figured I''d try the second option. I
> couldn''t find any start script where I could actually make that
> setting have any effect, and eventually I realized that it''s being
set
> to true at worker_rails.rb:21. If I comment out that line, suddenly
> I''m back in business!
>
> What I wonder is if I''m setting myself up for future catastrophe
with
> that change. I figure it''s got to be in there for *some* reason.
I
> think I read somewhere that Backgroundrb changed from a multi-thread
> to a multi-process architecture not too long ago; Is that line,
> setting allow_concurrency to true, a holdover from the multi-threaded
> days that''s no longer needed?
>
> --
> // jack
> // http://www.nuthole.com
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
Note that this is only for the postgres bindings afaik. Mysql is fine with allow concurrency = true -Ezra On Mar 5, 2007, at 2:57 PM, Ezra Zygmuntowicz wrote:> Hi- > > Yeah with the new multi process bdrb you probably need to set > allow_concurrency to false. I don''t think you will have a problem > with it like that. If you do run into a problem then you may have to > put a mutex around the calls to your database: > > @mymutex = Mutex.new > > @mymutex.synchronize { > # calls to database in here. > } > > > -Ezra > > On Mar 5, 2007, at 2:13 PM, Jack Nutting wrote: > >> First of all, I''d like to do what I''ve seen several others here do: >> thank Ezra and any other contributors for producing a really great >> plugin. Even though I''m having some minor problems, this is all so >> approachable and easy to work with and dig into... I hate to >> think of >> the hoops you''d need to jump through (both as creator of such a >> system >> and as a user) to do something similar in Java. >> >> Now then... I''ve stumbled across the problem described here: >> >> http://rubyforge.org/pipermail/backgroundrb-devel/2006-August/ >> 000299.html >> >> wherein the native Ruby adaptor for Postgres causes Backgroundrb to >> crap out with messages like this: >> >> ActiveRecord::StatementInvalid: NoMethodError: undefined method >> `async_query'' for #<PGconn:0x22ed648>: >> >> The author''s suggested solutions were to either use the compiled >> ruby-postgres, or set ActiveRecord::Base.allow_concurrency to >> false in >> a start script. >> >> Well, the first option seems tricky to me; I haven''t succeeded in >> getting that compiled for Mac OS X yet (granted, I haven''t given it >> too much effort yet), so I figured I''d try the second option. I >> couldn''t find any start script where I could actually make that >> setting have any effect, and eventually I realized that it''s being >> set >> to true at worker_rails.rb:21. If I comment out that line, suddenly >> I''m back in business! >> >> What I wonder is if I''m setting myself up for future catastrophe with >> that change. I figure it''s got to be in there for *some* reason. I >> think I read somewhere that Backgroundrb changed from a multi-thread >> to a multi-process architecture not too long ago; Is that line, >> setting allow_concurrency to true, a holdover from the multi-threaded >> days that''s no longer needed? >> >> -- >> // jack >> // http://www.nuthole.com >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > -- Ezra Zygmuntowicz > -- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273)
This is a new issue in Rails 1.2.x. If allow concurrency = true (in ActiveRecord) and you''re using the pure ruby postgres-pr driver, then you will get a NoMethodError when async_exec or async_query is called. I opened a ticket and submitted a patch for this: http://dev.rubyonrails.org/ticket/7727 And it looks like it has been fixed in the rails trunk, but not released yet. You could apply the same fix directly to your local rails install in the interim. Also be aware that the native postgres adapter has some issues on Mac OS X, particularly when used with backgroundrb. This is really a problem for Apple to fix. More details here: http://rubyforge.org/pipermail/backgroundrb-devel/2006-December/000594.html The net result is that on Mac OS X, you are best off using the postgres-pr driver if you are working with backgroundrb, but if you are also using Rails 1.2 -- you''ll need to apply the patch referenced above. best regards, Mason On 3/5/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:> > > Note that this is only for the postgres bindings afaik. Mysql is > fine with allow concurrency = true > > -Ezra > > > On Mar 5, 2007, at 2:57 PM, Ezra Zygmuntowicz wrote: > > > Hi- > > > > Yeah with the new multi process bdrb you probably need to set > > allow_concurrency to false. I don''t think you will have a problem > > with it like that. If you do run into a problem then you may have to > > put a mutex around the calls to your database: > > > > @mymutex = Mutex.new > > > > @mymutex.synchronize { > > # calls to database in here. > > } > > > > > > -Ezra > > > > On Mar 5, 2007, at 2:13 PM, Jack Nutting wrote: > > > >> First of all, I''d like to do what I''ve seen several others here do: > >> thank Ezra and any other contributors for producing a really great > >> plugin. Even though I''m having some minor problems, this is all so > >> approachable and easy to work with and dig into... I hate to > >> think of > >> the hoops you''d need to jump through (both as creator of such a > >> system > >> and as a user) to do something similar in Java. > >> > >> Now then... I''ve stumbled across the problem described here: > >> > >> http://rubyforge.org/pipermail/backgroundrb-devel/2006-August/ > >> 000299.html > >> > >> wherein the native Ruby adaptor for Postgres causes Backgroundrb to > >> crap out with messages like this: > >> > >> ActiveRecord::StatementInvalid: NoMethodError: undefined method > >> `async_query'' for #<PGconn:0x22ed648>: > >> > >> The author''s suggested solutions were to either use the compiled > >> ruby-postgres, or set ActiveRecord::Base.allow_concurrency to > >> false in > >> a start script. > >> > >> Well, the first option seems tricky to me; I haven''t succeeded in > >> getting that compiled for Mac OS X yet (granted, I haven''t given it > >> too much effort yet), so I figured I''d try the second option. I > >> couldn''t find any start script where I could actually make that > >> setting have any effect, and eventually I realized that it''s being > >> set > >> to true at worker_rails.rb:21. If I comment out that line, suddenly > >> I''m back in business! > >> > >> What I wonder is if I''m setting myself up for future catastrophe with > >> that change. I figure it''s got to be in there for *some* reason. I > >> think I read somewhere that Backgroundrb changed from a multi-thread > >> to a multi-process architecture not too long ago; Is that line, > >> setting allow_concurrency to true, a holdover from the multi-threaded > >> days that''s no longer needed? > >> > >> -- > >> // jack > >> // http://www.nuthole.com > >> _______________________________________________ > >> Backgroundrb-devel mailing list > >> Backgroundrb-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > -- Ezra Zygmuntowicz > > -- Lead Rails Evangelist > > -- ez at engineyard.com > > -- Engine Yard, Serious Rails Hosting > > -- (866) 518-YARD (9273) > > > > > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > -- Ezra Zygmuntowicz > -- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070307/976623e9/attachment-0001.html