Backgroundrb devel - Oct 2007 - How you want BackgrounDrb to behave

Hi,

Ok, As i promised.. I am working on new version of BackgrounDRB, which
is getting close and will be out soon. I need some feedback from you
guys. So, please reply back.

The code has changed significantly and its no longer using DRB. But I
will keep the name BackgroundRb. Ok, in new API, a worker looks like
this:

require "net/smtp"
require "guid"

class NewsletterWorker < Packet::Worker
  set_worker_name :newsletter_worker
  def worker_init
    puts "starting the worker"
  end

  def receive_data p_data
  end

  # this is where a request from rails will be received. so implement
this method
  # if you want to trigger your workers from rails.
  def receive_internal_data p_data
    self.send(p_data[:method],p_data[:data])
  end

  def send_mail data
  end
end

And you can invoke a method in worker from rails using:
# invoke method send_mail in newsletter_worker
WorkerProxy.send_request(:worker => :newsletter_worker, :method =>
:send_mail, :data => @newsletter.id)
# No Kidding, guys above code works.

Also, as usual you define your workers in a worker directory and they
will be picked and run.

Now, It should be noted that, part of stability that comes to new
version is because of total lack of threads. Even timers are
implemented using evented model of programming. Right now, we have two
methods "add_timer" and "add_periodic_timer" available in
all the
workers, which can be used to schedule a job.

A sample use case is:

def worker_init
   add_periodic_timer(10) { puts "Hello World : #{Time.now}"}
 end

Older version of BackgrounDrb was having a seperate file which was
used for reading worker schedules. I am thinking of getting rid of
that file and making all the workers self contained.
What you guys think?


Things that are not working:
1. There is no worker.delete or self.delete to stop a worker. But
since, your workers are seperate processes, you can call exit on them.
2. Since older version of BackgrounDrb used threads. The famous
progress bar example, that came with initial version of BackgrounDrb
worked. But new version has a event loop around all the workers and
thats how it runs timers and can trigger callbacks. So progress bar
example, will have to reworked using callback mechanism, rather than
threads.


PS: trunk doesn''t yet reflect the changes i said. I will be checking
in code soon. stay tuned.


-- 

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

Thank you for your hard work.  Getting rid of threads will help stability
immensely.

Re: the file for scheduled jobs.  
Remove away.  I would much rather have the scheduling definition contained
in the object rather than yet another configuration file.

Jim Scott


-----Original Message-----
From: backgroundrb-devel-bounces at rubyforge.org
[mailto:backgroundrb-devel-bounces at rubyforge.org] On Behalf Of hemant
Sent: Wednesday, October 31, 2007 5:08 PM
To: backgroundrb-devel at rubyforge.org
Subject: [Backgroundrb-devel] How you want BackgrounDrb to behave

Hi,

Ok, As i promised.. I am working on new version of BackgrounDRB, which
is getting close and will be out soon. I need some feedback from you
guys. So, please reply back.

The code has changed significantly and its no longer using DRB. But I
will keep the name BackgroundRb. Ok, in new API, a worker looks like
this:

require "net/smtp"
require "guid"

class NewsletterWorker < Packet::Worker
  set_worker_name :newsletter_worker
  def worker_init
    puts "starting the worker"
  end

  def receive_data p_data
  end

  # this is where a request from rails will be received. so implement
this method
  # if you want to trigger your workers from rails.
  def receive_internal_data p_data
    self.send(p_data[:method],p_data[:data])
  end

  def send_mail data
  end
end

And you can invoke a method in worker from rails using:
# invoke method send_mail in newsletter_worker
WorkerProxy.send_request(:worker => :newsletter_worker, :method =>
:send_mail, :data => @newsletter.id)
# No Kidding, guys above code works.

Also, as usual you define your workers in a worker directory and they
will be picked and run.

Now, It should be noted that, part of stability that comes to new
version is because of total lack of threads. Even timers are
implemented using evented model of programming. Right now, we have two
methods "add_timer" and "add_periodic_timer" available in
all the
workers, which can be used to schedule a job.

A sample use case is:

def worker_init
   add_periodic_timer(10) { puts "Hello World : #{Time.now}"}
 end

Older version of BackgrounDrb was having a seperate file which was
used for reading worker schedules. I am thinking of getting rid of
that file and making all the workers self contained.
What you guys think?


Things that are not working:
1. There is no worker.delete or self.delete to stop a worker. But
since, your workers are seperate processes, you can call exit on them.
2. Since older version of BackgrounDrb used threads. The famous
progress bar example, that came with initial version of BackgrounDrb
worked. But new version has a event loop around all the workers and
thats how it runs timers and can trigger callbacks. So progress bar
example, will have to reworked using callback mechanism, rather than
threads.


PS: trunk doesn''t yet reflect the changes i said. I will be checking
in code soon. stay tuned.


-- 

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
_______________________________________________
Backgroundrb-devel mailing list
Backgroundrb-devel at rubyforge.org
http://rubyforge.org/mailman/listinfo/backgroundrb-devel

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.16/1102 - Release Date: 10/31/2007
4:38 PM
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.16/1102 - Release Date: 10/31/2007
4:38 PM

Sweet deal hemant, this will be a big improvement.

-Ezra

