[Backgroundrb-devel] Worker's not created quick enough?

Mitchell Curtis Hatter curtis.hatter at insightbb.com
Sat Sep 20 02:27:21 EDT 2008

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.


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.

More information about the Backgroundrb-devel mailing list