You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2015/05/26 09:34:19 UTC
[jira] [Commented] (LUCENE-6499) WindowsFS misses to remove open
file handle if file is concurrently deleted
[ https://issues.apache.org/jira/browse/LUCENE-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14558788#comment-14558788 ]
Uwe Schindler commented on LUCENE-6499:
---------------------------------------
bq. I am not super happy since we now sync on top of an IO operation but I don't think there is a much easier solution unless we wanna use like an array of locks and the hash of the path to lock on two stages
WindowsFS is for tests only, so I think this limitation is fine. With the synchronization the "atomic" operation are really atomic (for the Lucene tests) and that is all what counts. I am sure, you and Robert now can be hired by M$ to implement their filesystems! :-)
Just one question about the test: You are using a CyclicBarrier(2) here. Is this just your own preference or is there a specific reason? Most tests like this use a CountDownLatch(1) that is decremented by the child thread once its ready so the main thread starts to fire it with some load. It's not some critique, I never used CyclicBarrier, so it is just my own interest...
> WindowsFS misses to remove open file handle if file is concurrently deleted
> ---------------------------------------------------------------------------
>
> Key: LUCENE-6499
> URL: https://issues.apache.org/jira/browse/LUCENE-6499
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/test-framework
> Affects Versions: 5.1
> Reporter: Simon Willnauer
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6499.patch, LUCENE-6499.patch
>
>
> WindowsFs has some race conditions when files are concurrently opened and deleted. A file might be successfully opened while concurrently deleted which should be prevented by the WindowsFS with an IOException / access denied. The problem is that we try to remove the leaked file handle form the internal map on close which fails since we fail to read the key from the filesystem since it has already been deleted. This manifests in subsequent `access denied` exceptions even though all streams on the file are closed.
--
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