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

[Mitchell Curtis Hatter]

I'm actually losing the call to the async_* method.

Anytime I first create a new worker I lose any async_* calls to it for  
approximately 10 to 15 seconds.

I even tried this:

     MiddleMan.new_worker(:worker => :texis_worker, :worker_key =>  
worker_key.to_s)
     sleep(5)
     MiddleMan.worker(:texis_worker,  
worker_key.to_s).async_search(:arg => {:book => self, :search_params  
=> search_params}, :job_key => job_key)

And got nothing. After the worker creates it's fine. But I tried just  
one call and waited about 30 seconds, got nothing, then made another  
call and got results right away.

Again, when I do it from script/console it never fails.

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.
>
>
>
>
>