Reducing dependency on remote ferret process

Ruby Apps Ferret
1

Hi.

We use FerretDrb for search. If the ferret process is down, our entire
application comes down the moment we try to save a model which is
indexed.

Is there a way to decouple this relationship such that we can somehow
resume normal operations despite ferret being down and not index the
model?

Thanks.

Morten

2

Morten wrote:

Morten
I really don’t understand your concern. I could also say “if the web
server process is down, our entire application is down” (assuming you’re
talking about a web app). The FerretDrb process shouldn’t be down. If
you continue even if it’s down, your index will become out of date.
Depending on your data that may or may not be worse than crashing.

3

Hongli L. wrote:

Morten

I really don’t understand your concern. I could also say “if the web
server process is down, our entire application is down” (assuming you’re
talking about a web app). The FerretDrb process shouldn’t be down. If
you continue even if it’s down, your index will become out of date.
Depending on your data that may or may not be worse than crashing.

I don’t think your comparison is quite fair. Ferret is nice, but it’s
not fully matured compared to Apache, MySQL and so on. At least I’m
having more stability issues with it than I’ve had with the other
processes that I base my work on, which is why I think my concern is
completely valid.

Br,

Morten

4

Hey …

unfortunately, no … not with the current construction.
However, there might be a chance to switch to a
messaging service like ap4r, so your indexing
requests doesn’t get lost.

I think there are some considerations about re-factoring
the drb server, so maybe this dependency might be
dropped in the future…

Cheers
Ben

On 2007-11-11, at 16:09, Morten wrote:

Thanks.

Morten

Ferret-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ferret-talk

Gruss
Ben

Benjamin K.

[email protected]

Rails-Schulung “Advancing with Rails” mit David A. Black
19.11.-22.11.2007, Berlin-Mitte
Details u. Anmeldung: http://www.railsschulung.de

5

Morten,

If you’re still looking at how to solve this, here is what I did.
This is just a hack, but I didn’t really have a choice, this coupling
was killing my entire application stack.

— act_methods.rb (revision 1534)
+++ act_methods.rb (working copy)
@@ -185,9 +185,10 @@
end
logger.info “default field list: #{aaf_configuration[:ferret]
[:default_field].inspect}”

  •  if options[:remote]

  •    aaf_index.ensure_index_exists

  •  end

  •  # FIXME fix and send a patch to the AAF team

  •  # if options[:remote]

  •  #   aaf_index.ensure_index_exists

  •  # end
end

–
Peter J. - 303-669-2637
pmade inc. - http://pmade.com

6

Let me take a wild guess on this one.

On ACTS_AS_FERRET_GEM_ROOT/lib/index.rb

def ferret_create
if ferret_enabled?
logger.debug “ferret_create/update: #{self.class.name} : #{self.id}”
self.class.aaf_index << self
else
ferret_enable if @ferret_disabled == :once
end
true # signal success to AR
end

Try wrapping “aaf_index<<” like this

begin
self.class.aaf_index << self
rescue Exception => e
logger.warn “Error creating/updating document:
#{e.inspect}\n#{e.backtrace.join(”\n\t")}"
end

Mind I’m just reading the source and writing the code here straight
away. In the event of my theory being right, this would gracefully
handle exceptions related to adding an entry to the index by dropping
a warning in the AAF log file and moving on.

I think this could be an optional in config/initializers (Rails 2.0)
perhaps, as in

config.aaf.exception_on_save = true

IMHO, of course.

7

I’ve added suggestions from Julio Cesar O. and Peter J. to the
relevant ticket:

http://projects.jkraemer.net/acts_as_ferret/ticket/149

If anyone has another solution, consider adding it to the ticket.
Quote code in trac like this:

{{{

my code

}}}