Backgroundrb devel - Dec 2007 - Updates and Fixes and more of awesome stuff

1. Whenever you ask BackgrounDRb to perform a particular task using:

       MiddleMan.ask_work(:worker => :rss_worker,:worker_method =>
:fetch_url, :data => "www.google.com")

Your task would be performed then and there. But, if your worker is
busy, task won''t be queued, except in socket buffer.

And your request may get lost. This isn''t generally a problem with
tasks that is being scheduled through scheduler, but problem
happens when you are pusing lots of tasks to worker and you don''t want
them to run concurrently since that may hog CPU resources.
You would rather want tasks to be queued and be processed one after
another easily. The simple solution for such tasks is to set
thread pool size for worker to 1 and use thread_pool.defer { do_something }

      class RssWorker < BackgrounDRb::MetaWorker
        set_worker_name :rss_worker
        pool_size(1)
      end

Now no matter how many requests you send to the worker, they all will
be queued in a thread pool, but since thread pool is of size 1,
only one of the task would run at a time. You don''t have to worry with
thread issues, because only one thread will at a time anyways.

2. I have a method called MiddleMan.worker_info, which can be used like this:
>> MiddleMan.worker_info(:worker => :rss_worker)
=> {:status=>:running, :worker=>:rss_worker, :job_key=>nil}

You can pass some job_key also to check whether a worker is running or
not. If a worker is not running, :status value will be :stopped.

3. Removed all modifications to core classes. BackgrounDRb no longer
messes with any of the core classes. Poor thing has everything in its
own namespace. :)
It will fix any issues with ActiveSupport and other such libraries.


Give it a spin and we can release it as 1.0.1 version.

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