lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3528) TestNRTManager hang
Date Tue, 08 Nov 2011 16:07:51 GMT


Simon Willnauer commented on LUCENE-3528:

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?
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:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message