[
https://issues.apache.org/jira/browse/LUCENE-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213638#comment-13213638
]
Yonik Seeley commented on LUCENE-3800:
--------------------------------------
Ouch - more weak references. I was hoping we could reduce the number of those
(I've seen them cause worse GC problems for a number of people).
But if I understand the description correctly, then without this patch things
could core dump when using mmap directory?
> Readers wrapping other readers don't prevent usage if any of their subreaders
> was closed
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-3800
> URL: https://issues.apache.org/jira/browse/LUCENE-3800
> Project: Lucene - Java
> Issue Type: Bug
> Components: core/index
> Affects Versions: 4.0
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-3800.patch, LUCENE-3800.patch, LUCENE-3800.patch
>
>
> On recent trunk test we got this problem:
> org.apache.lucene.index.TestReaderClosed.test
> fails because the inner reader is closed but the wrapped outer ones are still
> open.
> I fixed the issue partially for SlowCompositeReaderWrapper and
> ParallelAtomicReader but it failed again. The cool thing with this test is
> the following:
> The test opens an DirectoryReader and then creates a searcher, closes the
> reader and executes a search. This is not an issue, if the reader is closed
> that the search is running on. This test uses LTC.newSearcher(wrap=true),
> which randomly wraps the passed Reader with SlowComposite or ParallelReader -
> or with both!!! If you then close the original inner reader, the close is not
> detected when excuting search. This can cause SIGSEGV when MMAP is used.
> The problem in (in Slow* and Parallel*) is, that both have their own Fields
> instances thats are kept alive until the reader itsself is closed. If the
> child reader is closed, the wrapping reader does not know and still uses its
> own Fields instance that delegates to the inner readers. On this step no more
> ensureOpen checks are done, causing the failures.
> The first fix done in Slow and Parallel was to call ensureOpen() on the
> subReader, too when requesting fields(). This works fine until you wrap two
> times:
> ParallelAtomicReader(SlowCompositeReaderWrapper(StandardDirectoryReader(segments_1:3:nrt
> _0(4.0):C42)))
> One solution would be to make ensureOpen also check all subreaders, but that
> would do the volatile checks way too often (with n is the total number of
> subreaders and m is the number of hierarchical levels this is n^m) - we
> cannot do this. Currently we only have n*m which is fine.
> The proposal how to solve this (closing subreaders under the hood of parent
> readers is to use the readerClosedListeners. Whenever a composite or slow
> reader wraps another readers, it registers itself as interested in
> readerClosed events. When a subreader is then forcefully closed (e.g by a
> programming error or this crazy test), we automatically close the parents,
> too.
> We should also fix this in 3.x, if we have similar problems there (needs
> investigation).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
