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 <e...@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 <saisantosh...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Reply via email to