Backgroundrb devel - Nov 2007 - pre-release version of backgroundrb available now from svn

Hi,

A pre-release version of backgroundrb is available now from svn.
Download it from here:

http://svn.devjavu.com/backgroundrb/branches/version099/

Since this release marks significant migration from existing
practices, i intend to keep trunk untouched for a while.

There are no install scripts, but you should copy "backgroundrb" file
from script directory of plugin to script directory of rails. You
should also config "backgroundrb.yml" file from config directory of
plugin to config directory of rails root.

There is one sample worker available in
BACKGROUNDRB_ROOT/sample_worker directory.
There is also a sample client available.

Currently, passing of ActiveRecord objects is not supported. Although,
We can do that, but in most situations, passing ''id'' of object
is
enough i thought. Also, you may encounter some bugs when you are
passing large objects around.

I will try to explain meat of a sample worker:

class FooWorker < MetaWorker
  set_worker_name :foo_worker
  attr_accessor :count
  def worker_init
    puts "Starting Foo Worker"
    add_periodic_timer(4) { increment_status}
  end
  def process_request p_data
    p p_data
  end

  def increment_status
    @count ||= 0
    @count += 1
    register_status(@count)
  end
end

First, I intend to wrap MetaWorker within a namespace(read module), so
pardon me there.

So, when backgroundrb starts it reads all the workers in
WORKER_ROOT(which should be RAILS_ROOT/lib/workers) directory and
worker_init is called in child process of each worker. You can use
worker_init for initializing a worker.

"process_request" is the method which will be normally invoked when
you receive requests from rails. But there is a exception, in each
worker there is a method called "register_status" available, which can
be invoked from workers to register their status with master.

Now, from rails, you can query status of a worker using

MiddleMan.ask_status(:worker => :foo_worker)

All the status requests are server by master itself and hence
"process_request" inside worker will not be invoked for them.

You will find support for schedules very rough around the edges.
Reason is, You can use

add_periodic_timer(5) { foo_job }

to do any kind of scheduling. add_periodic_timer takes number of
seconds as argument.
for one shot timers, you can use:

add_timer(5) { foo_job }


Core of new version of bdrb is implemented on a networking library
called "packet".  It needs its own introduction. But now, inside each
worker you can start evented network connections. You have some
methods like:

connect("localhost",5678,FooHandler)
start_server("localhost"m,5678,FooServer)

inside each worker, which can be used to let workers do fancy stuff.
This is just a by product of using "packet" library.

I know, thing is rough around the edge and needs more polish. But
still, i hope it will be more stable than previous versions of
backgroundrb.

Please report all the bugs here.

Thanks

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

