lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uwe Schindler <...@thetaphi.de>
Subject Re: IndexSearcher.close() removed in 4.0
Date Tue, 19 Feb 2013 17:59:09 GMT
This example lacks some similarities: FilterInputStream is itsself an InputStream. IndexSearcher
is a completely different class with totally different functionality. The Index Reader holds
the resources. This was never different in previous Lucene versions! In earlier version you
were able to open the reader implicit by passing a directory to the ctor, so close was needed.
If you opened the searcher by passing a reader, close was a no op, too. 

Uwe

Uwe



Eric Charles <eric@apache.org> schrieb:

>Hi Uwe,
>
>Thx for to point that IndexSearcher does not retain resources.
>
>If we continue the analogy with the FilterInputStream which decorates 
>the InputStream, you can see that FIS.close calls close() on the
>wrapped 
>IS [1]. But this may be not to be compared with the Searcher/Reader way
>
>of working.
>
>I have no requirement to (re)add the close method, and also not the 
>needed background on the Lucene internals to state any opinion on this.
>
>Calling manager.release(indexReader) in the finally block is perfectly 
>fine to me, it's just that indexSearcher.close() sounds more natural.
>
>Btw, I saw the initial question posted by saisantoshi exactly at the 
>same time I was removing all the search.close() in my code base while 
>migrating to latest 4.1 (honestly, this small impact is trivial
>compared 
>to all the other changes :)
>
>Thx, Eric
>
>[1] 
>http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/io/FilterInputStream.java#180
>
>On 19/02/2013 17:23, Uwe Schindler wrote:
>> IndexSearcher in Lucene 4.0 does not hook resources and never will.
>IndexSearcher is a thin wrapper class which is not IO related so
>implementing Closeable is simply wrong. This is the same paradigm like
>a input stream should never be closed by a method unless explicitly
>documented. The code that opens the Index Reader has to close it not
>any wrapper class magically doing this. This also conforms to try with
>resources in Java 7 (although you should not use this language
>construct with index readers).
>>
>> Uwe
>>
>>
>>
>> Eric Charles <eric@apache.org> schrieb:
>>
>>> Hi Simon,
>>>
>>> Many thx for this info. I am just digging into the new Lucene3/4
>>> goodies, so excuse my stupid questions.
>>>
>>> Having a SearcherManager sounds great, I will try it.
>>>
>>> Still I like the paragdim to 'close' the resources I have created.
>Why
>>> not having a close() that simply does nothing for now and would do
>>> something in future releases if needed. This will allow the users to
>>> code that close method and they will not have to review all their
>>> sources if the close is really needed in the future. (Just thinking
>>> loud
>>> here...). Even better, some making the big version jump will even
>not
>>> have to change that part (close was available on IndexSearcher
>before).
>>>
>>> Another option would be to release the IndexReader on
>>> IndexSearcher#close. This means the the IndexReader must be able to
>>> autorelease itself (so it must know to which manager it belongs)
>(once
>>> again, just thinking loud).
>>>
>>> Thx, Eric
>>>
>>>
>>> On 19/02/2013 09:39, Simon Willnauer wrote:
>>>> Hey Eric,
>>>>
>>>> the problem here is more tricky than it seems. and IndexReader is a
>>>> point in time snapshot that should be shared as long as possible.
>If
>>>> you share this across threads you can not just call close you need
>to
>>>> count references. We have utilities for this (ReferenceManager /
>>>> SearcherManager) which I recommend to use. The process is usually
>>>> something like this
>>>>
>>>> IndexReader indexReader = manager.accquire();
>>>> try {
>>>>     IndexSearcher s = new IndexSeacher(indexReader);
>>>>     //do your search
>>>> } finally {
>>>>     manager.release(indexReader);
>>>> }
>>>>
>>>>
>>>> hope that helps
>>>>
>>>> simon
>>>> On Mon, Feb 18, 2013 at 11:30 PM, Eric Charles <eric@apache.org>
>>> wrote:
>>>>> Hi,
>>>>> Why not having the IS#close() calling the wrapped IR#close() ?
>>>>>
>>>>> I would be happier having to only deal with the Searcher once
>>> created and
>>>>> forget it wraps a Reader: I create a Searcher, I close it.
>>>>>
>>>>> Thx, Eric
>>>>>
>>>>>
>>>>> On 18/02/2013 22:20, Simon Willnauer wrote:
>>>>>>
>>>>>> On Mon, Feb 18, 2013 at 7:32 PM, saisantoshi
>>> <saisantoshi76@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> I understand from the JIRA ticket(Lucene-3640) that the
>>>>>>> IndexSearcher.close()
>>>>>>> is no-op operation but not very clear on why it is a no-op?
>Could
>>> someone
>>>>>>> shed some light on this? We were using this method in the older
>>> versions
>>>>>>> and
>>>>>>> is it safe now to remove this call. Just want to understand the
>>>>>>> consequences
>>>>>>> before we make any changes? Is there any alternative that we
>need
>>> to use
>>>>>>> here?
>>>>>>
>>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> previous version had a constructor that accepted a directory [1]
>if
>>>>>> you used this constructor IndexSearcher#close did also close the
>>> index
>>>>>> reader that was created. Since we removed this constructor we
>also
>>>>>> removed close since it's a no-op. IndexSearcher is just a wrapper
>>> to
>>>>>> add some functionality on top of the reader. You can ignore the
>>>>>> IS#close() if you closing the IndexReader properly.
>>>>>>
>>>>>> simon
>>>>>> [1]
>>>>>>
>>>
>http://lucene.apache.org/core/3_6_2/api/core/org/apache/lucene/search/IndexSearcher.html#IndexSearcher(org.apache.lucene.store.Directory)
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sai
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>
>http://lucene.472066.n3.nabble.com/IndexSearcher-close-removed-in-4-0-tp4041177.html
>>>>>>> Sent from the Lucene - Java Users mailing list archive at
>>> Nabble.com.
>>>>>>>
>>>>>>>
>>>
>---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail:
>java-user-help@lucene.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>
>---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>>>>
>>>>>
>>>>>
>>>
>---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>>>
>>>>
>>>>
>---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>>
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
>> --
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, 28213 Bremen
>> http://www.thetaphi.de
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>For additional commands, e-mail: java-user-help@lucene.apache.org

--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message