From christopher.k.hall at gmail.com Tue Sep 4 15:17:49 2007 From: christopher.k.hall at gmail.com (Chris Hall) Date: Tue, 4 Sep 2007 15:17:49 -0400 Subject: [Backgroundrb-devel] so who's the new maintainer? Message-ID: never saw anything saying there was officially a new maintainer. just wondering what the status is. Chris From gethemant at gmail.com Tue Sep 4 23:26:03 2007 From: gethemant at gmail.com (hemant) Date: Wed, 5 Sep 2007 08:56:03 +0530 Subject: [Backgroundrb-devel] so who's the new maintainer? In-Reply-To: References: Message-ID: On 9/5/07, Chris Hall wrote: > never saw anything saying there was officially a new maintainer. just > wondering what the status is. > > Chris > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > Currently me and Brett Rogers stepped up for job, but real commits are pretty thin. From davidj503 at gmail.com Fri Sep 14 12:48:02 2007 From: davidj503 at gmail.com (David James) Date: Fri, 14 Sep 2007 12:48:02 -0400 Subject: [Backgroundrb-devel] Can :args only be a string? Message-ID: <59b5d4330709140948j162457cld74dab53f01d4742@mail.gmail.com> Here's something strange! the_job_key = MiddleMan.new_worker( :class => :log_view_to_sf_worker, :args => "just a string" ) works fine. But the_job_key = MiddleMan.new_worker( :class => :log_view_to_sf_worker, :args => { :landing_page => @landing_page, :driver => @driver } ) does not. It is as if :args can only be a string, not a hash! Still exploring this... -DJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070914/ded2f254/attachment.html From simon.wilkinson at 434wireless.com Fri Sep 14 12:54:09 2007 From: simon.wilkinson at 434wireless.com (Simon) Date: Fri, 14 Sep 2007 12:54:09 -0400 Subject: [Backgroundrb-devel] Can :args only be a string? In-Reply-To: <59b5d4330709140948j162457cld74dab53f01d4742@mail.gmail.com> References: <59b5d4330709140948j162457cld74dab53f01d4742@mail.gmail.com> Message-ID: <001801c7f6ef$e0f333c0$0c01a8c0@DCDGLG81> I have a worker starting that takes a hash as its args: MiddleMan.new_worker(:class => :parser_worker, :args => {:doc => @doc, :ip => @request.remote_ip}) This works fine for me. Both argument values in the hash are strings. Not sure if yours are as well. It might be more an issue of passing objects in the hash. Simon _____ From: backgroundrb-devel-bounces at rubyforge.org [mailto:backgroundrb-devel-bounces at rubyforge.org] On Behalf Of David James Sent: 14 September 2007 12:48 To: backgroundrb-devel at rubyforge.org Subject: [Backgroundrb-devel] Can :args only be a string? Here's something strange! the_job_key = MiddleMan.new_worker( :class => :log_view_to_sf_worker, :args => "just a string" ) works fine. But the_job_key = MiddleMan.new_worker ( :class => :log_view_to_sf_worker, :args => { :landing_page => @landing_page, :driver => @driver } ) does not. It is as if :args can only be a string, not a hash! Still exploring this... -DJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070914/6a13fdc1/attachment.html From bernesco at muteki.it Sun Sep 16 19:58:41 2007 From: bernesco at muteki.it (=?ISO-8859-1?Q?Alessio_Bernesco_L=E0vore?=) Date: Mon, 17 Sep 2007 01:58:41 +0200 Subject: [Backgroundrb-devel] Using ActiveRecord with CachingSweep. In-Reply-To: <8bca3aa10707300806j749adef6t3304340d729d4a30@mail.gmail.com> References: <8bca3aa10707300806j749adef6t3304340d729d4a30@mail.gmail.com> Message-ID: <3AA60380-AAEA-4685-B899-886F2EE86F85@muteki.it> Hi everyone, I need to sweep a fragment cache when a specific model is destroyed. Usually I'm using a cache_sweeper that observe the "on_destroy" event and then sweep the cache. When the operation is started from inside a controller, by an action, everything works well. But when the action is started from inside a Worker (i.e. a worker destroing objects olders than X hours) i'm not able to trigger the sweeping. Anyone can explain me why is this happening and also give me an advice on how to sweep a cache fragment from inside a worker? Thank you, Alessio Bernesco L?vore ----------------------- www.muteki.it bernesco at muteki.it 338/5614781 ----------------------- From craig at craigambrose.com Tue Sep 18 19:30:58 2007 From: craig at craigambrose.com (Craig Ambrose) Date: Wed, 19 Sep 2007 11:30:58 +1200 Subject: [Backgroundrb-devel] best practices for robust workers Message-ID: Hi folks, I've got some BackgroundRB workers to handle a long running task (triggered by a user) that work very well on my staging server, and I just wanted to check to see if anyone had any advice before I put it into production. When I start the worker (which performs an import), I write a record to my database for each import. The record gets updated by the worker to indicate progress, and marked as compete when finished. These tasks are idempotent, so I'm not concerned about attempting to do all or part of the import multiple times. It all works very nicely, but I haven't yet tested under high load, I have a couple of questions: How does the pool size work? For example, say I have a pool size of 5, and I try and create a 6th worker, what happens? Will it get queued and then created when one of the existing five is finished? Does the backgroundrb server crash much? If so, I could restart my workers based on their records in the database. Do people do this? As a manual step only? I could write a rake task to restart imports that I run if the server dies, or perhaps I could hook it in somewhere. Does backgroundRB try and restart itself if it fails? If so, is there a hook there I can use to restart my workers? thanks Craig ps: I realise BackgroundRB is not well maintained at the moment. I'm happy to help to some extent, as I think it's a great project, particularly in the area of submitting patches with tests and fixes for any problems that I encounter which affect my work. ----- Craig Ambrose www.craigambrose.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070919/ca394f56/attachment-0001.html From leeslist at gmail.com Tue Sep 18 22:18:19 2007 From: leeslist at gmail.com (lee hartley) Date: Wed, 19 Sep 2007 07:48:19 +0530 Subject: [Backgroundrb-devel] best practices for robust workers In-Reply-To: References: Message-ID: hey, This is more of a "me too" than a response, but I have found that the server does die with some regularity (at least in my case) and does not restart, I am starting to address this now and was wondering what is the best method, the first thing that comes to mind is some sort of process monitor like monit or god...along the same lines, what do people do for server boot up/reboot...my first thought is an init script but I am sure there is a more railsy way to tie it to application startup...I also am happy to contribute where needed lyric On 9/19/07, Craig Ambrose wrote: > > > Hi folks, > > I've got some BackgroundRB workers to handle a long running task (triggered > by a user) that work very well on my staging server, and I just wanted to > check to see if anyone had any advice before I put it into production. > > When I start the worker (which performs an import), I write a record to my > database for each import. The record gets updated by the worker to indicate > progress, and marked as compete when finished. These tasks are idempotent, > so I'm not concerned about attempting to do all or part of the import > multiple times. > > It all works very nicely, but I haven't yet tested under high load, I have a > couple of questions: > > How does the pool size work? For example, say I have a pool size of 5, and I > try and create a 6th worker, what happens? Will it get queued and then > created when one of the existing five is finished? > > Does the backgroundrb server crash much? If so, I could restart my workers > based on their records in the database. Do people do this? As a manual step > only? I could write a rake task to restart imports that I run if the server > dies, or perhaps I could hook it in somewhere. Does backgroundRB try and > restart itself if it fails? If so, is there a hook there I can use to > restart my workers? > > thanks > > Craig > > ps: I realise BackgroundRB is not well maintained at the moment. I'm happy > to help to some extent, as I think it's a great project, particularly in the > area of submitting patches with tests and fixes for any problems that I > encounter which affect my work. > > ----- > Craig Ambrose > www.craigambrose.com > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Everything should be made as simple as possible, but not simpler. -- Albert Einstein From epugh at opensourceconnections.com Fri Sep 21 14:43:59 2007 From: epugh at opensourceconnections.com (Eric Pugh) Date: Fri, 21 Sep 2007 14:43:59 -0400 Subject: [Backgroundrb-devel] Querying Autostart jobs.. Message-ID: Hi all, I am really liking the auto start stuff! One thing I notice is that I can't seem to query for them through the MiddleMan via the job_key... Is that the correct behavior? Or do I have a bug of some variety? thanks, Eric Pugh From gapeldoorn at wehkamp.nl Mon Sep 24 04:38:33 2007 From: gapeldoorn at wehkamp.nl (Ger Apeldoorn) Date: Mon, 24 Sep 2007 10:38:33 +0200 Subject: [Backgroundrb-devel] Trouble using backgroundrb Message-ID: <1190623113.18793.10.camel@localhost> Hi all, I'm a newbie to backgroundrb and am having trouble integrating it into my rails-app. I'm using namespaces to differentiate between the parts of my app. When I want to create a new worker, it seems that it cannot find the worker object. Here's my code: -------------------- controller app/passwd/index -------------------- class Passwd::IndexController < ApplicationController layout 'default' def index $subtitle = "AIX user inventory tool" end def createReport Passwdentry.delete_all User.delete_all session[:job_key] = MiddleMan.new_worker(:class => "passwd:get_passwds_worker", :args => "") end def get_progress if request.xhr? progress_percent = MiddleMan.get_worker(session[:job_key]).progress render :update do |page| page.call('progressPercent', 'progressbar', progress_percent) page.redirect_to( :action => 'done') if progress_percent >= 100 end else redirect_to :action => 'index' end end def done render :text => "De database is bijgewerkt" MiddleMan.delete_worker(session[:job_key]) end end --------------------lib/workers/get_passwds_worker.rb-------------------- # Put your code that runs your task inside the do_work method it will be # run automatically in a thread. You have access to all of your rails # models. You also get logger and results method inside of this class # by default. class Passwd::GetPasswdsWorker < BackgrounDRb::Worker::RailsBase attr_reader :progress def do_work(args) @progress = 0 @progressinterval = 100/System.count System.find_all.each do |sys| getAndParsePasswdFile(sys.name) @progress += @progressinterval end end def getAndParsePasswdFile(sys) output = %x[some command-line-magic ;)] output.each do |outputline| outputline = outputline.split(":") thisline = Passwdentry.new thisline.setvalues(outputline[0], sys, outputline[2]); thisline.save end end end Passwd::GetPasswdsWorker.register --------------------app/views/passwd/index/createReport.rhtml--------------------

