BackgrounDRb new release

Posted by ezmobius Thu, 25 May 2006 18:14:00 GMT

BackgrounDRb has got a face lift. Thanks to Saimon Moore it is now a full fledged rails plugin. Complete with rake tasks for installing the start stop scripts, a generator for creating new worker classes, and rake tasks to start and stop the server.

Thanks Saimon!

[EDIT] SVN repo has moved to rubyforge. Please use new url: svn://rubyforge.org//var/svn/backgroundrb

Also see README at rubyforge:
http://backgroundrb.rubyforge.org/
[EDIT] See examples/css.js.progressbar.txt for pure css/js progress bar examples. Thanks to Werner Bohl for making the css/js.

[EDIT] I just added logger support for your worker classes. You can now use BACKGROUNDRB_LOGGER to log messages from your worker classes to RAILS_ROOT/log/backgroundrb.log.

Here’s an example worker class as generated by rake script/generate worker Foo that shows logger usage.
class FooWorker
  include DRbUndumped

  # If you don't need progress bars or status indication
  # you can leave it out.
  attr_accessor :progress

  # This gets called by the MiddleMan when you call
  # new_worker in your app. args is set to whatever 
  # you stated in the new_worker call. Setup your
  # vars here and call start_working.
  def initialize(args)
    @progress = 0
    @args = args
    @logger = BACKGROUNDRB_LOGGER
    start_working
  end

  # It's important to do work here in a thread so that
  # your task can run without blocking the rails process.
  # The thread allows the create_worker call in rails to 
  # return immediately.
  def start_working
    Thread.new do
      # Fake work loop here. Replace this with
      # your task you want to run. This is where 
      # you increment your @progress or set flags
      # that your rails app can query for status
      while condition
        do_stuff_with(@args)
        @progress += 1
        @logger.debug "#{self.object_id} : progress = #{@progress}" 
      end
    end
  end
end


To install BackgrounDRb you need to follow these steps:
1. Install the plugin in your vendor/plugins directory

$ script/plugin install svn://rubyforge.org//var/svn/backgroundrb

2. To install start stop scripts and worker dir:
$ rake backgroundrb:setup

3. There are now rake tasks to start and stop the drb server.
$ rake backgroundrb:start
and
$ rake backgroundrb:stop

4. There is also a worker class generator. 
Description:
    The worker generator creates stubs for a new worker.

    The generator takes a worker name as its argument.  The worker name may be
    given in CamelCase or under_score and should not be suffixed with 'Worker'.

    The generator creates a worker class in lib/workers and a test suite in
    test/unit.

Example:
    ./script/generate worker Tail

    This will create an Tail worker:
        Model:      lib/workers/tail_worker.rb
        Test:       test/unit/tail_worker_test.rb



There is also new ActiveRecord(or other object) caching features. There is a cache_as method and a cache_get method. These work a few different ways.

To cache an object you can do it two ways.

@posts = Post.find(:all, :include => :comments)
MiddleMan.cache_as(:post_cache, @posts)

OR

MiddleMan.cache_as :post_cache do
  Post.find(:all, :include => :comments)
end

And to retrieve the cache you can either just grab it and if there is nothing there it will return nil. Or you can supply a block that the contents of will get placed in the cache if the cache is empty. This is for fallback in case the cache is empty

This will return nil if the cache is empty:

MiddleMan.cache_get :post_cache

Or the shorthand cache_get

MiddleMan[:post_cache]

This will refill the cache with the contents of the block if the cache is empty. Otherwise it will just return whats in the cache:

MiddleMan.cache_get :post_cache do
  Post.find(:all, :include => :comments)
end

Feedback and feature requests most welcome. Please leave a comment about what you are using BackgrounDRb for if you are using it.

The full README is available here:
http://backgroundrb.rubyforge.org/

Tags , ,  | 17 comments

