lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LUCENE-6507) Directory#makeLock is trappy (it does not aquire lock, although its name implies) + NativeFSLock.close() has side effects
Date Thu, 28 May 2015 12:23:19 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler updated LUCENE-6507:
----------------------------------
    Summary: Directory#makeLock is trappy (it does not aquire lock, although its name implies)
+ NativeFSLock.close() has side effects  (was: Directory#makeLock is trappy)

> Directory#makeLock is trappy (it does not aquire lock, although its name implies) + NativeFSLock.close()
has side effects
> -------------------------------------------------------------------------------------------------------------------------
>
>                 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message