similar to: backgroundrb launches concurrent instances of same job

Hi I have previously used railscron for server-side manipulation of the database but had a heap of trouble working with it. BackgrounDRB was suggested to me by a friend. I upload some files via acts_as_attachment and these go lie in a dir structure that i desire. What I want from the background process is to periodically (not user initiated) do some file-structure manipulation i.e. I want to

I am sure..again I am missing something, but I am trying to start a worker, when backgroundrb starts and it doesn''t seem to work. Here is my config/backgroundrb_schedules.yml file: feed_worker: class: feed_worker job_key: feed_worker_key worker_method: do_work trigger_args: repeat_interval: 20.minutes I even tried this from Rails controller: # def start_feed_worker #

I''m running the latest backgroundrb mainly for scheduled tasks support. As per the documentation I created the backgroundrb_schedules.yml with the following: simple_label: :class: :document_sorter_worker :worker_method: :do_work :job: :bleh :trigger_args: :start: <%= Time.now + 5.seconds %> :end: <%= Time.now + 10.minutes :repeat_interval: 1.minute Under

Hello Folks- I am really happy to announce the release of BackgrounDRb 0.2.0 . This is a complete rewrite and re-architecture of this codebase. I want to thank skaar for all of his hard work. I put out a call for help with the new architecture and skaar stepped up bigtime. I had already written the new scheduler and cron compatible syntax and moved to multi process architecture. But he

Hi gang, Thanks to other help I''ve gotten on this list, I''ve got backgroundrb up and running using postgres alongside my rails app. I''ve designed the system to have several eternally-running workers that periodically poll the database to see if there''s any work for them to do, and set things up in the config file to make them restart quickly if any of them

We have a fairly expensive task that we''d rather not schedule too many instances of in parallel. Couldn''t get pool_size to limit the amount of workers, and I figure that''s hardly optimal anyway, so would like to have the work queued up for a single named worker instead, running as soon as possible. Using MiddleMan.schedule_worker() with :job_key does start off a

I''ve got some workers that I want to have running all the time. Right now I''m just launching them manually, by requesting a special page in my rails app that includes lines like: MiddleMan.new_worker(:class=> :receiver, :job_key=>:r, :args=>{:sleep_time=>10}) This strikes me as a really weak way to fire up my workers. I basically want to automate things so

Hi, I have backgroundrb running to decouple the execution of massive business logic from an ActionWebservice request. The service is designed to take some configuration parameters and fire a lot of background workers to do the requested work. Due to performance reasons I want to limit the number of workers to a maximum number of 30. But when I start a configuration that requires for example

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

Hey Greg- Yes I am sorry, the new architecture uses fork and named pipes and a bunch of unix stuff to do its magick. Now you may be able to port it to qwork on windows, but I don''t think it is possible :( I''m really sorry about this but I need this thing to be as robust and solid as it can be and in the end windows isn''t compatible. Now you may be able to

There is a line in the backgroundrb codebase: sleep 0.1 # TODO this is dangerous; could skip over some jobs Could this explain why my scheduler stops triggering? It only seems to work for about 12 - 24 hours before schedules are being skipped... Once I changed the times to using cron trigger in backgroundrb_schedules.yml and set the times to every 37th and 59th minute of the hour, instead of

Hello all, i just started using backgroundrb and i really like it a lot so far. I finally succeeded in setting up version 0.21 and the examples from the readme run fine. Now i do not want to create and delete my worker anytime i want it to do something but call repeatedly a method with arguments. There is a arg_method defined in the readme so i guess this is a feasible way to procede.

So disregard this question. I followed Mason Hale''s suggestion that I pass in some worker_args and all is well in the scheduler.yml file. Brian _____ From: Brian Lucas [mailto:blucasCO at gmail.com] Sent: Thursday, February 15, 2007 2:49 PM To: ''backgroundrb-devel at rubyforge.org'' Subject: new syntax for autostart and repeat Hello: I''m a

The new backgroundrb seemed to me to be markedly slower than the old one. So, I ran a "side-by-side" comparison test using a worker that I had written which parses a CSV file and loads the results into a database. The results? The latest version appears to take twice as long to run the same code as the previous version. Has anyone else experienced speed issues with the new

Hi, I''m using backgroundrb to get RSS feeds and pass them back to the controller. I''m using the Ruby RSS library to parse the feed, which returns an RSS object. After that I pass the object into the results hash, but that''s when this error occurs. Basically, this is what I have: rss = RSS::Parser.parse(response.body) results[:feed] = rss # error! 20061120-15:46:19

Hi I just tried to move my project to rails 1.2.1 on my locomotive development setup. It seems that backgroundrb is not willing to start up anymore. If I switch locomotive back to 1.1.6, everthing is fine. This is the error I get while attempting to start backgroundrb: /Applications/Locomotive2/Bundles/standardRailsJan2007.locobundle/

I have the next including files structure : - controller fileaA.rb including line (#8): require "fileB"... - /lib/fileB.rb with main header: load ''backgroundrb/worker.rb'' load ''backgroundrb/ worker_rails.rb'' class FileB <

Hi, I''m using backgroundrb 0.2.1 in a production environment and for most parts I''m very happy. We are using it to do some heavy video editing on the server side and it works great except that under, what seems heavy load the below problem happens intermittently. The problem has only happened 5 times out of over 500 runs by our backgroundrb worker. This is the code in our

I''m just getting back to looking at backgroundrb after a long hiatus since June. I''m looking at creating some workers but I''m a bit stuck as to how I should write tests for them. What''s the recommended approach for unit testing of workers? The project will ultimately be used by a Rails app but I''m comfortable developing the worker code as a

so i have an after_create method on my track model that kicks off a background process that converts an mp3 to a swf. this is working fine locally on my machine, but upon moving it to my production server, i am getting the following error. I''ve only been using backgroundRB for like 48 hours, so i''m not really sure what this means or where to go. any ideas?