[ANN] BackgrounDRb 1.0 pre-release available now

Hi Folks,

We are glad to announce shiny new release of BackgrounDRb, which will
soon become 1.0.

A quick summary of changes:

  • BackgrounDRb is no londer DRb, its based on event driven network
    programming library packet ( http://www.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, progrss 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 mulitple methods with their own triggers.

  • 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.

The detailed list of changes can be found here:

http://backgroundrb.rubyforge.org/

Please give it a try and let me know if you found any bugs.


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

Hemant, this looks great. Could one use BackgroundRb to have workers
interact programatically with a remote telnet service? Or would I
simply start a worker that does this interaction via a
shell/spawn/telnet/expect…

Great doco too, thanks.

George

On Tue, 2007-12-11 at 23:08 +1100, George Bray wrote:

Hemant, this looks great. Could one use BackgroundRb to have workers
interact programatically with a remote telnet service? Or would I
simply start a worker that does this interaction via a
shell/spawn/telnet/expect…

Sure as hell… with any tcp service actually in a evented manner.
However, that area is not polished ( no one ever asked. :slight_smile: )

@Hemant :

Has this been tested on Windows? If so, are there known issues? Previous
versions did not work on Windows, although the original version did.

On Tue, 2007-12-11 at 07:45 -0600, Brian H. wrote:

@Hemant :

Has this been tested on Windows? If so, are there known issues?
Previous versions did not work on Windows, although the original
version did.

No, it won’t work on Windows. Even when I removed “slave”, still we need
unix domain sockets for internal communication, which is not available
on windows.


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

@Hemant:

Thank you. That’s what I suspected.

Hi,

Looking forward to a chance to use this library. Thanks for the work!

On 10-Dec-07, at 6:47 PM, hemant wrote:

How does this affect the licensing of BackgrounDRb (not to mention the
name of the project :-)? The packet library is GPLv2 (the url doesn’t
have the leading www by the way), while BackgrounDRb is dual licensed
with the Ruby License or an MIT license.

Cheers,
Bob

Hi

On Wed, 2007-12-12 at 11:35 -0500, Bob H. wrote:

How does this affect the licensing of BackgrounDRb (not to mention the
name of the project :-)? The packet library is GPLv2 (the url doesn’t
have the leading www by the way), while BackgrounDRb is dual licensed
with the Ruby License or an MIT license.

Damn I realized it after posting the message. But then thought “packet”
may be irrelevant anyways ( to rails guys i mean )

Regarding license issues, since packet is dual licensed under GPL2 and
Ruby, you can take shit from packet and embed in your app and forget
that its under GPL2, since Ruby license allows you do that. There is a
clause from Ruby license that says:

“place your modifications in the Public Domain or otherwise
make them Freely Available, such as by posting said
modifications to Usenet or an equivalent medium, or by allowing
the author to include your modifications in the software.”

So, I guess its ok to have that.


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

Question: anyone know the ‘latest’ version that does work with windows
(of backgroundrb?)
Thanks!
-Roger
Brian H. wrote:

@Hemant :

Has this been tested on Windows? If so, are there known issues? Previous
versions did not work on Windows, although the original version did.

svn checkout svn://rubyforge.org/var/svn/backgroundrb

Question: anyone know the ‘latest’ version that does work with windows
(of backgroundrb?)
Thanks!
-Roger

Question: how does this compare to EventMachine?

  • 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.

Question: how does this compare to EventMachine?

Sorry about wrong link, correct one is: http://packet.googlecode.com

Well, i think one of the strengths of packet is, it lets you write
tightly integrated workers with master process. So, this way, you can
offload blocking tasks to these workers, which will run parallely and
keep processing further requests in master.

And its pure ruby.

Sounds cool. I think EM also does pure ruby these days–seems like a
trend :slight_smile:
Now if I can just figure out which is the latest version of
acts_as_ferret that runs on win32… :slight_smile:
Thanks for any help.
-Roger

On Dec 29, 2007 1:58 AM, Roger P. [email protected]
wrote:

Question: how does this compare to EventMachine?

Sorry about wrong link, correct one is: http://packet.googlecode.com

Well, i think one of the strengths of packet is, it lets you write
tightly integrated workers with master process. So, this way, you can
offload blocking tasks to these workers, which will run parallely and
keep processing further requests in master.

And its pure ruby.


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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs