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

hemant kumar gethemant at gmail.com
Sat Sep 20 00:36:44 EDT 2008


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