[Backgroundrb-devel] pre-release version of backgroundrb available now from svn

hemant gethemant at gmail.com
Sun Nov 4 15:49:56 EST 2007


On 11/5/07, Brendan Grainger <brendan.grainger at gmail.com> wrote:
>  Hi Hemant,
>
> The new API looks great, but I'm having a couple of problems I wonder if you
> know about.
>
> * The first is that there seems to be a missing guid.rb file in the
> repository? In packet.rb there is:
>
>
> require 'guid'

Yes it depends on uuid gem, which can be downloaded from:

http://rubyforge.org/projects/uuid/

>
> I created my own guid.rb and added a hexdigest method which seemed to fix
> the problem.

Yes that would solve the problem.
>
> * The second is when I start and stop backgroundrb it prints out:
>
>
> Loaded suite script/backgroundrb
> Started
>
> Finished in 0.00025 seconds.
>
> 0 tests, 0 assertions, 0 failures, 0 errors
>

Weird, I will have a look into this. If your app is not too critical,
you can zip entire code and send me. I will surely look into this.


> It looks like it's loading the test suite somehow, but I'm confused about
> how.
>
> * Finally I always get a nice little stack trace when I call backgroundrb
> stop
>
> $
> /Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/nbio.rb:12:in
> `read_data': Packet::DisconnectError (Packet::DisconnectError)
>         from
> /Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/worker.rb:43:in
> `handle_internal_messages'
>         from
> /Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/core.rb:131:in
> `start_reactor'
>         from
> /Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/core.rb:129:in
> `each'
>         from
> /Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/core.rb:129:in
> `start_reactor'
>

He he, Don't bother about these stacktraces. I will have to install
some signal handlers, and they will be gone. Since, those were not top
priority, I left it.

Also, I am pushing some changes, which will fix some issues with
timers. Please sync to latest code.

> Thanks!
> Brendan
>
>
> On Nov 2, 2007, at 6:05 AM, hemant wrote:
>
> Hi,
>
> A pre-release version of backgroundrb is available now from svn.
> Download it from here:
>
> http://svn.devjavu.com/backgroundrb/branches/version099/
>
> Since this release marks significant migration from existing
> practices, i intend to keep trunk untouched for a while.
>
> There are no install scripts, but you should copy "backgroundrb" file
> from script directory of plugin to script directory of rails. You
> should also config "backgroundrb.yml" file from config directory of
> plugin to config directory of rails root.
>
> There is one sample worker available in
> BACKGROUNDRB_ROOT/sample_worker directory.
> There is also a sample client available.
>
> Currently, passing of ActiveRecord objects is not supported. Although,
> We can do that, but in most situations, passing 'id' of object is
> enough i thought. Also, you may encounter some bugs when you are
> passing large objects around.
>
> I will try to explain meat of a sample worker:
>
> class FooWorker < MetaWorker
>   set_worker_name :foo_worker
>   attr_accessor :count
>   def worker_init
>     puts "Starting Foo Worker"
>     add_periodic_timer(4) { increment_status}
>   end
>   def process_request p_data
>     p p_data
>   end
>
>   def increment_status
>     @count ||= 0
>     @count += 1
>     register_status(@count)
>   end
> end
>
> First, I intend to wrap MetaWorker within a namespace(read module), so
> pardon me there.
>
> So, when backgroundrb starts it reads all the workers in
> WORKER_ROOT(which should be RAILS_ROOT/lib/workers) directory and
> worker_init is called in child process of each worker. You can use
> worker_init for initializing a worker.
>
> "process_request" is the method which will be normally invoked when
> you receive requests from rails. But there is a exception, in each
> worker there is a method called "register_status" available, which can
> be invoked from workers to register their status with master.
>
> Now, from rails, you can query status of a worker using
>
> MiddleMan.ask_status(:worker => :foo_worker)
>
> All the status requests are server by master itself and hence
> "process_request" inside worker will not be invoked for them.
>
> You will find support for schedules very rough around the edges.
> Reason is, You can use
>
> add_periodic_timer(5) { foo_job }
>
> to do any kind of scheduling. add_periodic_timer takes number of
> seconds as argument.
> for one shot timers, you can use:
>
> add_timer(5) { foo_job }
>
>
> Core of new version of bdrb is implemented on a networking library
> called "packet".  It needs its own introduction. But now, inside each
> worker you can start evented network connections. You have some
> methods like:
>
> connect("localhost",5678,FooHandler)
> start_server("localhost"m,5678,FooServer)
>
> inside each worker, which can be used to let workers do fancy stuff.
> This is just a by product of using "packet" library.
>
> I know, thing is rough around the edge and needs more polish. But
> still, i hope it will be more stable than previous versions of
> backgroundrb.
>
> Please report all the bugs here.
>
> Thanks
>
> --
> Let them talk of their oriental summer climes of everlasting
> conservatories; give me the privilege of making my own summer with my
> own coals.
>
> http://gnufied.org
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>


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

http://gnufied.org


More information about the Backgroundrb-devel mailing list