similar to: Minor warnings since 296

I''m working on upgrading my app to the latest version of backgroundrb. Everything went find until I tried to execute my tasks. Here is my simple worker for testing: class MscWorker < BackgrounDRb::MetaWorker set_worker_name :msc_worker def create(args = nil) # this method is called, when worker is loaded for the first time end # Send a message to everyone def

I recently switched over to v1.0, and things are rolling along pretty well. However, one thing that has always been a little confusing to me is knowing when to use thread_pool. Since most of my bgrb workers are called from my web app to process rather than being scheduled, I''m using the thread_pool for every call. Unfortunately, that means that I have to split up workers by how many

I have a previous question regarding long tasks and the thread_pool (sorry for the dup, I didn''t see the first go through). To try and track things down, I made a change based on a suggestion found in the archives. I moved my import contacts worker to its own file and set the pool_size to 1. class ImportContactsWorker < BackgrounDRb::MetaWorker set_worker_name

I''m having some trouble with using brb for polling for work. Basically, what I want to do is update the state of a record and have brb notice and start a process. I do not want to call ask_work for each process because there may be several places where the object''s state is changed, and I only want to process once. Plus, I can schedule things better this way. My first thought

I use backgroundrb for many long tasks in my system, but I''m having issues with one in particular. Two large tasks for me are importing people and updating companies. def import_contacts(args = nil) thread_pool.defer(args) do |job_id| begin job = ImportJob.find(job_id) job.process_job rescue => err logger.error "MscWorker#import_contacts

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

is there an easy way to disable logging to backgroundrb_debug.log? Regards - reynard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080102/195dee18/attachment.html

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

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

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

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

Hi, I am trying to get the scheduling to work with my RoR application. How do I determine what version of backgroundrb I have configured? When I try to invoke??? rake backgroundrb:setup? , it fails. Thanks for the help. Linda

Hi All, When I add the line ''reload_on_schedule true'' to my worker, my tests will no longer run with the following exception: Starting ferret DRb server.../Users/revelation/projects/revelation-project/config/../lib/workers/alert_worker.rb:3: undefined method `reload_on_schedule'' for AlertWorker:Class (NoMethodError) class AlertWorker < BackgrounDRb::MetaWorker

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

Hi, I would like to use backgroundrb inside a story, been trying to set this up for a while, but I think the only solution is to use fixture files and unit testing. The problem is that every time I call a new worker, the test database gets wiped out, and only has available the records in fixture files. Instead, it would be great if the test database maintains its state throughout the

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