De database wordt voorzien van de laatste data.

<%= periodically_call_remote(:url => {:action => 'get_progress'}, :frequency => 1) %> --------------------conf/backgroundrb.yml-------------------- --- :host: localhost :port: 2000 :rails_env: development :load_rails: true :worker_dir: lib/workers Your help is *very much* appreciated! Thanks, Ger Apeldoorn From gapeldoorn at wehkamp.nl Mon Sep 24 10:06:00 2007 From: gapeldoorn at wehkamp.nl (Ger Apeldoorn) Date: Mon, 24 Sep 2007 16:06:00 +0200 Subject: [Backgroundrb-devel] Trouble using backgroundrb In-Reply-To: <156c5bc40709240659yfbe8b3co114dea52879f3381@mail.gmail.com> References: <1190623113.18793.10.camel@localhost> <156c5bc40709240659yfbe8b3co114dea52879f3381@mail.gmail.com> Message-ID: <1190642760.18793.14.camel@localhost> Hi Tieg, Thanks a lot for your reply! Unfortunately, I'm not there yet.. After I adapt the new_worker call, this is the error I get: uninitialized constant Passwd So, it really doesnt know how to handle namespaces it appears. Can you see any way to get around that? If I generate the worker without the namespace, can I call it from within the passwd namespace? Thanks again, Ger. On Mon, 2007-09-24 at 09:59 -0400, Tieg Zaharia wrote: > I'm not sure if this is your problem, but I think you should include > two colons in the worker klass name, like this: > > ...new_worker(:class => "passwd::get_passwds_worker", :args => "")... > > Also, BackgrounDRb uses a method in the middleman.rb file called > worker_klass_constant(), from whence it derives the constant name. > This is the constant that BackgrounDRb will look for after passing > your class name to that method: > > "Passwd::getPasswdsWorker" > (whereas you want Passwd::GetPasswdsWorker) > > That might be a bug (or a feature enhancement if BDrb doesn't support > namespaced workers yet), so the right way would be to patch that > method. Orrr, you could just pass the real name of the worker in your > controller, like this.. > > session[:job_key] = MiddleMan.new_worker(:class => > "Passwd::GetPasswdsWorker", :args => {})... > > > -tieg > > > On 9/24/07, Ger Apeldoorn wrote: > Hi all, > > I'm a newbie to backgroundrb and am having trouble integrating > it into > my rails-app. I'm using namespaces to differentiate between > the parts of > my app. > > When I want to create a new worker, it seems that it cannot > find the > worker object. Here's my code: > > -------------------- controller app/passwd/index > -------------------- > class Passwd::IndexController < ApplicationController > layout 'default' > > def index > $subtitle = "AIX user inventory tool" > end > > def createReport > Passwdentry.delete_all > User.delete_all > session[:job_key] = MiddleMan.new_worker(:class => > "passwd:get_passwds_worker", :args => "") > end > > def get_progress > if request.xhr? > progress_percent = > MiddleMan.get_worker(session[:job_key]).progress > render :update do |page| > page.call('progressPercent', 'progressbar', > progress_percent) > page.redirect_to( :action => 'done') if > progress_percent >= 100 > end > else > redirect_to :action => 'index' > end > end > > def done > render :text => "De database is bijgewerkt" > MiddleMan.delete_worker(session[:job_key]) > end > end > > --------------------lib/workers/get_passwds_worker.rb-------------------- > # Put your code that runs your task inside the do_work method > it will be > # run automatically in a thread. You have access to all of > your rails > # models. You also get logger and results method inside of > this class > # by default. > class Passwd::GetPasswdsWorker < > BackgrounDRb::Worker::RailsBase > attr_reader :progress > def do_work(args) > @progress = 0 > @progressinterval = 100/System.count > System.find_all.each do |sys| > getAndParsePasswdFile(sys.name ) > @progress += @progressinterval > end > end > > def getAndParsePasswdFile(sys) > output = %x[some command-line-magic ;)] > output.each do |outputline| > outputline = outputline.split (":") > thisline = Passwdentry.new > thisline.setvalues(outputline[0], sys, outputline[2]); > thisline.save > end > end > end > Passwd::GetPasswdsWorker.register > > --------------------app/views/passwd/index/createReport.rhtml-------------------- >

De database wordt voorzien van de laatste data.

>
> <%= periodically_call_remote(:url => {:action => > 'get_progress'}, :frequency => 1) %> > > --------------------conf/backgroundrb.yml-------------------- > --- > :host: localhost > :port: 2000 > :rails_env: development > :load_rails: true > :worker_dir: lib/workers > > Your help is *very much* appreciated! > > Thanks, > Ger Apeldoorn > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > From gapeldoorn at wehkamp.nl Tue Sep 25 02:27:26 2007 From: gapeldoorn at wehkamp.nl (Ger Apeldoorn) Date: Tue, 25 Sep 2007 08:27:26 +0200 Subject: [Backgroundrb-devel] Trouble using backgroundrb In-Reply-To: <156c5bc40709240722u181835a9xe6fd8350317d23e4@mail.gmail.com> References: <1190623113.18793.10.camel@localhost> <156c5bc40709240659yfbe8b3co114dea52879f3381@mail.gmail.com> <1190642760.18793.14.camel@localhost> <156c5bc40709240722u181835a9xe6fd8350317d23e4@mail.gmail.com> Message-ID: <1190701647.18793.21.camel@localhost> Hi Tieg, Unfortunately, it is not that easy. I've tried your suggestions, but they didnt work. If I put the worker-class in the same file as the controller, I get 'uninitialized constant BackgrounDRb::Worker' instead of 'uninitialized constant Passwd'. Now, I've generated a non-namespaced worker, which gives the same results! (uninitialized constant GetPasswds) Shouldn't I include anything into environment.rb or something? Thanks again, Ger. On Mon, 2007-09-24 at 10:22 -0400, Tieg Zaharia wrote: > Hey Ger, > > This should be pretty easy. You just need to initialize the Module > name, which you could do like this: > > module Passwd > class GetPasswdsWorker > ... > end > end > > or you could initialize it and then wrap it like this: > > module Passwd end > class Passwd::GetPasswdsWorker > ... > end > > That should work, but is there any specific reason to namespace it? > Could you just call the class PasswdWorker? > > > -tieg > > On 9/24/07, Ger Apeldoorn wrote: > Hi Tieg, > > Thanks a lot for your reply! > > Unfortunately, I'm not there yet.. After I adapt the > new_worker call, > this is the error I get: > > uninitialized constant Passwd > > So, it really doesnt know how to handle namespaces it appears. > Can you > see any way to get around that? If I generate the worker > without the > namespace, can I call it from within the passwd namespace? > > Thanks again, > Ger. > > On Mon, 2007-09-24 at 09:59 -0400, Tieg Zaharia wrote: > > I'm not sure if this is your problem, but I think you should > include > > two colons in the worker klass name, like this: > > > > ...new_worker(:class => "passwd::get_passwds_worker", :args > => "")... > > > > Also, BackgrounDRb uses a method in the middleman.rb file > called > > worker_klass_constant(), from whence it derives the constant > name. > > This is the constant that BackgrounDRb will look for after > passing > > your class name to that method: > > > > "Passwd::getPasswdsWorker" > > (whereas you want Passwd::GetPasswdsWorker) > > > > That might be a bug (or a feature enhancement if BDrb > doesn't support > > namespaced workers yet), so the right way would be to patch > that > > method. Orrr, you could just pass the real name of the > worker in your > > controller, like this.. > > > > session[:job_key] = MiddleMan.new_worker (:class => > > "Passwd::GetPasswdsWorker", :args => {})... > > > > > > -tieg > > > > > > On 9/24/07, Ger Apeldoorn wrote: > > Hi all, > > > > I'm a newbie to backgroundrb and am having trouble > integrating > > it into > > my rails-app. I'm using namespaces to differentiate > between > > the parts of > > my app. > > > > When I want to create a new worker, it seems that it > cannot > > find the > > worker object. Here's my code: > > > > -------------------- controller app/passwd/index > > -------------------- > > class Passwd::IndexController < > ApplicationController > > layout 'default' > > > > def index > > $subtitle = "AIX user inventory tool" > > end > > > > def createReport > > Passwdentry.delete_all > > User.delete_all > > session[:job_key] = MiddleMan.new_worker(:class > => > > "passwd:get_passwds_worker", :args => "") > > end > > > > def get_progress > > if request.xhr? > > progress_percent = > > MiddleMan.get_worker(session[:job_key]).progress > > render :update do |page| > > page.call ('progressPercent', 'progressbar', > > progress_percent) > > page.redirect_to( :action => 'done') if > > progress_percent >= 100 > > end > > else > > redirect_to :action => 'index' > > end > > end > > > > def done > > render :text => "De database is bijgewerkt" > > MiddleMan.delete_worker(session[:job_key]) > > end > > end > > > > > --------------------lib/workers/get_passwds_worker.rb-------------------- > > # Put your code that runs your task inside the > do_work method > > it will be > > # run automatically in a thread. You have access to > all of > > your rails > > # models. You also get logger and results method > inside of > > this class > > # by default. > > class Passwd::GetPasswdsWorker < > > BackgrounDRb::Worker::RailsBase > > attr_reader :progress > > def do_work(args) > > @progress = 0 > > @progressinterval = 100/System.count > > System.find_all.each do |sys| > > getAndParsePasswdFile(sys.name ) > > @progress += @progressinterval > > end > > end > > > > def getAndParsePasswdFile(sys) > > output = %x[some command-line-magic ;)] > > output.each do |outputline| > > outputline = outputline.split (":") > > thisline = Passwdentry.new > > thisline.setvalues(outputline[0], sys, > outputline[2]); > > thisline.save > > end > > end > > end > > Passwd::GetPasswdsWorker.register > > > > > --------------------app/views/passwd/index/createReport.rhtml-------------------- > >

