On Jun 15, 2006, at 6:03 AM, Christian R. wrote:
From the description there it seems that BackgrounDRb is a kind
of “generic” drb server that takes any pieces of code to run (the
workers) and provides a nice access wrapper on the client side. If
that
is correct, I can’t really use it – my background tasks have to run
as ‘root’ (system admin tool). Running a generic “please run my code”
server is a big no-no for that 
You pretty much have the right idea here. But it the drb server
won’t run any code except what you tell it to run in your worker
classes. So it’s every bit as safe as you want it to be. I am using
it in a few places where the drb server runs as root because it needs
root to do some sysadmin tasks. Its a lot safer to run your root code
in a separate process then it is to run your rails app as root.
Backgroundrb uses DRb acl lists so you can specify the ip adressess
that can access the server. By default it only allows access from
localhost but you can get as fine grained as you want here.
I’m also a bit confused about what exactly is the problem with
threading.
BackgrounDRb seems to use multithreaded ActiveRecord just fine –
so why
does rails have problems with it?
Well ActiveRecord itself seems to work very well in threaded mode by
itself. Its mainly the combination of ActionController and
ActiveRecord that have threading problems. People do all kinds of
weird stuff in their rails controllers like using popen to run tasks
and other things that make it hate itself. Rails is a pretty big code
base and the combination of all parts is not thread safe. ANd it
would take a lot of work and probably some performance hits to make
it safe.
In BackgrounDRb I use mutexes in the key spots to make sure that the
threads don’t stomp on each other. But I hear you, I haven’t ever
been able to get a real straight answer as to why rails is not thread
safe in general. I think its just that it is a large framework and
its designed for shared nothing where requests are run in separate
fcgi’s or mongrel backends and are serialized in these back ends so
only on request per backend runs at once.
I have tested BackgrounDRb with ActivceRecord reads and writes in a
tight loop with 100 workers grabbing stuff from AR and changing the
records and saving and it works fine. Of course multi threaded
programming is hard to do ‘right’ so I am sure there are edge cases
that I have not forseen yet, but I will handle those as they come.
not really bugs in rails, just usage patterns that people have which
Summary: I’m thoroughly confused by now 8+?
Even if rails was totally thread safe I would still not recommend
just spinning off threads at will from your controllers during web
requests. Its just bound to get messy. ActiveRecord stores its
database connection in Thread.current, which cause the Mysql server
has gone away error when two threads step on each other’s database
connections.
For me it was much easier to create my own environment outside of
rails with threading in mind from the start and push these tasks to
another ruby instance. This was a much easier task then trying to
make rails itself thread safe. Rails handles what it is good at very
well. And that is handling web requests as fast as it can. But long
running tasks just clash with the whole HTTP request/response cycle
and so thats why I saw the need for this plugin.
Cheers-
-Ezra
