At present I’m working on a couple of different Rails projects, each of
which has to have background tasks running for a variety of reasons
(handling large imported files, sending reminder emails at predetermined
times, handling incoming emails, etc.)
So far I’ve been using the “spawn” plugin for this in preference to the
many other equally undocumented choices mostly because it was the first
one I tried that just “worked”, and it is getting the job done well
enough. Biggest problem is just remembering to restart the silly thing
whenever the Rails app is restarted for a deployment or whatever.
Today while researching a new feature to add, I stumbled upon a
different idea and I wanted to get some feedback from the community on
the pro’s and cons of doing “background tasks” in this way:
Why not just write a second little Rails app that doesn’t happen to have
any end-user facing UI? This app would use RESTful stuff for handling
lengthy tasks such as handling large import files and such.
A third app would be a mindless loop, continually checking various
things to see if it needs to do something like send a reminder email or
handle incoming emails.
To be sure, this approach would suck up some RAM, but it would make
splitting up the app when the user base gets huge an almost trivial
proposition.
If one were to serve these three apps (the mail app plus two different
types of background app) via “mod_rails” (Phusion Passenger), would they
effectively all be in separate threads and avoid holding each other up?
Are there any hidden gotcha’s involved with having three such apps
connected to the same MySQL database?
P.S. I can’t exactly put into words why this method appeals to me over
the current method of spawning a simple background process that is more
closely coupled to the main Rails app. It just seems like an
interesting way to do it. Wondered what others think of it.
thanks,
jp