Found this: http://gnufied.org/2008/02/12/backgroundrb-best-practises/
Which you wrote of course. Point #2 seems to have solved my problem. I
removed where I was passing the entire Book AR object and just passed
the Book's id and things start working as expected within the full
Rails environment.
Any chance a "best practices" could be added somewhere to the
backgroundrb.rubyforge.org site and have those comments added.
If I have any more problems with this I'll post to this thread again
but for now seems to be working.
Thanks,
Curtis
On Sep 20, 2008, at 12:36 AM, hemant kumar wrote:
On Fri, 2008-09-19 at 23:58 -0400, Brent Collier wrote:
Yeah, you pretty much have to throw a sleep call in between creating
the worker and actually asking it to do work. It only takes a
fraction of a second. I was told this was only a problem on OS X,
but
I've also witnessed it on Gentoo. I see this question on the mailing
list enough that I think it might as well be included in the docs
somewhere.
First what exactly is async_xxx "failed"? As far as my thinking goes,
since in a worker, usually full rails environment is loaded, it is
naturally a bit slow to start, but any sync/async task execution
should
not get "lost" between the time worker is loading the rails
environment.
For example, on my ubuntu box, with packet-0.1.13 and bdrb from git:
require File.join(File.dirname(__FILE__) + "/../config/environment")
a = MiddleMan.new_worker(:worker => :wow_worker,:worker_key =>
"hello_world")
10.times do |i|
MiddleMan.worker(:wow_worker,"hello_world").async_run_crap(:arg =>
"hello world : #{i}")
end
I won't loose any of the "async_run_crap" calls, even though there
is no
"sleep" between starting a worker and asking it to execute a method.
Sure, worker may take time, to be fully ready, but by that time, tasks
should be "queued" up and thats what happens in Linux and behaviour is
correct.
On OSX though, you will loose async_xxx calls and hence its a bug.So,
mitchell, are you loosing async_xxx method calls? Or it gets invoked
eventually but slightly delayed (while its loading rails env)? If a
method call is lost, its a bug, I will need to fix it.
On OSX, ruby nonblocking APIs aren't working well and hence tasks
aren't
getting enqueued in socket buffer too and hence we are loosing
messages.
But this works, quite well in Linux, in my experience.
_______________________________________________
Backgroundrb-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/backgroundrb-devel