On Oct 31, 2007, at 4:07 PM, hemant wrote:
> Hi,
>
> Ok, As i promised.. I am working on new version of BackgrounDRB, which
> is getting close and will be out soon. I need some feedback from you
> guys. So, please reply back.
>
> The code has changed significantly and its no longer using DRB. But I
> will keep the name BackgroundRb. Ok, in new API, a worker looks like
> this:
>
> require "net/smtp"
> require "guid"
>
> class NewsletterWorker < Packet::Worker
>  set_worker_name :newsletter_worker
>  def worker_init
>    puts "starting the worker"
>  end
>
>  def receive_data p_data
>  end
>
>  # this is where a request from rails will be received. so implement
> this method
>  # if you want to trigger your workers from rails.
>  def receive_internal_data p_data
>    self.send(p_data[:method],p_data[:data])
>  end
>
>  def send_mail data
>  end
> end
>
> And you can invoke a method in worker from rails using:
> # invoke method send_mail in newsletter_worker
> WorkerProxy.send_request(:worker => :newsletter_worker, :method =>
> :send_mail, :data => @newsletter.id)
> # No Kidding, guys above code works.
>
> Also, as usual you define your workers in a worker directory and they
> will be picked and run.
>
> Now, It should be noted that, part of stability that comes to new
> version is because of total lack of threads. Even timers are
> implemented using evented model of programming. Right now, we have two
> methods "add_timer" and "add_periodic_timer" available
in all the
> workers, which can be used to schedule a job.
>
> A sample use case is:
>
> def worker_init
>   add_periodic_timer(10) { puts "Hello World : #{Time.now}"}
> end
>
> Older version of BackgrounDrb was having a seperate file which was
> used for reading worker schedules. I am thinking of getting rid of
> that file and making all the workers self contained.
> What you guys think?
>
>
> Things that are not working:
> 1. There is no worker.delete or self.delete to stop a worker. But
> since, your workers are seperate processes, you can call exit on them.
> 2. Since older version of BackgrounDrb used threads. The famous
> progress bar example, that came with initial version of BackgrounDrb
> worked. But new version has a event loop around all the workers and
> thats how it runs timers and can trigger callbacks. So progress bar
> example, will have to reworked using callback mechanism, rather than
> threads.
>
>
> PS: trunk doesn''t yet reflect the changes i said. I will be
checking
> in code soon. stay tuned.
>
>
> -- 
>
> 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
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>

Holler if you need testers.  I have several apps that are using
BackgroundRb, one which is in development stages.

~ Ben

On 10/31/07, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
> Sweet deal hemant, this will be a big improvement.
>
> -Ezra
>
> On Oct 31, 2007, at 4:07 PM, hemant wrote:
>
> > Hi,
> >
> > Ok, As i promised.. I am working on new version of BackgrounDRB, which
> > is getting close and will be out soon. I need some feedback from you
> > guys. So, please reply back.
> >
> > The code has changed significantly and its no longer using DRB. But I
> > will keep the name BackgroundRb. Ok, in new API, a worker looks like
> > this:
> >
> > require "net/smtp"
> > require "guid"
> >
> > class NewsletterWorker < Packet::Worker
> >  set_worker_name :newsletter_worker
> >  def worker_init
> >    puts "starting the worker"
> >  end
> >
> >  def receive_data p_data
> >  end
> >
> >  # this is where a request from rails will be received. so implement
> > this method
> >  # if you want to trigger your workers from rails.
> >  def receive_internal_data p_data
> >    self.send(p_data[:method],p_data[:data])
> >  end
> >
> >  def send_mail data
> >  end
> > end
> >
> > And you can invoke a method in worker from rails using:
> > # invoke method send_mail in newsletter_worker
> > WorkerProxy.send_request(:worker => :newsletter_worker, :method
=>
> > :send_mail, :data => @newsletter.id)
> > # No Kidding, guys above code works.
> >
> > Also, as usual you define your workers in a worker directory and they
> > will be picked and run.
> >
> > Now, It should be noted that, part of stability that comes to new
> > version is because of total lack of threads. Even timers are
> > implemented using evented model of programming. Right now, we have two
> > methods "add_timer" and "add_periodic_timer"
available in all the
> > workers, which can be used to schedule a job.
> >
> > A sample use case is:
> >
> > def worker_init
> >   add_periodic_timer(10) { puts "Hello World : #{Time.now}"}
> > end
> >
> > Older version of BackgrounDrb was having a seperate file which was
> > used for reading worker schedules. I am thinking of getting rid of
> > that file and making all the workers self contained.
> > What you guys think?
> >
> >
> > Things that are not working:
> > 1. There is no worker.delete or self.delete to stop a worker. But
> > since, your workers are seperate processes, you can call exit on them.
> > 2. Since older version of BackgrounDrb used threads. The famous
> > progress bar example, that came with initial version of BackgrounDrb
> > worked. But new version has a event loop around all the workers and
> > thats how it runs timers and can trigger callbacks. So progress bar
> > example, will have to reworked using callback mechanism, rather than
> > threads.
> >
> >
> > PS: trunk doesn''t yet reflect the changes i said. I will be
checking
> > in code soon. stay tuned.
> >
> >
> > --
> >
> > 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
> > _______________________________________________
> > Backgroundrb-devel mailing list
> > Backgroundrb-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>

-- 
Ben Reubenstein
303-947-0446
http://www.x-cr.com

On 11/1/07, Ben Reubenstein <benr at x-cr.com>
wrote:
> Holler if you need testers.  I have several apps that are using
> BackgroundRb, one which is in development stages.
>
Yup, You are more than welcome. Wait for the pre-release.
> ~ Ben
>
> On 10/31/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> > Sweet deal hemant, this will be a big improvement.
> >
> > -Ezra
Thanks Ezra.


Jim:
Ok then, we will be taking out schedules.yml file altogether. I hope,
it doesn''t piss off people.


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