Ferret talk - Aug 2006 - 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? :) knew why ferret might 
choke on this setup.

I''ve been developing using lighttpd as a server without any problems
-Debian sarge built like
http://brainspl.at/articles/2005/11/13/the-perfect-lightweight-rails-lighttpd-debian-install

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

-- 
Posted via http://www.ruby-forum.com/.

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? :) knew why ferret might
choke on this setup.

I''ve been developing using lighttpd as a server without any problems
-Debian sarge built like
http://brainspl.at/articles/2005/11/13/the-perfect-lightweight-rails-lighttpd-debian-install

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 Giffney <samuelgiffney at gmail.com>
wrote:
> 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? :) knew why ferret might
> choke on this setup.
>
> I''ve been developing using lighttpd as a server without any
problems
> -Debian sarge built like
>
http://brainspl.at/articles/2005/11/13/the-perfect-lightweight-rails-lighttpd-debian-install
>
> 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)
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.

-- 
Posted via http://www.ruby-forum.com/.

On 8/5/06, Sam <samuelgiffney at gmail.com> wrote:
> > 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.
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 Balmain wrote:
> On 8/5/06, Sam <samuelgiffney at gmail.com> 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.

-- 
Posted via http://www.ruby-forum.com/.