[
https://issues.apache.org/jira/browse/LUCENE-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567155#comment-14567155
]
Robert Muir commented on LUCENE-6508:
-------------------------------------
{quote}
...you could shed light on what future locking needs Lucene might have? I feel
like we should design for today, especially on a part of Lucene that has had so
much trouble/bugs.
{quote}
Well for example, we could have a commit lock again. I'm not pushing for it at
all, I'm just saying its a valid option.
As I explained, I went for the path of least resistance: you know adding some
deprecated methods and even keeping defaults the same (like timeout stuff).
I think this makes the change easier to digest, and as followups to this issue
i'd propose:
* re-evaluate default lock timeout in IWC (this could even be a version-based
change or whatever we want to do, but i like a default of zero).
* eradicate any usage of stuff like IndexWriter.isLocked, which IMO is
generally a bug.
* see if we can add back an AssertingLock and/or add lock mocking to mockfs,
but one that doesn't suck or hide bugs.
> Simplify Directory/lock api
> ---------------------------
>
> Key: LUCENE-6508
> URL: https://issues.apache.org/jira/browse/LUCENE-6508
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Assignee: Uwe Schindler
> Attachments: LUCENE-6508-deadcode1.patch, LUCENE-6508.patch,
> LUCENE-6508.patch
>
>
> See LUCENE-6507 for some background. In general it would be great if you can
> just acquire an immutable lock (or you get a failure) and then you close that
> to release it.
> Today the API might be too much for what is needed by IW.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