De database wordt voorzien van de laatste > data.

> >
> > <%= periodically_call_remote(:url => {:action => > > 'get_progress'}, :frequency => 1) %> > > > > > --------------------conf/backgroundrb.yml-------------------- > > --- > > :host: localhost > > :port: 2000 > > :rails_env: development > > :load_rails: true > > :worker_dir: lib/workers > > > > Your help is *very much* appreciated! > > > > Thanks, > > Ger Apeldoorn > > > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > From gapeldoorn at wehkamp.nl Wed Sep 26 10:53:58 2007 From: gapeldoorn at wehkamp.nl (Ger Apeldoorn) Date: Wed, 26 Sep 2007 16:53:58 +0200 Subject: [Backgroundrb-devel] Trouble using backgroundrb In-Reply-To: <156c5bc40709250901w444dc0a5r611437092c92d32f@mail.gmail.com> References: <1190623113.18793.10.camel@localhost> <156c5bc40709240659yfbe8b3co114dea52879f3381@mail.gmail.com> <1190642760.18793.14.camel@localhost> <156c5bc40709240722u181835a9xe6fd8350317d23e4@mail.gmail.com> <1190701647.18793.21.camel@localhost> <156c5bc40709250901w444dc0a5r611437092c92d32f@mail.gmail.com> Message-ID: <1190818438.5579.19.camel@localhost> Hi Tieg, Thanks for your help, I came a bit further.... :) I didnt need to add the loadpaths. Now, I've got another problem. In about 20% of the launched processes, the worker process dies instantly or it is not created at all. The MiddleMan.new_worker call returns the ID as it should, but a log message which is called on the first line in do_work doesnt appear. How might I make it more reliable? Thanks, Ger. On Tue, 2007-09-25 at 12:01 -0400, Tieg Zaharia wrote: > Hey Ger, > > I would just stick to the convention and keep the class in the file > "RAILS_ROOT/lib/workers/passwd_worker.rb". > > I can't remember if it was necessary or not, but I've also added load > paths to the plugin in my environment.rb file before: > config.load_paths += % > W( #{RAILS_ROOT}/vendor/plugins/backgroundrb/server > #{RAILS_ROOT}/vendor/plugins/backgroundrb/server/lib ) > > I don't think you need any special config though as long as you have > the plugin installed. Does that help? > > > Tieg > > > > > On 9/25/07, Ger Apeldoorn wrote: > Hi Tieg, > > Unfortunately, it is not that easy. I've tried your > suggestions, but > they didnt work. If I put the worker-class in the same file as > the > controller, I get 'uninitialized constant > BackgrounDRb::Worker' instead > of 'uninitialized constant Passwd'. > > Now, I've generated a non-namespaced worker, which gives the > same > results! (uninitialized constant GetPasswds) > > Shouldn't I include anything into environment.rb or something? > > Thanks again, > Ger. > > On Mon, 2007-09-24 at 10:22 -0400, Tieg Zaharia wrote: > > Hey Ger, > > > > This should be pretty easy. You just need to initialize the > Module > > name, which you could do like this: > > > > module Passwd > > class GetPasswdsWorker > > ... > > end > > end > > > > or you could initialize it and then wrap it like this: > > > > module Passwd end > > class Passwd::GetPasswdsWorker > > ... > > end > > > > That should work, but is there any specific reason to > namespace it? > > Could you just call the class PasswdWorker? > > > > > > -tieg > > > > On 9/24/07, Ger Apeldoorn < gapeldoorn at wehkamp.nl> wrote: > > Hi Tieg, > > > > Thanks a lot for your reply! > > > > Unfortunately, I'm not there yet.. After I adapt > the > > new_worker call, > > this is the error I get: > > > > uninitialized constant Passwd > > > > So, it really doesnt know how to handle namespaces > it appears. > > Can you > > see any way to get around that? If I generate the > worker > > without the > > namespace, can I call it from within the passwd > namespace? > > > > Thanks again, > > Ger. > > > > On Mon, 2007-09-24 at 09:59 -0400, Tieg Zaharia > wrote: > > > I'm not sure if this is your problem, but I think > you should > > include > > > two colons in the worker klass name, like this: > > > > > > ...new_worker(:class => > "passwd::get_passwds_worker", :args > > => "")... > > > > > > Also, BackgrounDRb uses a method in the > middleman.rb file > > called > > > worker_klass_constant(), from whence it derives > the constant > > name. > > > This is the constant that BackgrounDRb will look > for after > > passing > > > your class name to that method: > > > > > > "Passwd::getPasswdsWorker" > > > (whereas you want Passwd::GetPasswdsWorker) > > > > > > That might be a bug (or a feature enhancement if > BDrb > > doesn't support > > > namespaced workers yet), so the right way would be > to patch > > that > > > method. Orrr, you could just pass the real name of > the > > worker in your > > > controller, like this.. > > > > > > session[:job_key] = MiddleMan.new_worker (:class > => > > > "Passwd::GetPasswdsWorker", :args => {})... > > > > > > > > > -tieg > > > > > > > > > On 9/24/07, Ger Apeldoorn < gapeldoorn at wehkamp.nl> > wrote: > > > Hi all, > > > > > > I'm a newbie to backgroundrb and am having > trouble > > integrating > > > it into > > > my rails-app. I'm using namespaces to > differentiate > > between > > > the parts of > > > my app. > > > > > > When I want to create a new worker, it > seems that it > > cannot > > > find the > > > worker object. Here's my code: > > > > > > -------------------- controller > app/passwd/index > > > -------------------- > > > class Passwd::IndexController < > > ApplicationController > > > layout 'default' > > > > > > def index > > > $subtitle = "AIX user inventory tool" > > > end > > > > > > def createReport > > > Passwdentry.delete_all > > > User.delete_all > > > session[:job_key] = > MiddleMan.new_worker(:class > > => > > > "passwd:get_passwds_worker", :args => "") > > > end > > > > > > def get_progress > > > if request.xhr? > > > progress_percent = > > > > MiddleMan.get_worker(session[:job_key]).progress > > > render :update do |page| > > > page.call ('progressPercent', > 'progressbar', > > > progress_percent) > > > page.redirect_to( :action => > 'done') if > > > progress_percent >= 100 > > > end > > > else > > > redirect_to :action => 'index' > > > end > > > end > > > > > > def done > > > render :text => "De database is > bijgewerkt" > > > MiddleMan.delete_worker > (session[:job_key]) > > > end > > > end > > > > > > > > > --------------------lib/workers/get_passwds_worker.rb-------------------- > > > # Put your code that runs your task inside > the > > do_work method > > > it will be > > > # run automatically in a thread. You have > access to > > all of > > > your rails > > > # models. You also get logger and results > method > > inside of > > > this class > > > # by default. > > > class Passwd::GetPasswdsWorker < > > > BackgrounDRb::Worker::RailsBase > > > attr_reader :progress > > > def do_work(args) > > > @progress = 0 > > > @progressinterval = 100/System.count > > > System.find_all.each do |sys| > > > getAndParsePasswdFile( sys.name ) > > > @progress += @progressinterval > > > end > > > end > > > > > > def getAndParsePasswdFile(sys) > > > output = %x[some > command-line-magic ;)] > > > output.each do |outputline| > > > outputline = outputline.split (":") > > > thisline = Passwdentry.new > > > thisline.setvalues(outputline[0], > sys, > > outputline[2]); > > > thisline.save > > > end > > > end > > > end > > > Passwd::GetPasswdsWorker.register > > > > > > > > > --------------------app/views/passwd/index/createReport.rhtml-------------------- > > >

