Until recently I’ve been using Daemon kit on a Ruby on Rails project
I’ve
been developing for work. Namely I’m trying to monitor a Delayed Job
queue.
This has worked fine during development as I’ve not had to actually run
my
script as an actual daemon. Sadly, Daemon kit fails utterly for
production
RoR applications as it uses both ObjectSpace (which we can enable) and
forks, which is something JRuby just doesn’t like.
I’m wondering what the community as a whole is using. I’m currently
looking
into TorqueBox. My only qualm with this solution is that it seems like
it
isn’t as convenient as the Glassfish gem for development.
I’m wondering what the community as a whole is using. I’m currently
looking into TorqueBox. My only qualm with this solution is that it
seems like it isn’t as convenient as the Glassfish gem for
development.
For work I am spawning off JRuby daemons from a regular Ruby script.
The Ruby script parses all the command line options and constructs the
command line to call JRuby. On the flip side, the Ruby script also
shuts down the JRuby daemon when we deploy new code or when something
breaks. It works very well, and we’ve not had any problems with this
arrangement.
I’m wondering what the community as a whole is using. I’m currently
looking into TorqueBox. My only qualm with this solution is that it seems
like it isn’t as convenient as the Glassfish gem for development.
This is a timely thread. We need a simple daemon which runs with
sub-minute granularity (so we can’t use cron). The daemon runs search
reindexing process every n seconds.
Questions:
How does this work with deployment as a War? Do you have to build a
UI for controlling and monitoring the daemon?
What about detection of crashes or memory leaks? In a standard
non-jRuby rails environment, we’d use Monit for this. Does servolux
or some other solution handle that?
into TorqueBox. My only qualm with this solution is that it seems like it
isn’t as convenient as the Glassfish gem for development.
Maybe this is what you are saying as well but anyway, GlassFish gem
supports
daemonizing on linux and solaris platforms. Just run glassfish with -d
flag.
This is a timely thread. We need a simple daemon which runs with
sub-minute granularity (so we can’t use cron). The daemon runs search
reindexing process every n seconds.
Questions:
How does this work with deployment as a War? Do you have to build a
UI for controlling and monitoring the daemon?
There is no war file involved in the context in which we are using
Servolux. All control and monitoring of the daemon process is done by
hand right now (no monit, god, or nagios). We are using “vlad” for
deployment, though.
What about detection of crashes or memory leaks? In a standard
non-jRuby rails environment, we’d use Monit for this. Does servolux
or some other solution handle that?
Servolux will attempt to determine if the daemon process started
successfully or not and report the status. After the daemon starts,
though, no more monitoring is performed. You should use another tool
for server monitoring.
My own experience. Daemonizing is not simple to do reliably with lots
of
daemons and pid files are inherently unreliable, avoid them if you can.
runit is a good alternative when it’s the right fit. For queue type
stuff,
running stuff frequently with cron will thrash your servers with all
those
processes constantly starting up. For delayed jobs, we use webhooks.
We
stick stuff into a queue that does an http post back to our rails app
that
processes the delayed job. Leverages our existing infrastructure, no
custom
job runners, etc… works great and we push through about a million or
more
jobs a day. Our queue servers used to run with a load average of around
20,
not they are down to 1-2.
Chris
I’ll second the daemonizing of GlassFish Gem as long as you’re on
Linux or Solaris, especially if (as it sounds) you’re already using it
for development. Seems like it would make your entire deployment story
nicely simple.
Indeed it does, but this is not quite what I meant. I’m more interested
in
how people are daemonizing tasks. Take for instance the Delayed Job gem
and
it’s Worker class. The Worker class monitors a queue in your database
that
holds a list of tasks that need to be performed. You such a class should
be
running as a daemon for a productionalized version of your application.
Making a daemon in MRI is straight forward: fork a process and hand off
control to the init process. Since JRuby doesn’t do forking, I’m curious
how
people are handling this. The consensus seems to be running some script
in
the background with “nohup”. Example:
VERYYYY interesting. Do you perchance have any introductions to webhooks?
I’m not familiar with this topic.
It’s just a fancy name for an http callback. We stole the rest of the
architecture idea from how google is using them to manage similar
delayed
jobs. The basic architecture is that we have a queue server that
accepts
http POST requests to add items to the queue. Our web apps then make
http
requests to add jobs to the queue server. The queue server then takes
the
url for the queue, and posts the job to that url, which processes the
task
and returns a response. We have a number of different queues each with
their own url. The queue server is written with eventmachine.
Chris
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.