On 11/2/07, hemant <gethemant at gmail.com> wrote:
> Hi,
>
> A pre-release version of backgroundrb is available now from svn.
> Download it from here:
>
> http://svn.devjavu.com/backgroundrb/branches/version099/
>
> Since this release marks significant migration from existing
> practices, i intend to keep trunk untouched for a while.
>
> There are no install scripts, but you should copy "backgroundrb"
file
> from script directory of plugin to script directory of rails. You
> should also config "backgroundrb.yml" file from config directory
of
> plugin to config directory of rails root.
>
> There is one sample worker available in
> BACKGROUNDRB_ROOT/sample_worker directory.
> There is also a sample client available.
>
> Currently, passing of ActiveRecord objects is not supported. Although,
> We can do that, but in most situations, passing ''id'' of
object is
> enough i thought. Also, you may encounter some bugs when you are
> passing large objects around.
>
> I will try to explain meat of a sample worker:
>
> class FooWorker < MetaWorker
>   set_worker_name :foo_worker
>   attr_accessor :count
>   def worker_init
>     puts "Starting Foo Worker"
>     add_periodic_timer(4) { increment_status}
>   end
>   def process_request p_data
>     p p_data
>   end
>
>   def increment_status
>     @count ||= 0
>     @count += 1
>     register_status(@count)
>   end
> end
>
> First, I intend to wrap MetaWorker within a namespace(read module), so
> pardon me there.
>
> So, when backgroundrb starts it reads all the workers in
> WORKER_ROOT(which should be RAILS_ROOT/lib/workers) directory and
> worker_init is called in child process of each worker. You can use
> worker_init for initializing a worker.
>
> "process_request" is the method which will be normally invoked
when
> you receive requests from rails. But there is a exception, in each
> worker there is a method called "register_status" available,
which can
> be invoked from workers to register their status with master.
>
> Now, from rails, you can query status of a worker using
>
> MiddleMan.ask_status(:worker => :foo_worker)
>
> All the status requests are server by master itself and hence
> "process_request" inside worker will not be invoked for them.
>
> You will find support for schedules very rough around the edges.
> Reason is, You can use
>
> add_periodic_timer(5) { foo_job }
>
> to do any kind of scheduling. add_periodic_timer takes number of
> seconds as argument.
> for one shot timers, you can use:
>
> add_timer(5) { foo_job }
>
>
> Core of new version of bdrb is implemented on a networking library
> called "packet".  It needs its own introduction. But now, inside
each
> worker you can start evented network connections. You have some
> methods like:
>
> connect("localhost",5678,FooHandler)
> start_server("localhost"m,5678,FooServer)
>
> inside each worker, which can be used to let workers do fancy stuff.
> This is just a by product of using "packet" library.
>
> I know, thing is rough around the edge and needs more polish. But
> still, i hope it will be more stable than previous versions of
> backgroundrb.
>
> Please report all the bugs here.
>
Couple of things, I wanted to add.

If you want to access your workers from other machines, then ip
section in config file should be something thats accessible from all
machines.

Also, you can''t restart your workers from rails. Although I would like
to have support for starting and stopping of workers dynamically, but
it was possible in this release.

I am looking for suggestions on how to smoothen scheduling of worker
methods. Currently its just add_periodic_timer and whatever we
implement is just going to be "sugar" around it, yet I need some
opinions.


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

Kick ass hemant. Looks good. I''m playing with it now and will give  
feedback,

Cheers-
-Ezra

On Nov 2, 2007, at 3:26 AM, hemant wrote:
> On 11/2/07, hemant <gethemant at gmail.com> wrote:
>> Hi,
>>
>> A pre-release version of backgroundrb is available now from svn.
>> Download it from here:
>>
>> http://svn.devjavu.com/backgroundrb/branches/version099/
>>
>> Since this release marks significant migration from existing
>> practices, i intend to keep trunk untouched for a while.
>>
>> There are no install scripts, but you should copy
"backgroundrb" file
>> from script directory of plugin to script directory of rails. You
>> should also config "backgroundrb.yml" file from config
directory of
>> plugin to config directory of rails root.
>>
>> There is one sample worker available in
>> BACKGROUNDRB_ROOT/sample_worker directory.
>> There is also a sample client available.
>>
>> Currently, passing of ActiveRecord objects is not supported.  
>> Although,
>> We can do that, but in most situations, passing ''id''
of object is
>> enough i thought. Also, you may encounter some bugs when you are
>> passing large objects around.
>>
>> I will try to explain meat of a sample worker:
>>
>> class FooWorker < MetaWorker
>>  set_worker_name :foo_worker
>>  attr_accessor :count
>>  def worker_init
>>    puts "Starting Foo Worker"
>>    add_periodic_timer(4) { increment_status}
>>  end
>>  def process_request p_data
>>    p p_data
>>  end
>>
>>  def increment_status
>>    @count ||= 0
>>    @count += 1
>>    register_status(@count)
>>  end
>> end
>>
>> First, I intend to wrap MetaWorker within a namespace(read module),  
>> so
>> pardon me there.
>>
>> So, when backgroundrb starts it reads all the workers in
>> WORKER_ROOT(which should be RAILS_ROOT/lib/workers) directory and
>> worker_init is called in child process of each worker. You can use
>> worker_init for initializing a worker.
>>
>> "process_request" is the method which will be normally
invoked when
>> you receive requests from rails. But there is a exception, in each
>> worker there is a method called "register_status" available,
which
>> can
>> be invoked from workers to register their status with master.
>>
>> Now, from rails, you can query status of a worker using
>>
>> MiddleMan.ask_status(:worker => :foo_worker)
>>
>> All the status requests are server by master itself and hence
>> "process_request" inside worker will not be invoked for them.
>>
>> You will find support for schedules very rough around the edges.
>> Reason is, You can use
>>
>> add_periodic_timer(5) { foo_job }
>>
>> to do any kind of scheduling. add_periodic_timer takes number of
>> seconds as argument.
>> for one shot timers, you can use:
>>
>> add_timer(5) { foo_job }
>>
>>
>> Core of new version of bdrb is implemented on a networking library
>> called "packet".  It needs its own introduction. But now,
inside each
>> worker you can start evented network connections. You have some
>> methods like:
>>
>> connect("localhost",5678,FooHandler)
>> start_server("localhost"m,5678,FooServer)
>>
>> inside each worker, which can be used to let workers do fancy stuff.
>> This is just a by product of using "packet" library.
>>
>> I know, thing is rough around the edge and needs more polish. But
>> still, i hope it will be more stable than previous versions of
>> backgroundrb.
>>
>> Please report all the bugs here.
>>
>
> Couple of things, I wanted to add.
>
> If you want to access your workers from other machines, then ip
> section in config file should be something thats accessible from all
> machines.
>
> Also, you can''t restart your workers from rails. Although I would
like
> to have support for starting and stopping of workers dynamically, but
> it was possible in this release.
>
> I am looking for suggestions on how to smoothen scheduling of worker
> methods. Currently its just add_periodic_timer and whatever we
> implement is just going to be "sugar" around it, yet I need some
> opinions.
>
>
> -- 
> 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
>

On Fri, 2007-11-02 at 10:03 -0700, Ezra Zygmuntowicz
wrote:
> Kick ass hemant. Looks good. I''m playing with it now and will give
> feedback,
> 
Thanks Ezra, for kind words. Do, let me know about any bugs you find.

I expect the API to change in coming days. I can imagine a rails page,
which will tell you about all your workers and what they are doing. You
can stop,start them from web interface. Lets see how far we can get.


> Cheers-
> -Ezra
> 
> On Nov 2, 2007, at 3:26 AM, hemant wrote:
> 
> > On 11/2/07, hemant <gethemant at gmail.com> wrote:
> >> Hi,
> >>
> >> A pre-release version of backgroundrb is available now from svn.
> >> Download it from here:
> >>
> >> http://svn.devjavu.com/backgroundrb/branches/version099/
> >>
> >> Since this release marks significant migration from existing
> >> practices, i intend to keep trunk untouched for a while.
> >>
> >> There are no install scripts, but you should copy
"backgroundrb" file
> >> from script directory of plugin to script directory of rails. You
> >> should also config "backgroundrb.yml" file from config
directory of
> >> plugin to config directory of rails root.
> >>
> >> There is one sample worker available in
> >> BACKGROUNDRB_ROOT/sample_worker directory.
> >> There is also a sample client available.
> >>
> >> Currently, passing of ActiveRecord objects is not supported.  
> >> Although,
> >> We can do that, but in most situations, passing
''id'' of object is
> >> enough i thought. Also, you may encounter some bugs when you are
> >> passing large objects around.
> >>
> >> I will try to explain meat of a sample worker:
> >>
> >> class FooWorker < MetaWorker
> >>  set_worker_name :foo_worker
> >>  attr_accessor :count
> >>  def worker_init
> >>    puts "Starting Foo Worker"
> >>    add_periodic_timer(4) { increment_status}
> >>  end
> >>  def process_request p_data
> >>    p p_data
> >>  end
> >>
> >>  def increment_status
> >>    @count ||= 0
> >>    @count += 1
> >>    register_status(@count)
> >>  end
> >> end
> >>
> >> First, I intend to wrap MetaWorker within a namespace(read
module),
> >> so
> >> pardon me there.
> >>
> >> So, when backgroundrb starts it reads all the workers in
> >> WORKER_ROOT(which should be RAILS_ROOT/lib/workers) directory and
> >> worker_init is called in child process of each worker. You can use
> >> worker_init for initializing a worker.
> >>
> >> "process_request" is the method which will be normally
invoked when
> >> you receive requests from rails. But there is a exception, in each
> >> worker there is a method called "register_status"
available, which
> >> can
> >> be invoked from workers to register their status with master.
> >>
> >> Now, from rails, you can query status of a worker using
> >>
> >> MiddleMan.ask_status(:worker => :foo_worker)
> >>
> >> All the status requests are server by master itself and hence
> >> "process_request" inside worker will not be invoked for
them.
> >>
> >> You will find support for schedules very rough around the edges.
> >> Reason is, You can use
> >>
> >> add_periodic_timer(5) { foo_job }
> >>
> >> to do any kind of scheduling. add_periodic_timer takes number of
> >> seconds as argument.
> >> for one shot timers, you can use:
> >>
> >> add_timer(5) { foo_job }
> >>
> >>
> >> Core of new version of bdrb is implemented on a networking library
> >> called "packet".  It needs its own introduction. But
now, inside each
> >> worker you can start evented network connections. You have some
> >> methods like:
> >>
> >> connect("localhost",5678,FooHandler)
> >> start_server("localhost"m,5678,FooServer)
> >>
> >> inside each worker, which can be used to let workers do fancy
stuff.
> >> This is just a by product of using "packet" library.
> >>
> >> I know, thing is rough around the edge and needs more polish. But
> >> still, i hope it will be more stable than previous versions of
> >> backgroundrb.
> >>
> >> Please report all the bugs here.
> >>
> >
> > Couple of things, I wanted to add.
> >
> > If you want to access your workers from other machines, then ip
> > section in config file should be something thats accessible from all
> > machines.
> >
> > Also, you can''t restart your workers from rails. Although I
would like
> > to have support for starting and stopping of workers dynamically, but
> > it was possible in this release.
> >
> > I am looking for suggestions on how to smoothen scheduling of worker
> > methods. Currently its just add_periodic_timer and whatever we
> > implement is just going to be "sugar" around it, yet I need
some
> > opinions.
> >
> >
> > -- 
> > 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
> >
>

On 11/2/07, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
> Kick ass hemant. Looks good. I''m playing with it now and will give
> feedback,
>
Thanks Ezra, for kind words. Do, let me know about any bugs you find.

I expect the API to change in coming days. I can imagine a rails page,
which will tell you about all your workers and what they are doing. You
can stop,start them from web interface. Lets see how far we can get.


-
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

On 11/2/07, hemant <gethemant at gmail.com> wrote:
> On 11/2/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> > Kick ass hemant. Looks good. I''m playing with it now and will
give
> > feedback,
> >
>
> Thanks Ezra, for kind words. Do, let me know about any bugs you find.
>
> I expect the API to change in coming days. I can imagine a rails page,
> which will tell you about all your workers and what they are doing. You
> can stop,start them from web interface. Lets see how far we can get.
>
Damn, I the only external dependency is:

http://rubyforge.org/projects/uuid/

You need to grab this to run it.

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

Hi Hemant,

The new API looks great, but I''m having a couple of problems I wonder  
if you know about.

* The first is that there seems to be a missing guid.rb file in the  
repository? In packet.rb there is:

require ''guid''

I created my own guid.rb and added a hexdigest method which seemed to  
fix the problem.

* The second is when I start and stop backgroundrb it prints out:


Loaded suite script/backgroundrb
Started

Finished in 0.00025 seconds.

0 tests, 0 assertions, 0 failures, 0 errors

It looks like it''s loading the test suite somehow, but I''m
confused
about how.

* Finally I always get a nice little stack trace when I call  
backgroundrb stop

$ /Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/ 
framework/nbio.rb:12:in `read_data'': Packet::DisconnectError  
(Packet::DisconnectError)
         from /Users/brendan/Workspace/kuripai/hac/vendor/plugins/ 
backgroundrb/framework/worker.rb:43:in `handle_internal_messages''
         from /Users/brendan/Workspace/kuripai/hac/vendor/plugins/ 
backgroundrb/framework/core.rb:131:in `start_reactor''
         from /Users/brendan/Workspace/kuripai/hac/vendor/plugins/ 
backgroundrb/framework/core.rb:129:in `each''
         from /Users/brendan/Workspace/kuripai/hac/vendor/plugins/ 
backgroundrb/framework/core.rb:129:in `start_reactor''

Thanks!
Brendan

On Nov 2, 2007, at 6:05 AM, hemant wrote:
> Hi,
>
> A pre-release version of backgroundrb is available now from svn.
> Download it from here:
>
> http://svn.devjavu.com/backgroundrb/branches/version099/
>
> Since this release marks significant migration from existing
> practices, i intend to keep trunk untouched for a while.
>
> There are no install scripts, but you should copy "backgroundrb"
file
> from script directory of plugin to script directory of rails. You
> should also config "backgroundrb.yml" file from config directory
of
> plugin to config directory of rails root.
>
> There is one sample worker available in
> BACKGROUNDRB_ROOT/sample_worker directory.
> There is also a sample client available.
>
> Currently, passing of ActiveRecord objects is not supported. Although,
> We can do that, but in most situations, passing ''id'' of
object is
> enough i thought. Also, you may encounter some bugs when you are
> passing large objects around.
>
> I will try to explain meat of a sample worker:
>
> class FooWorker < MetaWorker
>   set_worker_name :foo_worker
>   attr_accessor :count
>   def worker_init
>     puts "Starting Foo Worker"
>     add_periodic_timer(4) { increment_status}
>   end
>   def process_request p_data
>     p p_data
>   end
>
>   def increment_status
>     @count ||= 0
>     @count += 1
>     register_status(@count)
>   end
> end
>
> First, I intend to wrap MetaWorker within a namespace(read module), so
> pardon me there.
>
> So, when backgroundrb starts it reads all the workers in
> WORKER_ROOT(which should be RAILS_ROOT/lib/workers) directory and
> worker_init is called in child process of each worker. You can use
> worker_init for initializing a worker.
>
> "process_request" is the method which will be normally invoked
when
> you receive requests from rails. But there is a exception, in each
> worker there is a method called "register_status" available,
which can
> be invoked from workers to register their status with master.
>
> Now, from rails, you can query status of a worker using
>
> MiddleMan.ask_status(:worker => :foo_worker)
>
> All the status requests are server by master itself and hence
> "process_request" inside worker will not be invoked for them.
>
> You will find support for schedules very rough around the edges.
> Reason is, You can use
>
> add_periodic_timer(5) { foo_job }
>
> to do any kind of scheduling. add_periodic_timer takes number of
> seconds as argument.
> for one shot timers, you can use:
>
> add_timer(5) { foo_job }
>
>
> Core of new version of bdrb is implemented on a networking library
> called "packet".  It needs its own introduction. But now, inside
each
> worker you can start evented network connections. You have some
> methods like:
>
> connect("localhost",5678,FooHandler)
> start_server("localhost"m,5678,FooServer)
>
> inside each worker, which can be used to let workers do fancy stuff.
> This is just a by product of using "packet" library.
>
> I know, thing is rough around the edge and needs more polish. But
> still, i hope it will be more stable than previous versions of
> backgroundrb.
>
> Please report all the bugs here.
>
> Thanks
>
> -- 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20071104/ee42868c/attachment-0001.html

On 11/5/07, Brendan Grainger <brendan.grainger at gmail.com>
wrote:
>  Hi Hemant,
>
> The new API looks great, but I''m having a couple of problems I
wonder if you
> know about.
>
> * The first is that there seems to be a missing guid.rb file in the
> repository? In packet.rb there is:
>
>
> require ''guid''
Yes it depends on uuid gem, which can be downloaded from:

http://rubyforge.org/projects/uuid/
>
> I created my own guid.rb and added a hexdigest method which seemed to fix
> the problem.
Yes that would solve the problem.
>
> * The second is when I start and stop backgroundrb it prints out:
>
>
> Loaded suite script/backgroundrb
> Started
>
> Finished in 0.00025 seconds.
>
> 0 tests, 0 assertions, 0 failures, 0 errors
>
Weird, I will have a look into this. If your app is not too critical,
you can zip entire code and send me. I will surely look into this.

> It looks like it''s loading the test suite somehow, but
I''m confused about
> how.
>
> * Finally I always get a nice little stack trace when I call backgroundrb
> stop
>
> $
>
/Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/nbio.rb:12:in
> `read_data'': Packet::DisconnectError (Packet::DisconnectError)
>         from
>
/Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/worker.rb:43:in
> `handle_internal_messages''
>         from
>
/Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/core.rb:131:in
> `start_reactor''
>         from
>
/Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/core.rb:129:in
> `each''
>         from
>
/Users/brendan/Workspace/kuripai/hac/vendor/plugins/backgroundrb/framework/core.rb:129:in
> `start_reactor''
>
He he, Don''t bother about these stacktraces. I will have to install
some signal handlers, and they will be gone. Since, those were not top
priority, I left it.

