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

hemant gethemant at gmail.com
Sat Sep 20 02:18:41 EDT 2008

Mitchel, can you send me tar.gz file of your app, which is sufficient
to reproduce mentioned behaviour?
I mean, don't send me entire app (if it contains confidential info),
just enough of code, so as I can reproduce this. Also, in the
meanwhile, you can try git version and see if it fixes this.

On Sat, Sep 20, 2008 at 10:55 AM, Mitchell Curtis Hatter
<curtis.hatter at insightbb.com> wrote:
> 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.

Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.


More information about the Backgroundrb-devel mailing list