De database wordt voorzien van de > laatste > > data.

> > >
class="progress">
> > > <%= periodically_call_remote(:url => > {:action => > > > 'get_progress'}, :frequency => 1) %> > > > > > > > > > --------------------conf/backgroundrb.yml-------------------- > > > --- > > > :host: localhost > > > :port: 2000 > > > :rails_env: development > > > :load_rails: true > > > :worker_dir: lib/workers > > > > > > Your help is *very much* appreciated! > > > > > > Thanks, > > > Ger Apeldoorn > > > > > > > _______________________________________________ > > > Backgroundrb-devel mailing list > > > Backgroundrb-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > From eimorton at gmail.com Fri Sep 28 10:39:19 2007 From: eimorton at gmail.com (Erik Morton) Date: Fri, 28 Sep 2007 10:39:19 -0400 Subject: [Backgroundrb-devel] Workers sleeping habbits Message-ID: I'm having some issues with Workers dying after a period of several hours. Each worker runs a loop that asks Amazon SQS for work to do. If there is a message in the queue the work is completed (image processing, etc...); if there is no message the worker will sleep for X seconds (sleep 10, etc...). I've noticed that the workers will frequently exhibit two negative behaviors: A) stop asking for requests, but still exist as a process; or B) die completely (no more process) with no errors reported in either log file. I made a simple DeathWorker last night to try to find out exactly *when* death occurs. The worker will log when it asks for a message, when it goes to sleep, and when it wakes up. Like so: 09/27/2007 13:23:05 (7673) DeathWorker: SQSMiddleMan.next_message (:death_worker) 09/27/2007 13:23:05 (7673) DeathWorker: No message. Going to sleep. 09/27/2007 13:23:34 (7673) DeathWorker: Done sleeping. The above log entries show the normal course of operation for the DeathWorker: look for a message, almost immediately report that there is no message and go to sleep for 10 seconds. Wake up and log that you are awake. As you can see there was more than 10 seconds between logging that you were going to sleep and then waking up. Is it possible that the log synchronization that occurs through the logging worker causes the delay? This happened later in the night: 09/27/2007 13:23:38 (7673) DeathWorker: No message. Going to sleep. 09/27/2007 13:27:15 (7673) DeathWorker: Done sleeping. Almost four minutes of sleep when I call sleep 10. Interesting. Later in the night: 09/27/2007 13:50:13 (7673) DeathWorker: No message. Going to sleep. 09/27/2007 19:29:36 (7673) DeathWorker: Done sleeping. Wow! Almost 6 hours of sleeping! After that nap the worker went for another 10 minutes or so and then the process actually died, with no errors reported in the log. Any idea what is going on? How can I debug this issue? Every time I try to attach to the oversleeping process with GDB it segfaults. Thanks in advance! Erik From joevandyk at gmail.com Fri Sep 28 12:26:18 2007 From: joevandyk at gmail.com (Joe Van Dyk) Date: Fri, 28 Sep 2007 09:26:18 -0700 Subject: [Backgroundrb-devel] Couple questions about backgroundrb Message-ID: So, what's the status of this project? I'm a little confused. The documentation at http://backgroundrb.rubyforge.org seems out of date. It refers to http://svn.devjavu.com/backgroundrb/tags/release-0.2.1, which doesn't work. All I want is a way to easily set up tasks that should run periodically. Some stuff should run every 10 seconds, some stuff once a day, etc. The tasks will need to access Rails models and save data. There's maybe 10 or so different periodic tasks. What version should I be using? trunk? 0.2.1? Do you guys need a project hosting space? How can I help? Joe From joevandyk at gmail.com Fri Sep 28 12:38:17 2007 From: joevandyk at gmail.com (Joe Van Dyk) Date: Fri, 28 Sep 2007 09:38:17 -0700 Subject: [Backgroundrb-devel] Couple questions about backgroundrb In-Reply-To: References: Message-ID: cron only runs once a minute, some tasks need more frequent updates. Also, would prefer not to have to set up cron -- it's a pain to make sure that the environment gets set up properly. And then the configuration is kept in multiple places. On 9/28/07, Chris Hall wrote: > cron + script/runner > > On 9/28/07, Joe Van Dyk wrote: > > So, what's the status of this project? I'm a little confused. The > > documentation at http://backgroundrb.rubyforge.org seems out of date. > > It refers to http://svn.devjavu.com/backgroundrb/tags/release-0.2.1, > > which doesn't work. > > > > All I want is a way to easily set up tasks that should run > > periodically. Some stuff should run every 10 seconds, some stuff once > > a day, etc. The tasks will need to access Rails models and save data. > > There's maybe 10 or so different periodic tasks. > > > > What version should I be using? trunk? 0.2.1? Do you guys need a > > project hosting space? How can I help? > > > > Joe > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > From epugh at opensourceconnections.com Fri Sep 28 12:44:06 2007 From: epugh at opensourceconnections.com (Eric Pugh) Date: Fri, 28 Sep 2007 12:44:06 -0400 Subject: [Backgroundrb-devel] Couple questions about backgroundrb In-Reply-To: References: Message-ID: I agree with the -1 of cron.. it is a slippery slope.. You think "Oh, I'll just cron this one job", and before you know it you have 5 or 10 of them.. And no way to monitor them from the webapp... So you start communicating via database tables.. And then you deploy on a new server, and forget to check the crontab because it's under some sort of special user account! BackgroundRB is much better.. But I agree that it needs another release.. I have a version that isn't trunk latest that works great for me, but when I tried trunk I had lots of errors so went back to what worked. Joe, I can zip it and send it to you.. Not sure what "version" of backgroundrb it is though... Eric On Sep 28, 2007, at 12:38 PM, Joe Van Dyk wrote: > cron only runs once a minute, some tasks need more frequent updates. > Also, would prefer not to have to set up cron -- it's a pain to make > sure that the environment gets set up properly. And then the > configuration is kept in multiple places. > > On 9/28/07, Chris Hall wrote: >> cron + script/runner >> >> On 9/28/07, Joe Van Dyk wrote: >>> So, what's the status of this project? I'm a little confused. The >>> documentation at http://backgroundrb.rubyforge.org seems out of >>> date. >>> It refers to http://svn.devjavu.com/backgroundrb/tags/release-0.2.1, >>> which doesn't work. >>> >>> All I want is a way to easily set up tasks that should run >>> periodically. Some stuff should run every 10 seconds, some stuff >>> once >>> a day, etc. The tasks will need to access Rails models and save >>> data. >>> There's maybe 10 or so different periodic tasks. >>> >>> What version should I be using? trunk? 0.2.1? Do you guys need a >>> project hosting space? How can I help? >>> >>> Joe >>> _______________________________________________ >>> 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 ----------------------------------------------------- Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com From joevandyk at gmail.com Fri Sep 28 12:51:46 2007 From: joevandyk at gmail.com (Joe Van Dyk) Date: Fri, 28 Sep 2007 09:51:46 -0700 Subject: [Backgroundrb-devel] Couple questions about backgroundrb In-Reply-To: References: Message-ID: That would be great if you could email the working version to me. Or post it somewhere public. On 9/28/07, Eric Pugh wrote: > I agree with the -1 of cron.. it is a slippery slope.. You think > "Oh, I'll just cron this one job", and before you know it you have 5 > or 10 of them.. And no way to monitor them from the webapp... So > you start communicating via database tables.. > > And then you deploy on a new server, and forget to check the crontab > because it's under some sort of special user account! BackgroundRB > is much better.. > > But I agree that it needs another release.. I have a version that > isn't trunk latest that works great for me, but when I tried trunk I > had lots of errors so went back to what worked. Joe, I can zip it > and send it to you.. Not sure what "version" of backgroundrb it is > though... > > Eric > > > > On Sep 28, 2007, at 12:38 PM, Joe Van Dyk wrote: > > > cron only runs once a minute, some tasks need more frequent updates. > > Also, would prefer not to have to set up cron -- it's a pain to make > > sure that the environment gets set up properly. And then the > > configuration is kept in multiple places. > > > > On 9/28/07, Chris Hall wrote: > >> cron + script/runner > >> > >> On 9/28/07, Joe Van Dyk wrote: > >>> So, what's the status of this project? I'm a little confused. The > >>> documentation at http://backgroundrb.rubyforge.org seems out of > >>> date. > >>> It refers to http://svn.devjavu.com/backgroundrb/tags/release-0.2.1, > >>> which doesn't work. > >>> > >>> All I want is a way to easily set up tasks that should run > >>> periodically. Some stuff should run every 10 seconds, some stuff > >>> once > >>> a day, etc. The tasks will need to access Rails models and save > >>> data. > >>> There's maybe 10 or so different periodic tasks. > >>> > >>> What version should I be using? trunk? 0.2.1? Do you guys need a > >>> project hosting space? How can I help? > >>> > >>> Joe > >>> _______________________________________________ > >>> 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 > > ----------------------------------------------------- > Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > From epugh at opensourceconnections.com Fri Sep 28 13:27:27 2007 From: epugh at opensourceconnections.com (Eric Pugh) Date: Fri, 28 Sep 2007 13:27:27 -0400 Subject: [Backgroundrb-devel] Couple questions about backgroundrb In-Reply-To: References: Message-ID: I will email you my setup. Anyone else wants it, feel free to hollar.... I don't have readily available web server access where I am..... Eric On Sep 28, 2007, at 12:51 PM, Joe Van Dyk wrote: > That would be great if you could email the working version to me. Or > post it somewhere public. > > > > > > On 9/28/07, Eric Pugh wrote: >> I agree with the -1 of cron.. it is a slippery slope.. You think >> "Oh, I'll just cron this one job", and before you know it you have 5 >> or 10 of them.. And no way to monitor them from the webapp... So >> you start communicating via database tables.. >> >> And then you deploy on a new server, and forget to check the crontab >> because it's under some sort of special user account! BackgroundRB >> is much better.. >> >> But I agree that it needs another release.. I have a version that >> isn't trunk latest that works great for me, but when I tried trunk I >> had lots of errors so went back to what worked. Joe, I can zip it >> and send it to you.. Not sure what "version" of backgroundrb it is >> though... >> >> Eric >> >> >> >> On Sep 28, 2007, at 12:38 PM, Joe Van Dyk wrote: >> >>> cron only runs once a minute, some tasks need more frequent updates. >>> Also, would prefer not to have to set up cron -- it's a pain to make >>> sure that the environment gets set up properly. And then the >>> configuration is kept in multiple places. >>> >>> On 9/28/07, Chris Hall wrote: >>>> cron + script/runner >>>> >>>> On 9/28/07, Joe Van Dyk wrote: >>>>> So, what's the status of this project? I'm a little confused. >>>>> The >>>>> documentation at http://backgroundrb.rubyforge.org seems out of >>>>> date. >>>>> It refers to http://svn.devjavu.com/backgroundrb/tags/ >>>>> release-0.2.1, >>>>> which doesn't work. >>>>> >>>>> All I want is a way to easily set up tasks that should run >>>>> periodically. Some stuff should run every 10 seconds, some stuff >>>>> once >>>>> a day, etc. The tasks will need to access Rails models and save >>>>> data. >>>>> There's maybe 10 or so different periodic tasks. >>>>> >>>>> What version should I be using? trunk? 0.2.1? Do you guys need a >>>>> project hosting space? How can I help? >>>>> >>>>> Joe >>>>> _______________________________________________ >>>>> 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 >> >> ----------------------------------------------------- >> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com >> >> >> >> _______________________________________________ >> 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 ----------------------------------------------------- Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com From joevandyk at gmail.com Fri Sep 28 14:18:18 2007 From: joevandyk at gmail.com (Joe Van Dyk) Date: Fri, 28 Sep 2007 11:18:18 -0700 Subject: [Backgroundrb-devel] Couple questions about backgroundrb In-Reply-To: References: Message-ID: So, If I want to set up multiple running processes that do stuff, do I use the MiddleMan stuff? The documents are confusing me. What should the worker classes inherit from if they need to access rails models? On 9/28/07, Eric Pugh wrote: > I agree with the -1 of cron.. it is a slippery slope.. You think > "Oh, I'll just cron this one job", and before you know it you have 5 > or 10 of them.. And no way to monitor them from the webapp... So > you start communicating via database tables.. > > And then you deploy on a new server, and forget to check the crontab > because it's under some sort of special user account! BackgroundRB > is much better.. > > But I agree that it needs another release.. I have a version that > isn't trunk latest that works great for me, but when I tried trunk I > had lots of errors so went back to what worked. Joe, I can zip it > and send it to you.. Not sure what "version" of backgroundrb it is > though... > > Eric > > > > On Sep 28, 2007, at 12:38 PM, Joe Van Dyk wrote: > > > cron only runs once a minute, some tasks need more frequent updates. > > Also, would prefer not to have to set up cron -- it's a pain to make > > sure that the environment gets set up properly. And then the > > configuration is kept in multiple places. > > > > On 9/28/07, Chris Hall wrote: > >> cron + script/runner > >> > >> On 9/28/07, Joe Van Dyk wrote: > >>> So, what's the status of this project? I'm a little confused. The > >>> documentation at http://backgroundrb.rubyforge.org seems out of > >>> date. > >>> It refers to http://svn.devjavu.com/backgroundrb/tags/release-0.2.1, > >>> which doesn't work. > >>> > >>> All I want is a way to easily set up tasks that should run > >>> periodically. Some stuff should run every 10 seconds, some stuff > >>> once > >>> a day, etc. The tasks will need to access Rails models and save > >>> data. > >>> There's maybe 10 or so different periodic tasks. > >>> > >>> What version should I be using? trunk? 0.2.1? Do you guys need a > >>> project hosting space? How can I help? > >>> > >>> Joe > >>> _______________________________________________ > >>> 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 > > ----------------------------------------------------- > Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > From =?UTF-8?Q?=E8=91=89=E5=BF=97=E7=AB=8B_YIP_Chi_Lap_ Sun Sep 30 00:00:34 2007 From: =?UTF-8?Q?=E8=91=89=E5=BF=97=E7=AB=8B_YIP_Chi_Lap_ (=?UTF-8?Q?=E8=91=89=E5=BF=97=E7=AB=8B_YIP_Chi_Lap_) Date: Sun, 30 Sep 2007 12:00:34 +0800 Subject: [Backgroundrb-devel] Patch: background_tasks.rake Message-ID: <986DFDB5-F404-45C7-BA96-D8B0290D40D6@gmail.com> Hi, * Background I develop rails app with backgrounDRb where one of its parent folders has a space in its name. * Problem rake backgroundrb:start and rake backgroundrb:stop do not work * Analysis This is because the line for start and stop in backgroundrb_tasks.rake do not quote #{scripts_src} * Patch Quote the #{scripts_src} in the two lines so they become `"#{scripts_src}"/start -d` and `"#{scripts_src}"/stop` A patch file and the updated backgroundrb_tasks.rake are included for your reference. -------------- next part -------------- A non-text attachment was scrubbed... Name: backgroundrb_tasks.rake.patch Type: application/octet-stream Size: 144 bytes Desc: not available Url : http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070930/f632269e/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: backgroundrb_tasks.rake Type: application/octet-stream Size: 2545 bytes Desc: not available Url : http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070930/f632269e/attachment-0003.obj -------------- next part -------------- Regards, Beta.