You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shai Erera (JIRA)" <ji...@apache.org> on 2014/03/21 06:02:43 UTC

[jira] [Commented] (LUCENE-5544) exceptions during IW.rollback can leak files and locks

    [ https://issues.apache.org/jira/browse/LUCENE-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942789#comment-13942789 ] 

Shai Erera commented on LUCENE-5544:
------------------------------------

Patch looks good. So basically with this patch, the state of IW after rollback() is it's always closed() and doesn't leak any important resources like write.lock and pooled readers. And there's no way to continue using this instance - app must create a new IW instance. We can still end up w/ a segments_N file in the directory though (if its delete failed), but I guess IW will detect it's corrupt and use the one from the previous commit.

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().

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.

> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org