I’ve been using script/runner to add and delete files from the
database in response to inotify events. This works in theory, but is
too slow to keep up with a large number of events in succession; I’m
suspecting that the bottleneck is that script/runner has a huge
startup cost.
One thing I thought of was to queue inotify events, and call
script/runner once a minute to clear the queue, but that seems a bit
inelegant - ideally, what I’d like to do is have a persistent process
that is aware of my rails models, and which I can just keep sending
events to and have it process them as they come in. Any thoughts on
strategies to accomplish this?
martin
On 3 October 2006 14:20, Martin DeMello wrote:
One thing I thought of was to queue inotify events, and call
script/runner once a minute to clear the queue, but that seems a bit
inelegant - ideally, what I’d like to do is have a persistent process
that is aware of my rails models, and which I can just keep sending
events to and have it process them as they come in. Any thoughts on
strategies to accomplish this?
You can set up a separate process with DRB server on a well known
address/port. Then, you can manage it through DRB.
An simpler solution might be to use an obfuscated url and a wget
cronjob.
crontab:
/dev/null 2>&1
On 10/3/06, Jon C. [email protected] wrote:
An simpler solution might be to use an obfuscated url and a wget
cronjob.
crontab:
/dev/null 2>&1
Won’t that incur the extra overhead of a controller call? All I really
need is activerecord and access to the models. I’m trying to do this
in realtime (i.e. insert a file into the db as soon as inotify detects
it) rather than via a cron job, and I have a feeling that if I can get
rid of the script/runner startup time, the rest of the process will be
able to keep up nicely.
martin
On 10/3/06, Maxim K. [email protected] wrote:
address/port. Then, you can manage it through DRB.
Can you point me to some resources on running a DRB server from within
my rails app? Everything I’ve seen works the other way, with rails
acting as the DRB client.
martin
Martin DeMello wrote:
Won’t that incur the extra overhead of a controller call? All I really
need is activerecord and access to the models. I’m trying to do this
in realtime (i.e. insert a file into the db as soon as inotify detects
it) rather than via a cron job, and I have a feeling that if I can get
rid of the script/runner startup time, the rest of the process will be
able to keep up nicely.
While backgroundrb is certainly the most elegant way to go, if you just
want access to your model in a script without the whole Rails framework,
just write a ruby script and require ActiveRecord and your model.
Something like:
#!/usr/bin/ruby
require AR and gems
require ‘rubygems’
require ‘active_record’
require ‘…/app/models/event’
db_config = YAML::load(File.open("…/config/database.yml"))
ActiveRecord::Base.establish_connection(db_config[‘production’])
You can then acccess the Event model as normal. Hope it helps.
Alan
On 10/5/06, Alan B. [email protected] wrote:
want access to your model in a script without the whole Rails framework,
just write a ruby script and require ActiveRecord and your model.
Something like:
[…]
Thanks - that worked beautifully. I did have a look at backgroundrb,
but I had the same problem with it as with regular drb - as far as I
could make out, all the documentation assumed that Rails was running
the client, not the server.
martin
On Thu, Oct 05, 2006 at 12:27:06PM +0530, Martin DeMello wrote:
You can set up a separate process with DRB server on a well known
address/port. Then, you can manage it through DRB.
Can you point me to some resources on running a DRB server from within
my rails app? Everything I’ve seen works the other way, with rails
acting as the DRB client.
google for the nice backgroundrb plugin.
Jens
–
Jens Krämer
[email protected]