[list]
[*]Best place for BackgrounDRb documentation is the README file that comes with the plugin. Read it thoroughly before going anywhere else for documentation.
[*]When passing arguments from Rails to BackgrounDRb workers, don’t pass huge ActiveRecord objects. Its asking for trouble. You can easily circumvent the situation by passing id of AR objects.
[*]Its always a good idea to run trunk version rather than older tag releases.
[*]To debug backgroundrb problems. Its always a good idea to start bdrb in foreground mode by skipping ’start’ argument while starting the bdrb server. After that, you should fire rails console and try invoking bdrb tasks from rails console and find out whats happening. John Yerhot has posted an excellent write up about this, here
[*]Whenever you update the plugin code from svn, don’t forget to remove old backgroundrb script and run :
[*]When deploying the plugin in production, please change backgroundrb.yml, so as production environment is loaded in backgroundrb server. You should avoid keeping backgroundrb.yml file in svn. Rather, you should have a cap task that generates backgroundrb.yml on production servers.
[*]When you are processing too many tasks from rails, you should use inbuilt thread pool, rather than firing new workers
[*]BackgrounDRb needs Ruby >= 1.8.5
[*]When you are starting a worker using
MiddleMan.new_worker()
from rails and using a job_key to start the worker ( You must use unique job keys anyways, if you want more than one instance of same worker running at the same time ), you must always access that instance of worker with same job key. Thats all MiddleMan methods that will invoke a method on that instance of worker must carry job_key as a parameter. For example:
Omitting the job_key in subsequent calls will be an error, if your worker is started with a job_key.
[/list]
[*]Best place for BackgrounDRb documentation is the README file that comes with the plugin. Read it thoroughly before going anywhere else for documentation.
[*]When passing arguments from Rails to BackgrounDRb workers, don’t pass huge ActiveRecord objects. Its asking for trouble. You can easily circumvent the situation by passing id of AR objects.
[*]Its always a good idea to run trunk version rather than older tag releases.
[*]To debug backgroundrb problems. Its always a good idea to start bdrb in foreground mode by skipping ’start’ argument while starting the bdrb server. After that, you should fire rails console and try invoking bdrb tasks from rails console and find out whats happening. John Yerhot has posted an excellent write up about this, here
[*]Whenever you update the plugin code from svn, don’t forget to remove old backgroundrb script and run :
rake backgroundrb:setup [*]When deploying the plugin in production, please change backgroundrb.yml, so as production environment is loaded in backgroundrb server. You should avoid keeping backgroundrb.yml file in svn. Rather, you should have a cap task that generates backgroundrb.yml on production servers.
[*]When you are processing too many tasks from rails, you should use inbuilt thread pool, rather than firing new workers
[*]BackgrounDRb needs Ruby >= 1.8.5
[*]When you are starting a worker using
MiddleMan.new_worker()
from rails and using a job_key to start the worker ( You must use unique job keys anyways, if you want more than one instance of same worker running at the same time ), you must always access that instance of worker with same job key. Thats all MiddleMan methods that will invoke a method on that instance of worker must carry job_key as a parameter. For example:
session[:job_key] = MiddleMan.new_worker(:worker => :fibonacci_worker, :job_key => 'the_key', :data => params[:input])
MiddleMan.send_request(:worker => :fibonacci_worker, :worker_method => :do_work, :data => params[:input],:job_key => session[:job_key])
Omitting the job_key in subsequent calls will be an error, if your worker is started with a job_key.
[/list]
3342
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
