BackgrounDRb release 1.0 available now

Hi Folks,

I am glad to announce 1.0 release of BackgrounDRb.

This would be a major release since 0.2 release of BackgrounDRb.

Here is a brief summary of changes:

- BackgrounDRb is DRb no longer. It makes use of EventDriven network   programming library packet ( http://packet.googlecode.com ).

- Since we moved to packet, many nasty thread issues, result hash   corruption issues are totally gone. Lots of work has went in   making scheduler rock solid stable.

- Each worker, still runs in its own process, but each worker has a   event loop of its own and all the events are triggered by the internal   reactor loop. In a nutshell, you are not encouraged to use threads   in your workers now. All the workers are already concurrent, but you   are encouraged to use co-operative multitasking, rather than   pre-emptive. A simple example is,

  For implement something like progress bar in old version of bdrb, you would:     - start your processing a thread (so as your worker can receive       further request from rails ) and have a instance       variable ( protected by mutex ) which is updated on progress and       can be send to rails.

    - With new backgroundrb, progress bar would be:       process your damn request and just use register_status() to       register status of your worker. Just because       you are doing some processing won't mean that your worker will       block. It can still receive requests from rails.

- Now, you can schedule multiple methods with their own triggers.

   > :schedules:    > :foo_worker:    > :foobar:    > :trigger_args: */5 * * * * * *    > :data: Hello World    > :barbar:    > :trigger_args: */10 * * * * * *

- Inside each worker, you can start tcp server or connect to a   external server. Two important methods available in all workers are:

  start_server("localhost",port,ModuleName)   connect("localhost",port,ModuleName)

  Connected client or outgoing connection would be integrated with   Event Loop and you can process requests from these guys   asynchronously. This mouse trap can allow you to build truly   distributed workers across your network.

- Each worker comes with a "thread_pool" object, which can be used   to run tasks concurrently. For example:

    thread_pool.defer(url) { |url| scrap_wiki_content(url) }

- Each worker has access to method "register_status" which can be   used to update status of worker or store results. Results of a worker   can be retrieved even after a worker has died.

  By default the results would be saved in master process memory, but   you can configure BackgrounDRb to store these results in a memcache   server or a cluster using following option in configuration file:

      # backgroundrb.yml

      > :backgroundrb:       > :port: 11006       > :ip: 0.0.0.0       > :log: foreground       > :result_storage:       > :memcache: "10.10.10.2:11211,10.10.10.6:11211"

- Relevant URLs: ** Home Page: http://backgroundrb.rubyforge.org ** SVN : http://svn.devjavu.com/backgroundrb/trunk ** Bug Reports/Ticks: http://backgroundrb.devjavu.com/report

- Credits : ** Ezra Zygmuntowicz,skaar for taking BackgrounDRb so far. ** Kevin for helping out with OSX issues. ** Andy for patches and initial testing. ** Paul for patching up README. ** Other initial users. ** Matz, Francis for general inspiration.

Hi

Awesome, thanks for all the work, Hemant! Does this release also fix the issue with BackgrounDRb writing ActiveRecord messages to the development log?

Yes, John,

The issue you mention has been fixed in the latest release.