similar to: disabling backgroundrb_debug.log

Hi, I''m using backgroundrb 0.2.1 and having problem with worker processes staying around when the rails application does not explicitly delete them. Is there a way to automatically delete the worker processes when it has completed the job? Also does killing the process manually (using kill command) harm the backgroundrb server? I have some occasions where the backgroundrb server just

Hi, I am pushing some updates and fixes that addresses much of the issues that we talked about since last couple of days. 1. Use configuration option :debug_log: false to disable backgroundrb_debug.log. 2. As shown below, use lazy_load option to disable aggressive loading of models ( and somewhat stupid too). 3. MiddleMan.delete_worker(:worker => :foo_worker) will now ABORT the worker, it

Hi all, I''ve got the error below in my backgroundrb_debug.log. I''ve tried to reproduce the error in the development environment, but the only way I can get the same thing is by calling ask_work with a bogus worker name. Calling it with the production code causes no error. Here''s an example of what the code calls: MiddleMan.ask_work(:worker => :agronomy_worker,

Can anyone explain why BackgrounDRb is switching form DRb to SMTP protocol? That seems like a lot of overhead to add to the messaging back and forth? Orion

I''m getting the following error (when doing script/backgroundrb start) on my local machine, which is running os x 10.4.11. However, it works just fine on my linux server. RAILS_ROOT/vendor/plugins/backgroundrb/lib/../framework/nbio.rb:64:in `dump_object'': undefined method `write_nonblock'' for #<UNIXSocket: 0x135b5f4> (NoMethodError) I just grabbed the

Hi, just updated backgroundrb to release 1.0.1 and am getting this error when trying to start backgroundrb. vendor/plugins/backgroundrb/framework/core.rb:18: uninitialized constant Packet::ClassHelpers (NameError) Just updated from r298 where everything was working fine. If I comment out the offending line then backgroundrb starts but I can''t connect to it from my app. Anyone have any

I''m running the latest from svn (rev 285). I''ve been having a problem launching a process repeatedly. What happens is that I get a debug message "some read error" and then the worker refuses to run again. I''ve stripped my worker down to just doing a puts and it still happens. Like the other threads I want to launch my workers as needed, however I get the

Hi, A pre-release version of backgroundrb is available now from svn. Download it from here: http://svn.devjavu.com/backgroundrb/branches/version099/ Since this release marks significant migration from existing practices, i intend to keep trunk untouched for a while. There are no install scripts, but you should copy "backgroundrb" file from script directory of plugin to script

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

Hello, Does reload_on_schedule force the worker to be reloaded even if it is already running? Or does it just load the worker if its not running when the schedule fires? I want to load the worker at the scheduled time if its not running, but I don''t want to reload the worker if its already running. Make sense? Thanks, Scott

I''m trying to run a single worker that could perform a periodic task for a given user. >From a controller, I imagine something like: def start_job MiddleMan.ask_work(:worker => :foo_worker, :worker_method => :perform_task, :data => { :user_id = current_user.id }) end def check_job @status = MiddleMan.ask_status(:worker => :foo_worker)[current_user.id] end

Hi, Is it possible to start a worker with job_key and then ask_status of that specific worker with the job_key? MiddleMan.ask_work(:worker => :auth_worker, :job_key=>''1'', :worker_method => :auth) and then MiddleMan.ask_status(:worker => :auth_worker, :job_key=>''1'') >From my testing of the new backgroundrb, asking status using job key

I''m working on an application that does extensive database searching. These searches can take a long time, so we have been working on moving the searches to a backgroundrb worker task so we can provide a sexy AJAX progress bar, and populate the search results as they are available. All of this seems to work fine until the size of the search results gets sufficiently large, when we start

Hi , If you are following commits, I have pushed following changes: 1. Now, you can specify :environment option in config file to load production environment and stuff. 2. Exeptions that were exposed to the user has been changed to BdrbConnError if rails is not able to connect to bdrb server. 3. loading mechanism has been changed, so remove backgroundrb script from your backgroundrb directory

Hi, Ok, As i promised.. I am working on new version of BackgrounDRB, which is getting close and will be out soon. I need some feedback from you guys. So, please reply back. The code has changed significantly and its no longer using DRB. But I will keep the name BackgroundRb. Ok, in new API, a worker looks like this: require "net/smtp" require "guid" class NewsletterWorker

What does the method query_all_workers() do? There is no documentation on what this method returns (1.0.1 version). Orion -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080118/9f9b8112/attachment.html

I noticed that backgroundrb does some kind of process queueing now? When I pounded the server to create 1000 workers, there are always only around 30-40 processes running at a time, which is good :) Is there some configuration for adjusting the max process? - reynard -------------- next part -------------- An HTML attachment was scrubbed... URL:

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:

Sorry for attaching patches in emails to the mailing list, but I''m still unable to login to Devjavu for Backgroundrb (I''m able to login just fine for Merb''s Devjavu and submitted a ticket successfully). Anyway, I encountered a bug when trying to #ask_status of a worker before it''s run (or rather, before its result_hash has been set to something). Not sure why

Hey guys, I was playing with the cron trigger, and I noticed that wday is not honored. Looking at the code confirms this. Has anyone else seen this? Thanks Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20071217/44d3a8a6/attachment.html