[
https://issues.apache.org/jira/browse/LUCENE-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942802#comment-13942802
]
Shai Erera commented on LUCENE-5544:
------------------------------------
bq. Just thinking about making the test more evil.
Though if the exception happens from Lock.close(), the lock will still exist
and the test will fail asserting that the writer isn't locked. It's a valid
exception but nothing we can do about it while calling rollback(). So maybe
exclude it from the list of allowed places to fail.
Do you think it's better to not swallow the exceptions in the finally part, but
add them as suppressed to any original exception? Because if e.g. lock.close()
fails, app won't be able to open a new writer, yet all it has as info is the
original exception that happened during rollback(), and no info that the lock
couldn't be released either.
> 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]
