lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <va...@osafoundation.org>
Subject Re: IndexReader.acquire()/release() ?
Date Fri, 18 Jul 2008 12:47:19 GMT

On Fri, 18 Jul 2008, Michael McCandless wrote:

> The counter argument here is: the ref counting that IndexReader already 
> implements is a precise match to this use case.  Why re-create the same logic 
> above?

Agreed. I was very pleased to find incRef() and decRef() already 
implemented. My patch just makes these methods with an ensureOpen() check.

> Lots of things (be they MultiSearchers or application's threads) need to 
> share access to a single IndexReader such that the reader cannot be closed 
> until all things have released their references.

Ok, I'll file the bug with the patch the proper way then.
Thanks !

Andi..

>
> Mike
>
> Mark Miller wrote:
>
>> Hey Andi,
>> 
>> I think that the best way of dealing with this, as there is little downside 
>> and it avoids further complicating IndexReader, is to build your reference 
>> counting around the IndexReader class rather than within it.
>> 
>> - Mark
>> 
>> Andi Vajda wrote:
>>> 
>>> I'd like to propose a patch for IndexReader but before I file a proper bug
>>> and attach the (simple) patch, I want to check here if my approach is the
>>> right one.
>>> 
>>> I have a server where a bunch of threads are handling search requests. I
>>> have a another process that updates the index used by the search server 
>>> and
>>> that asks the searcher server to reopen its index reader after the updates
>>> completed.
>>> 
>>> When I reopen() the index reader, I also close the old one (if the 
>>> reopen()
>>> yielded a new instance). This causes problems for the other threads that
>>> are currently in the middle of a search request.
>>> 
>>> I'd like to propose the addition of two methods, acquire() and release() 
>>> (see below), that increment/decrement the ref count that IndexReader 
>>> instances currently maintain for related purposes. That ref count prevents 
>>> the index reader from being actually closed until it reaches zero.
>>> 
>>> My server's search threads, thus acquiring and releasing the index reader 
>>> can be sure that the index reader they're currently using is good until 
>>> they're done with the current request, ie, until they release() it.
>>> 
>>> Is this the right way to go about this ?
>>> 
>>> Thanks !
>>> 
>>> Andi..
>>>
>>>    public synchronized void acquire()
>>>        throws AlreadyClosedException
>>>    {
>>>        ensureOpen();
>>>        incRef();
>>>    }
>>>
>>>    public synchronized void release()
>>>        throws AlreadyClosedException, IOException
>>>    {
>>>        ensureOpen();
>>>        decRef();
>>>    }
>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>> 
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message