Also, I am pushing some changes, which will fix some issues with
timers. Please sync to latest code.
> Thanks!
> Brendan
>
>
> On Nov 2, 2007, at 6:05 AM, hemant wrote:
>
> Hi,
>
> A pre-release version of backgroundrb is available now from svn.
> Download it from here:
>
> http://svn.devjavu.com/backgroundrb/branches/version099/
>
> Since this release marks significant migration from existing
> practices, i intend to keep trunk untouched for a while.
>
> There are no install scripts, but you should copy "backgroundrb"
file
> from script directory of plugin to script directory of rails. You
> should also config "backgroundrb.yml" file from config directory
of
> plugin to config directory of rails root.
>
> There is one sample worker available in
> BACKGROUNDRB_ROOT/sample_worker directory.
> There is also a sample client available.
>
> Currently, passing of ActiveRecord objects is not supported. Although,
> We can do that, but in most situations, passing ''id'' of
object is
> enough i thought. Also, you may encounter some bugs when you are
> passing large objects around.
>
> I will try to explain meat of a sample worker:
>
> class FooWorker < MetaWorker
>   set_worker_name :foo_worker
>   attr_accessor :count
>   def worker_init
>     puts "Starting Foo Worker"
>     add_periodic_timer(4) { increment_status}
>   end
>   def process_request p_data
>     p p_data
>   end
>
>   def increment_status
>     @count ||= 0
>     @count += 1
>     register_status(@count)
>   end
> end
>
> First, I intend to wrap MetaWorker within a namespace(read module), so
> pardon me there.
>
> So, when backgroundrb starts it reads all the workers in
> WORKER_ROOT(which should be RAILS_ROOT/lib/workers) directory and
> worker_init is called in child process of each worker. You can use
> worker_init for initializing a worker.
>
> "process_request" is the method which will be normally invoked
when
> you receive requests from rails. But there is a exception, in each
> worker there is a method called "register_status" available,
which can
> be invoked from workers to register their status with master.
>
> Now, from rails, you can query status of a worker using
>
> MiddleMan.ask_status(:worker => :foo_worker)
>
> All the status requests are server by master itself and hence
> "process_request" inside worker will not be invoked for them.
>
> You will find support for schedules very rough around the edges.
> Reason is, You can use
>
> add_periodic_timer(5) { foo_job }
>
> to do any kind of scheduling. add_periodic_timer takes number of
> seconds as argument.
> for one shot timers, you can use:
>
> add_timer(5) { foo_job }
>
>
> Core of new version of bdrb is implemented on a networking library
> called "packet".  It needs its own introduction. But now, inside
each
> worker you can start evented network connections. You have some
> methods like:
>
> connect("localhost",5678,FooHandler)
> start_server("localhost"m,5678,FooServer)
>
> inside each worker, which can be used to let workers do fancy stuff.
> This is just a by product of using "packet" library.
>
> I know, thing is rough around the edge and needs more polish. But
> still, i hope it will be more stable than previous versions of
> backgroundrb.
>
> Please report all the bugs here.
>
> Thanks
>
> --
> 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
>

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

