[
https://issues.apache.org/jira/browse/LUCENE-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942795#comment-13942795
]
Robert Muir commented on LUCENE-5544:
-------------------------------------
{quote}
About the test, maybe instead of asserting that IW.isLocked == false, try to
open a new IW? I guess it will fail if you remove the stuff that you added to
the finally clause? That will guarantee that we test what the app is likely to
do after calling rollback().
{quote}
Well the current test doesnt even need that assert: its just for clarity. we
dont need an assert for this stuff at all: the last line of directory.close()
(MDW) will fail if there are open locks or files!
{quote}
And also, do you think it's better to use MDW.failOn to randomly fail if we're
somewhere in rollback() stack? Cause currently the test fails only in one of
two places. Just thinking about making the test more evil.
{quote}
This is a good idea.
> exceptions during IW.rollback can leak files and locks
> ------------------------------------------------------
>
> Key: LUCENE-5544
> URL: https://issues.apache.org/jira/browse/LUCENE-5544
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Fix For: 4.8, 5.0, 4.7.1
>
> Attachments: LUCENE-5544.patch
>
>
> Today, rollback() doesn't always succeed: if it does, it closes the writer
> nicely. otherwise, if it hits exception, it leaves you with a half-broken
> writer, still potentially holding file handles and write lock.
> This is especially bad if you use Native locks, because you are kind of
> hosed, the static map prevents you from forcefully unlocking (e.g.
> IndexWriter.unlock) so you have no real course of action to try to recover.
> If rollback() hits exception, it should still deliver the exception, but
> release things (e.g. like IOUtils.close).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