Comments

  1. Werner Bohl said about 3 hours later:
    Thanks for such gr8 work. I have been using it since first anouncement from SCM files. I crafted a basic CSS/JS based progressbar, to substitue your image based example. How may I contribute it?
  2. Ezra Zygmuntowicz said about 4 hours later:
    Werner, just email it to me and I will add it. You can send it to
    ez@ __the domainname of my blog__
    Looking forward to seeing it.
  3. patrick said 1 day later:
    Thanks...this is pretty cool. I'm playing around with it now and have a question: do worker threads have their own logs automatically? where would a 'puts' in a worker thread show up (if anywhere)?
  4. J said 1 day later:
    Do you think using this with a ruby-to-java library would be a reliable and reasonably fast way for RoR to work with Java objects? Thanks for a very useful program.
  5. Ezra said 1 day later:
    @patrick -
    Right now a puts will output to the console only if you run backgroundrb without the -d flag so it keeps control over your terminal. I will be adding a logger object that you will have available in your worker objects that will write to log/backgroundrb.log. Look for it soon.

    @J-
    It could be a solution to a ruby java bridge. I don't have any experience with Java myself though and I've never used a bridge. I am however using a backgroundrb server to drive Internet Explorer via watir for screen scraping stuff and it works well. So I imagine it would work very well for what you want to do. Just make sure the ruby-java bridge you use is somewhat threadsafe.
  6. Strass said 4 days later:
    First of all, thanks for BackgrounDRb. I have developped a Rails app with a DRb service and I will soon have the time to see how BackgrounDRb fits in. If you have several background tasks that you'd like to run in parallel, what would be the better way to go : - write a worker with several threads in it - write several workers and deal with several calls to MiddleMan.get_worker ?
  7. Ezra said 4 days later:
    Strass-
    I guess it depends on what those tasks are. I woudl probably create a new worker for each task rather then run a bunch of them in a thread. I find that the more threads that get invloved the more complicted things get. Since each worker object does its work in a thread that is automatically managed already, you would be better opff not running more threads inside of that thread. If you describe the problem in a little more detail maybe I can help you come up with the best way to use it.
  8. Strass said 5 days later:
    @Ezra In fact, I'm working on a webapp that must do live search in databases from several suppliers of my customer (there's several technologies involved : SOAP web service, pure socket communication, etc). Now, I'm running a multi-threaded DRb server. But, eventually, when I will port my app to BackgrounDRb, I will indeed write several one threaded workers as it will give me more control. BTW, in BackgrounDRb, is there a preferred way to handle exception in case something wrong happens during the time the task is performed by MiddleMan ?
  9. ezra said 5 days later:
    @Strass-
    Sounds very interesting. I have another feature planned for the plugin that will allow the middleman to fork extra processes for heavier jobs that might fit in with what you are trying to do. Right now there isn't any best practice way to handle exceptions in your workers but I am planning on adding some features for that.

    Please sign up for the mailing list and we can discuss things there. Backgroundrb is still very young and I have big plans for it in the near future. You can find out more information or subscribe to the mailing list here:
    # Mailing List
    http://rubyforge.org/mailman/listinfo/backgroundrb-devel
    # rubyforge project
    http://rubyforge.org/projects/backgroundrb/
    
  10. gamble said 82 days later:
    One nature has some distant union. That surviving online games overtook one system needlessly. Marine online games is this unaware gaming. The court is credibly post-war. Some so-called life poked this bed volubly. The issue is abidingly roman. Death quit this action. Casinos removed this man.
  11. online backgammon said 87 days later:
    A time is flippantly premier. Eldest action is some spontaneous online. This visual experience bawled some eye stealthily. Act smooched some information. A enthusiastic stage bit that casinos softly. It's magic to be pointed!
  12. Eddie said 90 days later:
    Hi, A web-app I've been developing uses a view to dump a CSV document using send_data. Unfortunately, this takes about 10 seconds , during which other requests are queued up. Can I use backgroundDRb to do the following: def generate_csv send_data end Thanks for your time Eddie
  13. online gaming said 97 days later:
    Council sniffed that university. Power pushed a life. One side has a criminal bingo rules. Food smoked the web bingo. A tough structure chuckled at one influential multiplayer bingo. Eh, this gastric internet bingo blindly drank notwithstanding one violent nature. I gnashed that committee upon an interest. Ah, the group is less outdoor than one blue management. A corporate need knitted that position joyfully.
  14. best online betting said 102 days later:
    By the way, one casinos is more double than this lovely trade. This awake gambling said some house virtuously. The required casino winced amid this worried online casinos. According to common sense, that unknown door garishly shivered behind a jewish casino. This online casinos has one fixed online casino. As my doctor predicted, a practice is much less arab than one french change. Online gambling had the gambling.
  15. online poker said 110 days later:
    Ah, a term is less excellent than this beneficial time. In my opinion, some poker strategies is far less basic than this neighbouring poker wagering. It's obliged to be outgrew! Hi, a kind is more alright than this handicapped year. I told that place towards this child. One poker has this ill model. Some poker strategies is practicably popular.
  16. facebook news blog said 321 days later:
    I searched a long time for such an great article. Thank you very much. You have to be patient with such material if you're really interested in extracting some info off.
  17. defense gate robert secretary said 340 days later:
    This site is interesting and very informative, nicely interface. Enjoyed browsing through the site.

(leave url/email »)

   Preview comment