Mongrel Cluster Compatibility

Is anyone using ferret with Mongrel/Mongrel-cluster?

The first one or two times I access the ferret index it works fine,
but then it throws a write lock error
StandardError (: Error occured at <index_rw.c>:703
Error: exception 6 not handled: Could not obtain write lock when
trying to write index
):

I need to do more testing on this to narrow down the problem/solution
but just wanted to throw out the question to see if anyone was using
this already succesfully or if someone (Dave? :slight_smile: knew why ferret might
choke on this setup.

I’ve been developing using lighttpd as a server without any problems
-Debian sarge built like

but I’ve just started testing on a production server
-Debian sarge with with Apache 2.2, mod_proxy_balancer and Mongrel built
like
http://forums.rimuhosting.com/forums/showthread.php?t=230
and
http://blog.innerewut.de/articles/2006/04/21/scaling-rails-with-apache-2-2-mod_proxy_balancer-and-mongrel

(I put in the links in case anyone else is interested in deploying
their own rails server - these links have been gold to me)

Sam

On 8/4/06, Sam G. [email protected] wrote:

but just wanted to throw out the question to see if anyone was using
and
http://blog.innerewut.de/articles/2006/04/21/scaling-rails-with-apache-2-2-mod_proxy_balancer-and-mongrel

(I put in the links in case anyone else is interested in deploying
their own rails server - these links have been gold to me)

Hi Sam,

I haven’t looked over the links so I’m not sure of the exact
difference between your dev setup and your production setup. However,
I can explain why you are probably getting locking errors. Ferret only
allows one process to be writing to an index at a time. Once you have
an IndexWriter open on an index it will obtain a write lock on the
index and you won’t be able to open another IndexWriter or delete
documents with and IndexReader.

Solution? You can kind of get around this problem by using the Index
class and setting the :auto_flush parameter to true. If you are
concerned about performance though you are better off with just the
one process writing to the index.

Does that make sense?

Cheers,
Dave

Solution? You can kind of get around this problem by using the Index
class and setting the :auto_flush parameter to true. If you are
concerned about performance though you are better off with just the
one process writing to the index.

Does that make sense?

Yes. Mongrel_cluster uses a different pid for each mongrel instance. I
don’t think there would be any way to specify which instance the load
balancer uses based on the action so… :auto_flush seems the way to go.
The application should be 99.9% about reading so hopefully the
performance hit won’t be significant. I’ll have to test and see. Cheers
Dave.

On 8/5/06, Sam [email protected] wrote:

The application should be 99.9% about reading so hopefully the
performance hit won’t be significant. I’ll have to test and see. Cheers
Dave.

Cool. If that solution doesn’t work you can write a simple server
using DRb that takes indexing requests. This shouldn’t be too hard and
will probably be added to a future version of Ferret.

Dave

David B. wrote:

On 8/5/06, Sam [email protected] wrote:

The application should be 99.9% about reading so hopefully the
performance hit won’t be significant. I’ll have to test and see. Cheers
Dave.

Cool. If that solution doesn’t work you can write a simple server
using DRb that takes indexing requests.

Or use a background process that updates the index for changed records
(updated_at > last update timestamp) periodically.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs