Just some things to watch out for when using backgroundrb with Rails:
1. Starting backgroundrb like this:
Does not mean that your application will be running in production mode. In other words, production here refers to the section in your backgroundrb.yml that will be used and will not, for example, cause rails to start with production database settings. For that to occur, your backgroundrb.yml setup needs to forward a Rails environment as follows:
2. This may be pretty obvious but:
Does not give you a new worker. It was giving me a worker so I just assumed it must be a new anonymous worker (that is one not identifiable by a job key). This tripped me up for a while until I figured out that when backgroundrb fires up it creates one instance of each worker and the above code will return a proxy to such an instance. Multiple long running method invocations on this single worker is of course going to end up result in blockage which is exactly what you are working to avoid with backgroundrb. So no, that syntax is not a shortcut to creating a new anonymous worker and you should instead use this:
And of course if you need to refer to that worker later to, for example, get a status update, you will have to create the worker with a job key so that you can grab a reference to it later:
3. The serialization / deserialization process that occurs when an argument is passed through drb may cause some unintended side effects. For example, a DateTime object that defaulted to displaying in UTC time before being passed through drb would display in local time after being passed through drb.