> > You will find support for schedules very rough around the edges.
> > Reason is, You can use
> >
> > add_periodic_timer(5) { foo_job }
Ok, I guess new release has been quite cold, with lots of changes from
existing practices. May be, time to implement some more interesting
ideas. I am still working on couple of things and I am a bit confused
on how to export a plugin from a project. I am using svn export, and
svn import to export the current plugin, but it kinda sucks.

If you guys have some opinions, about developing a plugin with a rails
project, please mention.

Now, here is the interesting part. I am working to implement
"runt"(http://runt.rubyforge.org/) temporal expressions in
backgroundrb, so as you can schedule tasks such as billing and stuff
more easily.

What you guys, think? Will it be useful to takeout existing cron style
scheduling from trunk and implement a runt interface in experimental
version?



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

I JUST completed (this weekend) a scheduling application that pushes jobs
into BackgroundRb.  It was painful, and will be painful, to maintain, and is
not portable at all from this application to any other application without
some significant rework.

I believe there is a very real difference between processing, and scheduling
of the processing.

I''m all for it.  If I can help, let me know.

Jim Scott

-----Original Message-----
From: backgroundrb-devel-bounces at rubyforge.org
[mailto:backgroundrb-devel-bounces at rubyforge.org] On Behalf Of hemant
Sent: Monday, November 05, 2007 9:52 AM
To: Brendan Grainger
Cc: backgroundrb-devel at rubyforge.org
Subject: Re: [Backgroundrb-devel] pre-release version of
backgroundrbavailable now from svn
> > You will find support for schedules very rough around the edges.
> > Reason is, You can use
> >
> > add_periodic_timer(5) { foo_job }
Ok, I guess new release has been quite cold, with lots of changes from
existing practices. May be, time to implement some more interesting
ideas. I am still working on couple of things and I am a bit confused
on how to export a plugin from a project. I am using svn export, and
svn import to export the current plugin, but it kinda sucks.

If you guys have some opinions, about developing a plugin with a rails
project, please mention.

Now, here is the interesting part. I am working to implement
"runt"(http://runt.rubyforge.org/) temporal expressions in
backgroundrb, so as you can schedule tasks such as billing and stuff
more easily.

What you guys, think? Will it be useful to takeout existing cron style
scheduling from trunk and implement a runt interface in experimental
version?



-- 
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.21/1110 - Release Date: 11/4/2007
9:37 PM
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.21/1110 - Release Date: 11/4/2007
9:37 PM

On Mon, 5 Nov 2007 22:21:55 +0530, hemant <gethemant at gmail.com>
wrote:
>> > You will find support for schedules very rough around the edges.
>> > Reason is, You can use
>> >
>> > add_periodic_timer(5) { foo_job }
> 
> Ok, I guess new release has been quite cold, with lots of changes from
> existing practices. May be, time to implement some more interesting
> ideas. I am still working on couple of things and I am a bit confused
> on how to export a plugin from a project. I am using svn export, and
> svn import to export the current plugin, but it kinda sucks.
> 
> If you guys have some opinions, about developing a plugin with a rails
> project, please mention.
> 
> Now, here is the interesting part. I am working to implement
> "runt"(http://runt.rubyforge.org/) temporal expressions in
> backgroundrb, so as you can schedule tasks such as billing and stuff
> more easily.
> 
> What you guys, think? Will it be useful to takeout existing cron style
> scheduling from trunk and implement a runt interface in experimental
> version?
My vote would be to see multiple scheduler classes: simple scheduler, cron
scheduler, runt scheduler, etc.
   
> 
> 
> 
> --
> 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