Hi Adrien,
> I'm afraid that always calling doClose would be problematic. If the reader
> is used in another thread then files might get closed under the hood while a
> search is being performed. Even if the guard that we added to MMapDirectory
> would now prevent segfaults, users would get potentially confusing
> exception.
Isn't it the right behavior though? Think of any closeable resource --
a file channel or even a stream. When you close it, other threads
using it should get an exception (that's the point of closing the
channel). The reader's contract is inconsistent to me here. If there
are multiple threads using it they should incRef/ decRef consistently
(there are assertions that verify sanity of this) and if it's a single
thread then calling close() should make the reader stop serving any
requests.
The situation you're describing above does sound like a real bug to me
where the reader is closed yet other threads still make happy use of
it -- I just can't imagine a real-life situation where this doesn't
signal a threading/ use case problem?
> I see pros and cons regarding checking "if (closed)" in ensureOpen. In any
> case I think we should keep a way to let ongoing searches finish
> successfully before effectively closing the reader, which I suspect users
> rely on.
This is the bit I find strange, actually. Converting to sequential
code, it'd be like this.
DirectoryReader reader = openReader();
IndexSearcher searcher = new IndexSearcher(reader);
reader.close();
searcher.search(new TermQuery(new Term("foo", "bar")), 10);
The above in a purely sequential case does not work (as expected). The
searcher doesn't incRef the reader's counter, so closing the reader
closes all its resources.
In my opinion ff there is code out there that relies on incRefs then
it shouldn't be calling close at all (and use decRef which closes the
reader when the ref count drops to zero). The close() on such a reader
should result in any subsequent searches being terminated (with the
AlreadyClosedException). There are efficient way to make sure all
search threads using a searcher in parallel terminate (join them,
await thread pool's termination)...
Conversely, you could argue that if you have parallel code that uses
ref counts and then wish to abort you won't be able to close such a
reader at all (because you don't know how many decRefs to call)?
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
