[
https://issues.apache.org/jira/browse/LUCENE-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146379#comment-13146379
]
Simon Willnauer commented on LUCENE-3528:
-----------------------------------------
{quote}
Can we move the fix "up"? Ie, leave SearcherManager.maybeReopen as returning
boolean indicating if a new reader was really reopened, but then in
NRTManager.maybeReopen, always carry the gen forward once we've called
maybeReopen?
{quote}
Mike, the problem here is that you need to have some information about if we
tried to reopen or not. If you use a NRT reader that doesn't apply deletes you
will always get false from reader.isCurrent() provided you have a delete still
sitting in memory. So if we move this up we can not tell if we simply didn't
get the lock in maybeReopen or if the reopen returned null. We could make the
contract of maybeReopen stronger and remove the non-blocking properties from it
or add a second method which blocks.
Simply moving it up is hardly possible since you can not tell what really
happened in maybeReopen()
> TestNRTManager hang
> -------------------
>
> Key: LUCENE-3528
> URL: https://issues.apache.org/jira/browse/LUCENE-3528
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 3.5, 4.0
> Reporter: Robert Muir
> Assignee: Simon Willnauer
> Fix For: 3.5, 4.0
>
> Attachments: LUCENE-3528.patch, LUCENE-3528.patch, LUCENE-3528.patch,
> LUCENE-3528_reproduceHang.patch
>
>
> didn't check 3.x yet, just encountered this one running the tests
--
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: [email protected]
For additional commands, e-mail: [email protected]
