Build fault tolerance if sunspot-solr is unavailable

I am currently creating a Rails 3.2 application that uses the gem sunspot to provide search functionality for my application. sunspot uses Apache Solr for full-text indexing and search.

 def index @search = Article.search do fulltext params[:search] with(:published_at).less_than(Time.zone.now) paginate :page => params[:page], :per_page => 10 facet(:published_month) end @articles = @search.results respond_to do |format| format.html # index.html.erb format.json { render json: @articles } end end 

Right now, my code just does a search every time someone gets to the article index page and then displays the results. I am worried that solr leaving for some reason, and my application is dying with it. How can I implement fault tolerance for this action, which the underlying Article.all when solr omitted?

I know that I could just rescue from the exception, but it still means that every request creates an attempt to connect to solr . Is there any way to prevent this? (For example, catching an exception once, and then waiting 5 minutes before the application tries to connect to solr )

+4
source share
1 answer

As a Sunspot contributor and co-founder of Websolr , I recommend using rescue_from with a minimum timeout.

When it comes to Sunspot, it looks like the option to specify a timeout has recently been added to RSolr, the Sunspot library is used, so if this is the function you need, then you should learn how to submit a request to Sunspot for transmission timeout in RSolr.

Creating a failed Solr request should not be so expensive if you have the right timeouts. If Solr is turned off, you want it to disconnect when you open a TCP connection. A healthy Solr server should open a TCP connection an order of magnitude less than a second and start sending data for no more than a second or two for really expensive requests.

A wait time of 0.1 seconds and a data timeout of 5 seconds should be more than enough here.

The next best option here is to have another local proxy between your application and Solr, which can suppress requests when Solr is down. Perhaps middleware caching or Lac. Of course, I see this as a more complex approach if such a proxy server or cache is no longer part of your application infrastructure.

+3
source

Source: https://habr.com/ru/post/1394661/


All Articles