[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562786#comment-14562786
]
Uwe Schindler commented on LUCENE-6507:
---------------------------------------
Robert,
thats another bug not related to the summary of this issue - its just
"mentioned" here in Simon's issue (sorry the issue description is
un-understandable). it is not makeLock() that's buggy, it is
NativeFSLock#close() thats buggy.
This issue is about bad naming and documentation of this method and that is how
I understood [~simonw].
Could we please split this issue into 2?:
- this issue about bad naming: I agree with Simon here
- a new issue to fix the NativeFSLock#close() method.
> 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]
