Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | A Ruby/Rails job server and scheduler edit |
-
And it kills kittens.
Comments
-
Please have a look at my comment on the code:
http://github.com/gnufied/backgroundrb/commit/22d365a4df4b49d29774efdb5a9335e0300a3ac9#server/lib/master_worker.rb-P27The method which should be called there doesn't seem to be defined anywhere...
Comments
You need to update your packet version to 0.1.15 for that to work. Basically, that change allows for instant exception thrown in user code, if you are trying to invoke a method on worker which isn't defined in worker.Needless to say, it also defeats method_missing kinda hack too.
-
Seems like for some time now, backgroundrb version 1.1 has been plaguing certain users with a "no such file" error for log_worker when starting up the backgroundrb server. It hit me today, and the cause quickly became apparent. Somewhere around version 0.1.7, packet's code changed in some way that causes WORKER_ROOT or WORKER_LOAD_ENV paths with spaces in them to cause a no such file error. It has to do with the way packet constructs the command line for packet_worker_runner.
While it would probably make more sense for the maintainers of packet to fix this issue on their end, the fix in backgroundrb is really simple. Just add preceding and trailing " characters to WORKER_ROOT and WORKER_LOAD_ENV.
I'd submit a patch myself, but I'm really new to ruby and not sure if my fix would be considered the "right way" to go about working around the packet issue. I plan on mentioning this to the packet maintainers too.
Comments
vulpinelogic
Tue Jun 09 09:19:11 -0700 2009
| link
Scrap that... quoting the path causes the Dir[] call to return an empty array in master_proxy. Back to square one...
vulpinelogic
Tue Jun 09 09:36:43 -0700 2009
| link
Duh... Fixed it at the root of the problem in packet_worker_runner. Don't know why I was trying to work around it in backgroundrb. Now lets see if I can get the packet maintainers to add the patch...
-
Calls to exit() seem to be broken in the master branch, which results in zombie workers until backgroundrb is cycled.
Comments
I added a backtrace print to the error handler, and the call stack is as follows:
/Users/don/Code/Rails/pubbrain/lib/workers/run_search_worker.rb:117:in 'exit' /Users/don/Code/Rails/pubbrain/lib/workers/run_search_worker.rb:117:in 'create' /Users/don/Code/Rails/pubbrain/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:320:in 'send' /Users/don/Code/Rails/pubbrain/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:320:in 'invoke_user_method' /Users/don/Code/Rails/pubbrain/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:127:in 'worker_init' /Library/Ruby/Gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet_worker.rb:19:in 'start_worker' /Library/Ruby/Gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:33:in 'load_worker' /Library/Ruby/Gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:26:in 'initialize' /Library/Ruby/Gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:47:in 'new' /Library/Ruby/Gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:47 /usr/bin/packet_worker_runner:19:in 'load' /usr/bin/packet_worker_runner:19
-
This might be a bug tickled by the latest version of rspec, because I've been using rspec and backgroundrb for ages without any problems.
What I'm finding is if I run 'rake spec' from a rails project with the backgroundrb plugin and a backgroundrb.yml file which specifies ":environment: development", line 23 of bdrb_config.rb sets RAILS_ENV to 'development'. This means that rake spec clobbers the development database.
Comments
Hey, I don't want any of those cute kittens being killed... ;-)