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. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary.
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.
> worker.read_from_socket ##### interesting line #666 > > 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.it''s not yet documented, but used internally for do_work, but you could call: worker.work_thread(:method => :read_from_socket) which will run the method in a separate thread in the worker process. (I would have to werify how work_thread behaves without arguments, but we can deal with that - please submit a ticket if you find that it doesn''t work).> 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.in the example above you would not have this problem, nor a reason to delete the worker. You are using :job_key here, which means singleton worker. It''s primarily in cases where you _don''t_ specify the job_key that you have to look out for "spurious" workers. /skaar -- ---------------------------------------------------------------------- |\|\ where in the | s_u_b_s_t_r_u_c_t_i_o_n | | >=========== W.A.S.T.E. | genarratologies |/|/ (_) is the wisdom | skaar at waste.org ----------------------------------------------------------------------
On 11/5/06, skaar <skaar at waste.org> wrote:> > worker.read_from_socket ##### interesting line #666 > > > > 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. > > it''s not yet documented, but used internally for do_work, but you could > call: > > worker.work_thread(:method => :read_from_socket) > > which will run the method in a separate thread in the worker process. (I > would have to werify how work_thread behaves without arguments, but we > can deal with that - please submit a ticket if you find that it doesn''t > work). > > > 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. > > in the example above you would not have this problem, nor a reason to > delete the worker. You are using :job_key here, which means singleton > worker. It''s primarily in cases where you _don''t_ specify the job_key > that you have to look out for "spurious" workers. > > /skaarThe cloud has cleared...I can see clear blue sky. Days of slavery has just begun. Thanks PS: Can we have a mirror of backgroundrb SVN at rubyforge also? devjavu SVN doesn''t play nice with people behind proxies. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary.
* skaar (skaar at waste.org) [061104 21:38]:> > worker.read_from_socket ##### interesting line #666 > > > > 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. > > it''s not yet documented, but used internally for do_work, but you could > call: > > worker.work_thread(:method => :read_from_socket) > > which will run the method in a separate thread in the worker process. (I > would have to werify how work_thread behaves without arguments, but we > can deal with that - please submit a ticket if you find that it doesn''t > work).ok, the above will in 0.2.1 (and from trunk r142) work as adverticed, you can use work_thread to background in the worker any method, with or without arguments. For now you will have to device a way in the worker to determine when the method is done doing it''s work. Worker exceptions are logged in backgroundrb.log. There is currently little indication in the MiddleMan if an exception has occured in the worker, but in the case an exception occur, the worker will be deleted. /skaar -- ---------------------------------------------------------------------- |\|\ where in the | s_u_b_s_t_r_u_c_t_i_o_n | | >=========== W.A.S.T.E. | genarratologies |/|/ (_) is the wisdom | skaar at waste.org ----------------------------------------------------------------------
On 11/6/06, skaar <skaar at waste.org> wrote:> * skaar (skaar at waste.org) [061104 21:38]: > > > worker.read_from_socket ##### interesting line #666 > > > > > > 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. > > > > it''s not yet documented, but used internally for do_work, but you could > > call: > > > > worker.work_thread(:method => :read_from_socket) > > > > which will run the method in a separate thread in the worker process. (I > > would have to werify how work_thread behaves without arguments, but we > > can deal with that - please submit a ticket if you find that it doesn''t > > work). > > ok, the above will in 0.2.1 (and from trunk r142) work as adverticed, > you can use work_thread to background in the worker any method, with or > without arguments. > > For now you will have to device a way in the worker to determine when > the method is done doing it''s work. > > Worker exceptions are logged in backgroundrb.log. There is currently > little indication in the MiddleMan if an exception has occured in the > worker, but in the case an exception occur, the worker will be deleted.no problem..I have an instance variable..that takes care... if the worker has finished its execution. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary.