similar to: BackgrounDRb 0.2.0 Release! Complete rewrite.

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

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

Hi Folks, I am glad to announce 1.0 release of BackgrounDRb. This would be a major release since 0.2 release of BackgrounDRb. Here is a brief summary of changes: - BackgrounDRb is DRb no longer. It makes use of EventDriven network programming library packet ( http://packet.googlecode.com ). - Since we moved to packet, many nasty thread issues, result hash corruption issues are totally

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 #

Hi, pardon if this is a duplicate mail, I forgot to click the subscription link the first time around. I''ve been using backgroundrb for a while now (older version) and I''ve had so many headaches because of it that I began looking for a replacement technology. And then I saw the new and shiny backgroundrb website, looking good! Initially I used the version maintained by

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

Hi there, Backgroundrb is working pretty well for me but I have a job that launches two of the same job, apparently a minute(?) apart from each other. Should this be happening if I have repeat interval enabled with a job_key? It seems like it should wait until the job is finished before launching a new instance. --Backgroundrb_schedules.yml-- city_updater: :class: :city_updater_worker

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

Hi Folks, BackgrounDRb is a Ruby job server and scheduler. Its main intent is to be used with Ruby on Rails applications for offloading long-running tasks. Since a Rails application blocks while serving a request it is best to move long-running tasks off into a background process that is divorced from http request/response cycle. This new release of BackgrounDRb is also modular and can be used

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

We ran into some problems accessing a freshly created worker, and had to insert a sleep of 1 second to get it to work. It looks like Ezra and skaar already know this: from middleman.rb: # HACK: there is a race in the worker/slave creation, we # currently need to sleep between create. sleep 0.1 You might want to increase it to 1 second for those of us on slowly mac books.

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

Is it really a hash? As in, can I pass it into a method that a worker is calling so that, for example, a method in my ActiveRecord that''s actually doing the work? Really liking the new code. Does rubyforge or devjavu have the rdocs anywhere? -- Joshua Warchol Code Poet, Zaadz Inc. http://joshua.zaadz.com/

Hey all, Been reading through all the old posts (and the docs) to familiarize myself but I still feel a bit lost. I''m on trunk and am having a bit of a hard time knowing where to start with the particular I''m trying to solve. So far, I''ve downloaded backgroundrb, done the basic rails setup, created my worker and started it using `script/backgroundrb start`.

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

Can a worker kill themselves when they''re ''done''? Or do I have to do that either from the controller or the worker manager? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061023/11dd429c/attachment.html

Hi, I''m using backgroundrb but I have 2 problems with it. First is when I launch a thread Toto from the do_work method. Toto can''t access to a class variable defined before... (undefined method `+'' for nil:NilClass) I suspect that thread is launched when backgroundrb start but the worker not .. My code is : class MonWorker < BackgrounDRb::Worker::RailsBase

Hello - I am observing that calls to MiddleMan.worker return only after the worker has completed its work. This puzzles me, and I presume that I am doing something wrong. Can anyone make suggestions? Snippets from my code are: class ReportController < SecurityController ... def create_xml_report(report,start_time) constraints = get_constraints(report,start_time,false)

Ok two things that bug me 1) http://backgroundrb.devjavu.com/projects/backgroundrb/ticket/48 i thought i''ll just post ticket link - but well - it''s strange 2) when i switch base class from RailsBase to Base i can''t access MiddleMan - i get error NameError: uninitialized constant MiddleMan from (drbunix:///tmp/backgroundrbunix_localhost_2999)

Hi! I''m using the latest&greatest backgroundrb with rails 2.0.2 on ubuntu dapper. I''ve made an app that lets you run a query on several servers at once, which are selected at runtime. Therefore, for each server that is selected, I spawn a new worker and assign its work. After everything is completed, the workers are deleted. I often get this error: