similar to: Worker suicide

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, 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"

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

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.

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

Is there something special I need to do to access session data in a worker? I''m using an AR session store. I''ve been working with Ezra''s tutorial, modifying it a little here and there to figure it out. So I changed the progress bar to a simple count-down in the worker which sends back the count to display in the view. No big deal. But if I try to access session

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''m using backgroundrb for session management and deletion of visitor-entered information when a session is abandoned. The visitor can either click a button to end their session and remove their data, or backgroundrb will do it for them after 5 minutes of inactivity. Everything''s working fine, I think. If the visitor explicitly logs out, then when the worker checks for their

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.

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

I''ve created a couple of tasks in my deploy.rb file for starting and stopping backgroundrb on the remote server. The stop task runs fine and kills the process. And the start task *seems* to run successfully, but backgroundrb is never started on the remote host. Has anyone had success with this? Here are my deploy tasks: desc ''Start backgroundrb server (default

Hello, Thank you so very much for Backgroundrb. Good Stuff. A general question: Do: - calling ''teminate'' within a worker - calling delete_worker through MiddleMan - letting the :ttl expire - calling MiddleMan.gc! (with an appropriate timestamp) All accomplish the same thing? And here''s a bonus feature request: It''d be cool if you could specify how many

Sorry to be such a bother but I''m not getting this. I have two models: Emrec and Session (I''m using AR for session mgmt.) In my worker I can access the Emrec model and delete a record, AS LONG AS I don''t try to access the Session model. With the Session model access commented out as below, the Emrec record gets deleted. If I uncomment those lines, the Emrec

Hello, Yesterday I posted about how to email from a worker. I decided to be a bit piggy and just inhale all of rails. Sorted. I am noticing some rather ominous behavior though. The setup: My worker takes an uploaded image as a param and passes it (via system call) to a C++ image processing engine. Take a look at these memory consumption figures for successive runs uploading the identical image

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

I''m just getting started wtih backgroundrb, and unfortunately hit a snag right away... I''m running the latest releases of rails, backgroundrb, slave and daemons. I created a simple worker class, using the generator, which currently does nothing but print the arguments that are passed to do_work. I''m running backgroundrb using ''./script/backgroundrb

Hey. I have a very annoying problem, and was wondering what is wrong. Suppose I have backgroundrb running, and then I have an action in some controller. In the action I define a worker. When leaving the action, suddenly the connection to backgroundrb is lost: DRb URI: druby://localhost:22222 Pid: 3976 Autostart... done druby://localhost:42531 - #<Errno::EBADF: Bad file descriptor -

I''m digging into BackgrounDRb and having some problems testing a worker class. The following line in my test (created from script/generate worker Test) throws an error: worker = TestWorker.new(:test_string => "testing...") Error: /activesupport/lib/active_support/dependencies.rb:123:in `const_missing'': uninitialized constant BackgrounDRb (NameError) from

Hi there, I''m trying to create a worker to do some asynchronous web client work and update the data model with its results. It seems, however, that every call I make to an ActiveRecord subclass causes the whole thing to block. At least I think it''s blocked. Right now I''m just using debug log output. Is there a decent way to debug/test workers I can try? Is there any

Hi All, I have this small doubt. Does backgroundrb have anything to do with dispatch.fcgi? some dispatch.fcgi are taking memory as much as 186 MB .... this is monstrous man... Also, if i put load rails environment with backgroundrb.yml file to be false.What will happen? i just loses access to db through ActiveRecord right? I can still use normal mysql gem to access db and modify the