Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of uwe@thetaphi.de designates
 188.138.97.18 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <512362E4.9080904@apache.org>
References: <1361212373311-4041177.post@n3.nabble.com>
 <CAAHmpkh3hqkd2AwfXxXJ==svSMCT7n9U5Lf-VX-obQw5jv2NhA@mail.gmail.com>
 <5122AB6B.4030306@apache.org>
 <CAAHmpkiH-7woEN4y=w2pkkbekW=1du=cgTyH-jenps-y5TsM8w@mail.gmail.com>
 <512362E4.9080904@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----1M0KKB030P7PYZQLEAD3FS6NGPD83B"
Subject: Re: IndexSearcher.close() removed in 4.0
From: Uwe Schindler <uwe@thetaphi.de>
Date: Tue, 19 Feb 2013 18:23:20 +0100
To: java-user@lucene.apache.org
Message-ID: <5f2e6732-501e-4918-bb2c-5a768b5163ab@email.android.com>

------1M0KKB030P7PYZQLEAD3FS6NGPD83B
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

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
------1M0KKB030P7PYZQLEAD3FS6NGPD83B--