[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562770#comment-14562770
]
Robert Muir commented on LUCENE-6507:
-------------------------------------
The main missing thing i see, hopefully it will provoke the fail, is a simple
multi-threaded unit test for lockfactories that tests them directly.
The current stress test with a best chance of provoking bugs here
({{_testStressLocks}}) is \@Nightly, not sure how much real action it sees...
and is more of an integration test, and opens indexwriters and indexreaders.
Additionally it uses MockDirectoryWrapper, so there is additional stuff
happening, including locks being wrapped with mocks and so on.
> Directory#makeLock is trappy
> ----------------------------
>
> Key: LUCENE-6507
> URL: https://issues.apache.org/jira/browse/LUCENE-6507
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Simon Willnauer
>
> the lock API in Lucene is super trappy since the lock that we return form
> this API must first be obtained and if we can't obtain it the lock should not
> be closed since we might ie. close the underlying channel in the NativeLock
> case which releases all lock for this file on some operating systems. I think
> the makeLock method should try to obtain and only return a lock if we
> successfully obtained it. Not sure if it's possible everywhere but we should
> at least make the documentation clear here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
