[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562625#comment-14562625 ] Uwe Schindler commented on LUCENE-6507: --- The naming of this method was always trappy. I did not touch that last year when I refactored the lock factories. The method is just a factory to create an instance of the Lock class. Maybe it should be called newLockInstance, then it would be clear what happens. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562707#comment-14562707
]
Robert Muir commented on LUCENE-6507:
-
I disagree with the synopsis. The problem here has nothing to do with Directory
or the lock API at all... this is all bugs in NativeFSLockFactory, around this
behavior in the JDK:
{noformat}
On some systems, closing a channel releases all locks held by the Java virtual
machine on the underlying file regardless of whether the locks were acquired
via that channel or via another channel open on the same file. It is strongly
recommended that, within a program, a unique channel be used to acquire all
locks on any given file.
{noformat}
-1 to changing the Directory/lock API, when it will not even fix the problem:
even attempting to obtain() means you are screwed.
To me the correct solution is to fix NativeFSLockFactory to follow the strong
recommendations. Today it already has a global map to try to workaround issues:
{code}
private static final SetString LOCK_HELD = Collections.synchronizedSet(new
HashSetString());
{code}
Seems that this is wrong, and needs to be a map with unique file channels as
the 'value'.
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562733#comment-14562733
]
Robert Muir commented on LUCENE-6507:
-
Also, LockStressTest from our ant task is not exercising the intra-JVM case, it
has never failed on these things.
We should be seeing test failures.
But just staring at code, you can see the bugs/races:
{code}
// obtain()
if (obtained == false) { // not successful - clear up and move out
clearLockHeld(path); // #1
clear global map
final FileChannel toClose = channel;
channel = null;
IOUtils.closeWhileHandlingException(toClose); // #2 close channel
}
...
// close()
try {
if (lock != null) {
try {
lock.release();
lock = null;
} finally {
clearLockHeld(path);// #1 clear global map
}
}
} finally {
IOUtils.close(channel);// #2 close channel
channel = null;
}
{code}
#1 and #2 happen in the wrong order.
We must close the channel first for the current code to even stand a chance of
working.
IMO this should block the release.
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562643#comment-14562643 ] Simon Willnauer commented on LUCENE-6507: - yeah this seems to go into the right direction here IMO. I like acquireLock best and deprecate or delete the newLock 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562649#comment-14562649 ] Uwe Schindler commented on LUCENE-6507: --- Yeah. I would like the new behaviour, more. Unfortunately there is some code in IndexWriter currently that gets the Lock instance just to check if it is locked. We have to review this. Maybe we can simplify the whole thing. In any case, I will make (ähm aquire) a proposal! Maybe the Backwards Compatibility Policeman has a good solution :-) I also found dead code: the abstract class Lock.With class is dead (no longer used). So we should remove. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562630#comment-14562630 ] Simon Willnauer commented on LUCENE-6507: - why don't we just hide the obtain call behind it? I mean we can have makeLock() and makeLock(long timeout) and only return the lock once it's obtained to prevent the trappyness? 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562640#comment-14562640 ] Uwe Schindler commented on LUCENE-6507: --- Changing the behaviour of this already existing method would be an unexpected change, code outside Lucene would fall over that (like Infinispan directory,...). So we should break hard and invent a new name for the method, especially if we change behaviour. So code that wants to lock a directory fails to compile. I think we have 2 possibilities: - newLockInstance() with the current behaviour - lockDirectory() or aquireLock() or whatever to do the actual locking. - makeLock() should be removed so existing code fails to compile I am sorry that I did not fix that before release of Lucene 5.0. This was on my list but I missed to fix the name or change behaviour. This change here should also be reflected in the LockFactory class (not just in directory)... 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562775#comment-14562775
]
Robert Muir commented on LUCENE-6507:
-
Its precisely the same issue Uwe. See Simon's description, and i quote:
{quote}
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
{quote}
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy (it does not aquire lock, although its name implies) + NativeFSLock.close() has side effects
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562794#comment-14562794 ] Uwe Schindler commented on LUCENE-6507: --- As you both don't want to split this issue, I updated the summary/title. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy (it does not aquire lock, although its name implies) + NativeFSLock.close() has side effects
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562809#comment-14562809 ] Robert Muir commented on LUCENE-6507: - Well, I think we should try to simplify the API, as always. But to me that is polishing the silverware when the house is burning down. We need to fix the bugs first. As far as simplifying the API, it would be great if it was just one single method that returned an obtained-lock, and then these locks wouldn't need any mutable state. I'm not sure if all the crazy methods we have are really needed, we should see what is the minimal thing we can get away with. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy (it does not aquire lock, although its name implies) + NativeFSLock.close() has side effects
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562857#comment-14562857 ] Robert Muir commented on LUCENE-6507: - I still don't like that clearLockHeld calls toRealPath() which can throw an exception / does IO. And we already do this canonicalization to toRealPath in obtain() which is synced, so i think we can just save it as an instance variable and simplify this further. I will look into this. 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 Attachments: LUCENE-6507.patch 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562760#comment-14562760 ] Uwe Schindler commented on LUCENE-6507: --- Hi Robert, I agree, but that is another problem. From reading Simon's issue description, this issue is not about the bug you are talking about. The problem described here is the following problem: if you call makeLock() on a directory it just creates a lock instance, but does not actually lock. This is a bit confusing regarding the naming of the method. makeLock() makes you think that this method aquires the lock and returns an instance of the lock. Simon then had the problem that because of the stupid naming, he unlocked the unlocked (not yet locked) lock. This should be a no-op, so the bug may be there. This is why my initial response was to rename the stupid named makeLock() to newLockInstance(). makeLock sounds like this already creates the lock. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562783#comment-14562783 ] Simon Willnauer commented on LUCENE-6507: - I agree with rob that there is a bug in this code but honest. Once we opened that channel we have to close it again but that might release another processes lock. so I wonder how we can fix that ? 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562769#comment-14562769 ] Uwe Schindler commented on LUCENE-6507: --- In any case, it would be nice to get a reference here to the failed Elasticsearch test or an example of code broken by this, because it looks like Robert and Simon are talking about something completely different, than described here in the issue description. To me the issue description is quite clear: Directory#makeLock only creates lock instance but does not lock directory. The bugs in NativeFSLockFactory should please be moved to a new issue, its completely unrelated to the current issue. Sorry. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562788#comment-14562788 ] Robert Muir commented on LUCENE-6507: - The separate process is not an issue. see the javadocs for FileLock again, its for the given java virtual machine. NativeFSLockFactory is buggy within the same JVM, that needs to be fixed here. Then close() has no crazy side effects. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562787#comment-14562787 ] Simon Willnauer commented on LUCENE-6507: - oh nevermind - this is only within the same JVM 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
