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 <e...@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 <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
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
