[Backgroundrb-devel] backgroundrb preview

[hemant]

On 11/5/06, hemant <gethemant at gmail.com> wrote:
> Hi Ezra/skaar,
>
> Wow man, the exercise was worth it. The connection closed problem with
> socket as i mentioned in my earlier mails...completely disappeared,
> and now i can connect only once to the socket and keep reading..till
> end of its days.
>
> Literally impossible with older release of backgroundrb.
>
> This could also potentially solve the issues people were having with
> ActiveRecord.
>
> As i said somewhere in past, I was/am using my home baked solution
> with EventMachine and  Memcache..which was serving me fine. But
> parsing the input data from socket is real pain. Parsing strings...are
> fun, but I had no idea..how do i go abt objects.
>
> But this release of backgroundrb fills the gap.
>

Here are some doubts/questions:

I have a worker like:

class FooWorker < BackgrounDRb::Worker::RailsBase
  attr_accessor :data_ready
  attr_accessor :xml_data
  def do_work
      @data_ready = false
     # initialize socket and few other things
  end

  def read_from_socket
     @data_ready = false
     # long running operation, may take time
     # populate XML data, read from socket
     @data_ready = true
  end

Now..in controller:

    MiddleMan.new_worker(:class => :foobar_worker,
                         :job_key => :lol,
                         :args => "Lol")
    worker = MiddleMan.worker(:lol)

    worker.read_from_socket  ##### interesting line #666

    if worker.data_ready
      render :xml => worker.xml_data
    else
      render :text => "Worki going on"
    end


now..on #666, how do i make sure..that controller just triggers the
method in worker and control comes back to the controller immediately.
Sounds like a typical use case of threads.

What I would like to do, is poll on the worker if data is ready..or
else display some foobar. Pretty standard thing i guess.


Another question, if you guys are still dozing:

Line # 443, README:

"Schedule worker to trigger every minute on the fifth second. Make sure
to delete these when they are done doing their work, as it would create
a new worker with a generated key every time the schedule is triggered."

So let's say..i have setup a perpetually running job that runs every
20 minutes or so, throguh  this config:

simple_label3:
  |  :class: :example_worker
  |  :job_key: :job_key3
  |  :worker_method: :do_work
  |  :trigger_args:
    |    :repeat_interval: 10.minute


Now..why on earth, I should delete this worker..once it finishes
processing at the end of each cycle? Surely..i am missing something or
is that the case...or else I will have a basket full of workers doing
same job over and over again..until earth tips over.


-- 
There was only one Road; that it was like a great river: its springs
were at every doorstep, and every path was its tributary.