similar to: delete_worker doesn''t kill the thread?

I noticed in the BackgroundRB class in the delete_worker method there is a line: if @jobs[key].respond_to? :thread For some reason this is returning false for me, it gets down to this line and returns false, not killing the thread. Any idea why this is returning false? Thanks for your help. Thank You, Ben Johnson E: bjohnson at contuitive.com -------------- next part -------------- An

Folks- I just commited another revision of the plugin. Nothing huge in this update but some extra features. Acl lists are now configurable in the config file. So you will want to blow away and recreate your config file again. Thanks to Georg Friedrich for this. And I applied Gunter Ladwig''s patch for singleton worker classes. These are workers that only have one instance of

I am pretty confident that mailers do not work in backgroundrb. Can anyone confirm this? Because when I try to do Notifier.deliver_some_method I get an error saying it cant find the templates for my email. The funny thing is that when I run script/ runner Notifier.deliver_some_method it works just fine. Any ideas? Thank You, Ben Johnson E: bjohnson at contuitive.com O: 800-341-6826 M:

OK I know whats happening. Your while loop completes and calls kill on the worker before your task_progress controller method ever gets called> So the worker is deleted and when you try to access it from rails you get an error because there is no longer a worker at that job key. The kill method is meant to be used within a worker that you fire and forget. If you want to get the

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

I thought I could delete a busy worker by calling MiddleMan.delete_worker, but doesn''t seem to end. I believe this was possible in 0.2, is it not in 1.0? thanks, Zach -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080103/0c701f29/attachment.html

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 <

I have workers that need to be created when I run rake backgroundrb:start. Where do I put this code? Thanks for your help. Thank You, Ben Johnson E: bjohnson at contuitive.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060731/d201c052/attachment.html

Since MiddleMan is an uninitialized constant in a worker how do you create new workers inside a worker? Thank You, Ben Johnson E: bjohnson at contuitive.com O: 800-341-6826 M: 817-229-4258 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060731/75a77fa6/attachment-0001.html

Hi, it would be nice to be able to specify workers as singletons. By this I mean that every call to the new_worker method returns the same instance of said worker. This can be done transparently either by adding a new argument to new_worker (something like :singleton => true) or adding a new method, like I did in my installation of BackgrounDrb: def get_worker_by_class(klass)

If there is an exception raised in my worker I rescue it and throw it into the log. This is decent, but it would really help to find out more information. Like the line number, the stack trace, etc. Is this possible? Thanks for your help. Thank You, Ben Johnson E: bjohnson at contuitive.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

I need to know what controller and action the user is currently in to do various things in my layouts/application.rhtml file. Isn''t there is a better way than: <% if params[:controller] == "whatever" && params[:action] == "whatever" %>some html<% end %> I know in the controllers you can just use controller_name, but that is not provided

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

Friends- I''m happy to annouce the first alpa release of BackgrounDRb. This is a small framework for managing long running background tasks that allows for ajax progress bars and more. It also serves as an Application wide cache and context store for when you need something like sessions but shared between users and multiple backend processes like fcgi''s or mongrels.

Hi, First, thanks for the plugin. Sorry if this is not strictly a backgroundrb issue but I thought others on this list might have come across this problem. I''m trying to run the test that comes via the worker generator. The test works fine when running ''rake test_functional'', but when the tests are run by autotest I get "uninitialized constant BackgrounDRb"

Howdy Folks- I''m happy to announce a new release of BackgrounDRb! I have added quite a few new features and included some nice patches from folks on the list. $ script/plugin install svn://rubyforge.org//var/svn/backgroundrb All of the code now stays within the plugin and the start and stop scripts are now just stubs. This makes it easier to tweak or figure out how it works.

I have concluded that it is impossible to get this background process stable. I am out of ideas and could really use some help. Here is what I have: 50 workers, just running an infinite loop that constantly calls save! on a model. Keep in mind this is just for testing purposes. I catch all exceptions and put them in the log. I am tried setting allow_concurrency to true and false. Neither

Is there a way to determine if attributes were changed? Let''s say in the before_save or after_save method? Thanks for your help. Thank You, Ben Johnson E: bjohnson@contuitive.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060711/442b20d2/attachment.html

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:

I am using BackgrounDRb to resize images after they are accepted into our system. However, it has become clear that this creates a memory leak. I''m not sure exactly where the leak exists, but I don''t think it''s in my own code as it is presently being used in production and has resized thousands of images without a leak occurring, thanks to calling GC.start