# BackgrounDRb 1.0.4 release **URL:** \ **Category:** Ruby\ **Created:** [July 13, 2008, 5:10pm UTC](https://www.ruby-forum.com/t/backgroundrb-1-0-4-release/142928 "2008-07-13T17:10:09Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![gnufied](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/ea666f/32.png) [@gnufied](https://www.ruby-forum.com/u/gnufied)\ **Post date:** [July 13, 2008, 5:10pm UTC](https://www.ruby-forum.com/t/backgroundrb-1-0-4-release/142928/1 "2008-07-13T17:10:09Z")
Hi, I am proud to release BackgrounDRb 1.0.4. This release contains, many fixes as listed below: Folks, as you are probably aware that I am working on getting cluster/distributed job handling support for BackgrounDRb. I am trying to make a brief overview of changes that I have currently checked into testcase branch of github. 1. Both synchronous and asychronous task invocation API has changed for accomadating clustering of BackgrounDRb servers. New API is: # for synchronous tasks: # invoke method some\_task in worker hello\_worker MiddleMan.worker(:hello\_worker).some\_task() # invoke method some\_task passing ‘data’ as an argument to method and use # session[:user\_id] as job\_key MiddleMan.worker(:hello\_worker).some\_task(:arg =\> data,:job\_key =\> session[:user\_id]) # run method ‘some\_task’ on all backgroundrb servers MiddleMan.worker(:hello\_worker).some\_task(:arg =\> data,:job\_key =\> session[:user\_id],:host =\> :all) # run method ‘some\_task’ on only locally configured server MiddleMan.worker(:hello\_worker).some\_task(:arg =\> data,:job\_key =\> session[:user\_id],:host =\> :local) # if you are using a bdrb cluster and now specifying :host option, your job will run on a # server selected in round-robin manner MiddleMan.worker(:hello\_worker).some\_task(:arg =\> data,:job\_key =\> session[:user\_id]) # run the task on specified server and return the results back MiddleMan.worker(:hello\_worker).some\_task(:arg =\> data,:job\_key =\> session[:user\_id],:host =\> “10.0.0.2:11210”) # For asychronous tasks: # invoke method some\_task in worker hello\_worker MiddleMan.worker(:hello\_worker).async\_some\_task() # invoke method some\_task passing ‘data’ as an argument to method and use # session[:user\_id] as job\_key MiddleMan.worker(:hello\_worker).async\_some\_task(:arg =\> data,:job\_key =\> session[:user\_id]) # run method ‘some\_task’ on all backgroundrb servers MiddleMan.worker(:hello\_worker).async\_some\_task(:arg =\> data, :job\_key =\> session[:user\_id],:host =\> :all) # run method ‘some\_task’ on only locally configured server MiddleMan.worker(:hello\_worker).async\_some\_task(:arg =\> data, :job\_key =\> session[:user\_id],:host =\> :local) # if you are using a bdrb cluster and now specifying :host option, your job will run on # server selected MiddleMan.worker(:hello\_worker).async\_some\_task(:arg =\> data,:job\_key =\> session[:user\_id],:host =\> “10.0.0.2:11210”) 1. Worker\_key and job\_key: BackgrounDRb prior to this version used job\_key as worker global data and workers started new were using ‘job\_key’. This naming convention was somewhat confusing and hence has been changed. 2. New thread pool: Following syntax of adding tasks to thread pool has been deprecated: thread\_pool.defer(args) do |arg| # runs in new thread end New syntax is: thread\_pool.defer(:some\_method,args) 3. Persistent job Queue: BackgrounDRb now have out of box support for persistent job queues which are persisted to the database. API to add a task in the job\_queue is pretty simple: 4. Log worker no longer has rails environment. 5. Result Caching and retrieval: Each worker has a worker local ‘cache’ object, which can be used to cache results for later retrieval. You can use memcach as result storage, you just need to specify that in config file. 6. Clustering and Fail safe: If a node in cluster goes down, bdrb will automatically remove that node from participation in load balancing, but once that node comes up, bdrb will automatically add it back and node will start running tasks. 7. Fixes for large size data transfer. URLS: [http://backgroundrb.rubyforge.org/](http://backgroundrb.rubyforge.org/) Credits: Ezra for letting me work on BackgrounDRb. Francis for EventMachine. – 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](http://gnufied.org) ---
**Author:** ![gnufied](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/ea666f/32.png) [@gnufied](https://www.ruby-forum.com/u/gnufied)\ **Post date:** [July 13, 2008, 5:11pm UTC](https://www.ruby-forum.com/t/backgroundrb-1-0-4-release/142928/2 "2008-07-13T17:11:55Z")
On Sun, Jul 13, 2008 at 8:39 PM, hemant [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Hi, > I am trying to make a brief overview of changes that I have currently > checked into testcase > branch of github. Ignore this part, all these changes are available in master and svn repository as well. Thanks. ---
**Author:** ![gnufied](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/ea666f/32.png) [@gnufied](https://www.ruby-forum.com/u/gnufied)\ **Post date:** [July 13, 2008, 5:17pm UTC](https://www.ruby-forum.com/t/backgroundrb-1-0-4-release/142928/3 "2008-07-13T17:17:10Z")
hemant wrote: > Ignore this part, all these changes are available in master and svn > repository as well. What can BackgrounDRb do that Spawn can’t do? One is out-of-process and the other in-process. Would a server like Mongrel hang up on a Spawn? ---
**Author:** ![gnufied](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/ea666f/32.png) [@gnufied](https://www.ruby-forum.com/u/gnufied)\ **Post date:** [July 13, 2008, 7:01pm UTC](https://www.ruby-forum.com/t/backgroundrb-1-0-4-release/142928/4 "2008-07-13T19:01:59Z")
On Sun, Jul 13, 2008 at 8:46 PM, Phlip [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Would a server like Mongrel hang up on a Spawn? > I do not think it will hang up on moderate load, but can create > problems when you are offloading lots of tasks to a thread running > inside mongrel. Also, there is no way to check, what happened to the > task. Thats from a very brief glance at Spawn.