Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Thanks Mike!
I got your reply too late, closed it already.
Since I opened this issue might be not too bad I guess, anyhow leaving it
closed - I feel I made too much noise with this already.
"Michael McCandless (JIRA)" <[EMAIL PROTECTED]> wrote on 12/01/2007 09:27:27:
>
> [ https://issues.apache.org/jira/browse/LUCENE-665?page=com.
>
atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464261]
>
> Michael McCandless commented on LUCENE-665:
> ---
>
> OK sounds good.
>
> Weird that the reply-to was my email. Normally it's java-dev?
>
> I guess I would "resolve" it as "fixed", but don't "close" it yet, see
here:
>
> http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200605.
> mbox/[EMAIL PROTECTED]
>
Okay, next time...
> I don't think it's a "duplicate" since it really is its own bug even
> if it shared a root cause (& fix) with another bug. And I don't
> think it's a "won't fix" since it is now fixed (in the trunk).
I chose won't fix because theoretically this is still possible for write
locks.
>
> > temporary file access denied on Windows
> > ---
> >
> > Key: LUCENE-665
> > URL: https://issues.apache.org/jira/browse/LUCENE-665
> > Project: Lucene - Java
> > Issue Type: Bug
> > Components: Store
> >Affects Versions: 2.0.0
> > Environment: Windows
> >Reporter: Doron Cohen
> > Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch,
> FSWinDirectory_26_Sep_06.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
> >
> >
> > When interleaving adds and removes there is frequent
> opening/closing of readers and writers.
> > I tried to measure performance in such a scenario (for issue 565),
> but the performance test failed - the indexing process crashed
> consistently with file "access denied" errors - "cannot create a
> lock file" in "lockFile.createNewFile()" and "cannot rename file".
> > This is related to:
> > - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> > - user list questions due to file errors:
> > - http://www.nabble.com/OutOfMemory-and-IOException-Access-
> Denied-errors-tf1649795.html
> > - http://www.nabble.com/running-a-lucene-indexing-app-as-a-
> windows-service-on-xp%2C-crashing-tf2053536.html
> > - discussion on lock-less commits http://www.nabble.com/Lock-less-
> commits-tf2126935.html
> > My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> > I noticed that the problem is more frequent when locks are created
> on one disk and the index on another. Both are NTFS with Windows
> indexing service enabled. I suspect this indexing service might be
> related - keeping files busy for a while, but don't know for sure.
> > After experimenting with it I conclude that these problems - at
> least in my scenario - are due to a temporary situation - the FS, or
> the OS, is *temporarily* holding references to files or folders,
> preventing from renaming them, deleting them, or creating new files
> in certain directories.
> > So I added to FSDirectory a retry logic in cases the error was
> related to "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-
> service-on-xp%2C-crashing-tf2053536.html - there, in addition to the
> retry, gc() is invoked (I did not gc()). This is based on the *hope*
> that a access-denied situation would vanish after a small delay, and
> the retry would succeed.
> > I modified FSDirectory this way for "Access Denied" errors during
> creating a new files, renaming a file.
> > This worked fine for me. The performance test that failed before,
> now managed to complete. There should be no performance implications
> due to this modification, because only the cases that would
> otherwise wrongly fail are now delaying some extra millis and retry.
> > I am attaching here a patch - FSDirectory_Retry_Logic.patch - that
> has these changes to FSDirectory.
> > All "ant test" tests pass with this patch.
> > Also attaching a test case that demostrates the problem - at least
> on my machine. There two tests cases in that test file - one that
> works in system temp (like most Lucene tests) and one that creates
> the index in a different disk. The latter case can only run if the
> path ("D:" , "tmp") is valid.
> > It would be great if people that experienced these problems could
> try out this patch and comment whether it made any difference for them.
> > If it turns out useful for others as well, including this patch in
> the code might help to relieve some of those "frustration" user cases.
> > A comment on state of proposed patch:
> > - It is not a "ready to deploy" code - it has some debug printing,
> showing the cases that the "retry logic" actually took place.
> > - I am not sure if current
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
https://issues.apache.org/jira/browse/LUCENE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464263
]
Doron Cohen commented on LUCENE-665:
In case anyone else is looking for this - Jira "life cycle" under discussed in
http://www.nabble.com/jira-workflow-tf2459130.html#a6853917
(would have been nice if my "life cycle" query was expanded with
"workflow".../:-))
For the workflow this is also useful:
http://wiki.apache.org/lucene-hadoop-data/attachments/JiraWorkflow/attachments/workflow.png
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: https://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch,
> FSWinDirectory_26_Sep_06.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patch and passes with the patch.
> 2. FSDirectory_Retry_Logic.patch
> 3. Test_Output.txt- output of the test
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
https://issues.apache.org/jira/browse/LUCENE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464261
]
Michael McCandless commented on LUCENE-665:
---
OK sounds good.
Weird that the reply-to was my email. Normally it's java-dev?
I guess I would "resolve" it as "fixed", but don't "close" it yet, see here:
http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200605.mbox/[EMAIL
PROTECTED]
I don't think it's a "duplicate" since it really is its own bug even if it
shared a root cause (& fix) with another bug. And I don't think it's a "won't
fix" since it is now fixed (in the trunk).
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: https://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch,
> FSWinDirectory_26_Sep_06.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patc
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
https://issues.apache.org/jira/browse/LUCENE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464250
]
Doron Cohen commented on LUCENE-665:
Hi Michael,
Funny that I got this email with reply-to to you rather than the list.
Funnier part is that I really wanted to reply you directly rather than the
list. Is JIRA a mind reader?
Yes, I would like to close the issue - I already said that in my Oct 30
post.
I would like to do this myself - should I "close" or "resolve" the issue?
or perhaps first resolve and then close? I think I read somewhere the life
cycle of an issue but I cannot find it. I am also wondering if it should be
with "won't fix" or "duplicate"?
Thanks,
Doron
atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464174]
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: https://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch,
> FSWinDirectory_26_Sep_06.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming",
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
https://issues.apache.org/jira/browse/LUCENE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464174
]
Michael McCandless commented on LUCENE-665:
---
Doron can we close this issue now? I think native locking and/or less IO
operations with lockless commits has resolved it?
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: https://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch,
> FSWinDirectory_26_Sep_06.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patch and passes with the patch.
> 2. FSDirectory_Retry_Logic.patch
> 3. Test_Output.txt- output of the test with the patch, on my XP. Only the
> createNewFile() case had to be bypassed in this test, but for another program
> I also saw the renameFile() being bypassed.
> - Doron
--
This message is automatically generated by
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12445724 ]
Doron Cohen commented on LUCENE-665:
> Odd that just by using native locking, it stopped your issues.
Agree. I did not expect that to happen, since indeed I saw in the past
exceptions on renameFile, though most exceptions were in locks activity. So I
ran it many times, with an antivirus scan, etc. But it always passes. Therefore
I would not object to closing this issue - If I cannot test it I cannot fix it.
But for the same reason, I would like to see native locks becoming the default.
> setLockPrefix()
I'll take this one to a seprate thread in dev list.
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch,
> FSWinDirectory_26_Sep_06.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12445540 ]
Michael McCandless commented on LUCENE-665:
---
Odd that just by using native locking, it stopped your issues. Lucene (without
lock-less commits) does quite a bit of file renaming (eg the deletable renaming
in your exception above). I don't get why switching to native locking by
itself would fix the renaming errors.
Yes the lock prefix is likely to not match when the machines mount to a
different point, and almost certainly not if the machines are different OSs.
To deal with this I just use LockFactory.setLockPrefix() after the LockFactory
has been assigned to a directory. I added to the Javadoc for that method in
the native locking implementation for exactly this use case.
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch,
> FSWinDirectory_26_Sep_06.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12445507 ]
Doron Cohen commented on LUCENE-665:
Michael, I am not able to generate this with native locks. (did not try with
lockless commits).
Which brings me to think that native locks should be made default?
There is another thing that bothers me with locks, in NFS or other shared fs
situations:
Locks are maintained in a specified folder, but a lock file name is derived
from the full path of the index dir, actually the cannonical name of this dir.
So, if the same index is accessed by two machines, the / /
root of that index dir must be named the same in all the machines on which
Lucene is invoked to access/maintain that index.
The documentation for File.getCanonicalPath() says that it is system dependent.
So I am not even sure how it can be guaranteed that Lucene used on Linux and
Lucene used on Windows (say) that accesss the same index would be able to lock
on the same index. And for two Windows machines, admin would have to verify
that the index fs (samba/afs/nfs) mounts with the same drive letter.
This seems like a limitation on one hand, and also as a source for possible
problems, when users mis configure their mount names.
I may be missing someting trivial here, because it seems too wrong to be
true... I'll let the list comment on that...
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch,
> FSWinDirectory_26_Sep_06.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this pa
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12445301 ]
Michael McCandless commented on LUCENE-665:
---
Doron, I finally managed to see an exception like yours above, but I had to
have the Windows Explorer open to the index directory and then right click on
files, while the indexing was happening. Once I could get this to happen I
then found that the lock-less patch ( LUCENE-701 ) plus native locking *seemed*
to prevent the issue (I think it should because no file renaming is done). But
given how hard it is for me to reproduce this, can you try in your area the
combination of lock-less and native locking to see if that prevents this issue?
Thanks.
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch,
> FSWinDirectory_26_Sep_06.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRe
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
"Michael McCandless (JIRA)" <[EMAIL PROTECTED]> wrote on 20/09/2006 04:41:26: > Doron, which version of TortoiseSVN did you have installed when you > got the exceptions? TortoiseSVN 1.3.5, Build 6804 - 32 Bit Subversion 1.3.2, apr 0.9.7 apr-iconv 0.9.7 apr-utils 0.9.7 berkeley db 4.3.28 neon 0.25.4 OpenSSL 0.9.8a 11 Oct 2005 zlib 1.2.3 My env: Microsoft Windows XP Professional Version 5.1.2600 Service Pack 2 Build 2600 Processor x86 Family 6 Model 13 Stepping 6 GenuineIntel ~1998 Mhz It is a laptop, btw. > I've installed version 1.4.0 on my Windows XP SP2 box, and then ran > your stress test just fine, ie, I can't reproduce the errors (to > verify that lock-less commits fixes this). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12436220 ]
Michael McCandless commented on LUCENE-665:
---
Doron, which version of TortoiseSVN did you have installed when you got the
exceptions?
I've installed version 1.4.0 on my Windows XP SP2 box, and then ran your stress
test just fine, ie, I can't reproduce the errors (to verify that lock-less
commits fixes this).
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, FSWinDirectory.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patch and passes with the patch.
> 2. FSDirectory_Retry_Logic.patch
> 3. Test_Output.txt- output of the test with the patch, on my XP. Only the
> createNewFile() case had to be bypassed in this test, but for another program
> I also saw the renameFile() being bypassed
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[ http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12435414 ] Doron Cohen commented on LUCENE-665: My summary - and "what's next" proposal - for the discussion so far (in comments for issue-665 and in thread http://www.nabble.com/-jira--Created%3A-%28LUCENE-665%29-temporary-file-access-denied-on-Windows-tf2167540.html): [1] Reported problem can be regenerated in Windows in presence of programs monitoring files. [2] The proposed fix adds retry after 100ms delay in rare cases where the problem occurs. [3] That fix reduces much the chances of the problem but does not really solve it. [4] Proposed fix for FSDirectry not accepted because: [4.1] 100ms second may be too long for highly interactive programs. [4.2] 100ms can be insufficient in some cases. [4.3] non windows environments might be affected with no justification. [4.4] work in progress "lock-less" commits may reduce chances for this problem. [5] A Windows-specific implementation of FSDir that would not be the default, but would be available for application to select, was proposed as a better place to host this retry logic, to be available for applications at least until the "lock-less" commits is available for use and proves to solve the same problem. So, I intend to write this solution as outlined in [5] above. It would be optional, definitely not the default. Applications would be able to use it for Windows environments. The retry behavior would be controlled. In addition, would be controlled if to apply retry logic for lock-delete or not - the default would be 'no' - because in NFS, a delete may return 'failed' due to time-out although it actually succeeded, and a retry logic in this case might "kill" voluntary file locking schemes like the default one used by Lucene (though I assume that with the NFS native locks proposed by Michael this is not the case). Hope this reflects the discussion so far... > temporary file access denied on Windows > --- > > Key: LUCENE-665 > URL: http://issues.apache.org/jira/browse/LUCENE-665 > Project: Lucene - Java > Issue Type: Bug > Components: Store >Affects Versions: 2.0.0 > Environment: Windows >Reporter: Doron Cohen > Attachments: FSDirectory_Retry_Logic.patch, > FSDirs_Retry_Logic_3.patch, Test_Output.txt, TestInterleavedAddAndRemoves.java > > > When interleaving adds and removes there is frequent opening/closing of > readers and writers. > I tried to measure performance in such a scenario (for issue 565), but the > performance test failed - the indexing process crashed consistently with > file "access denied" errors - "cannot create a lock file" in > "lockFile.createNewFile()" and "cannot rename file". > This is related to: > - issue 516 (a closed issue: "TestFSDirectory fails on Windows") - > http://issues.apache.org/jira/browse/LUCENE-516 > - user list questions due to file errors: > - > http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html > - > http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html > - discussion on lock-less commits > http://www.nabble.com/Lock-less-commits-tf2126935.html > My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs. > I noticed that the problem is more frequent when locks are created on one > disk and the index on another. Both are NTFS with Windows indexing service > enabled. I suspect this indexing service might be related - keeping files > busy for a while, but don't know for sure. > After experimenting with it I conclude that these problems - at least in my > scenario - are due to a temporary situation - the FS, or the OS, is > *temporarily* holding references to files or folders, preventing from > renaming them, deleting them, or creating new files in certain directories. > So I added to FSDirectory a retry logic in cases the error was related to > "Access Denied". This is the same approach brought in > http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html > - there, in addition to the retry, gc() is invoked (I did not gc()). This is > based on the *hope* that a access-denied situation would vanish after a small > delay, and the retry would succeed. > I modified FSDirectory this way for "Access Denied" errors during creating a > new files, renaming a file. > This worked fine for me. The performance test that failed before, now managed > to complete. There should be no performance implications due to this > modification, because only the cases that would otherwise wrongly fail are > now delaying some extra millis and retry. > I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these > changes to FSDirectory. > All "ant test" tests pass w
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Yonik Seeley wrote: > If it will happen so rarely, make it simpler and go directly for > segments_(N-1)... (treat it like your previous plan if segments_N.done > hadn't been written yet). Yes, true, we could just fall back to the prior segments_(N-1) file in this case. Though that means the reader will likely just hit an IOException trying to load the segments (since a commit is "in process") and then I'd have to re-retry against segments_N. You need to fall back in any case... (remember the writer crashing scenario). Reusing the fallback logic makes the code simpler in a case that will almost never happen. It's really just a question of if you put in extra retry logic or not. Yes, but with the separate file (segments_N.done) approach this is just an file exists check. In other words, the reader does a dir listing, finds the most recent segments_N for which there also exists a segments_N.done and uses that. But you're right I could re-use the retry logic I already have now, but instead of retrying forwards (N+1), retry backwards specifically when hitting an IOException when reading the contents of the segments file. I don't think it's that hard to implement ... my biggest worry is whether filesystem caching (for the likes of NFS) will cause delays, ie does NFS "cache" (under its own timeout policy) the fact that the file was N bytes when last it was opened? I would rather have a solution that doesn't rely on the caching policies of the filesystem. I will try both approaches & report back! I've been using NFS as my "proxy" for "least common denominator" I think that's a safe bet ;-) NFS v2 or v3? Good question -- so far only v3. I will test v2 as well. So many filesystems! Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Correct, but if you are using a distributing index, you should make copies of it, not access the same index (on one machine) from multiple machines. If doing this, you would still need some sort of server process on the master, and if that is available, it can control the distribution of the index - so once again, no problem with NFS do to renames, etc. I guess I just don't see how any NFS issues should matter in a properly deployed Lucene - even multiserver - environment. It is similar to the class reason why unix databases never used/ needed file locks - the server process managed the locks internally - which is far more efficient. On Sep 15, 2006, at 9:49 AM, Yonik Seeley wrote: On 9/15/06, robert engels <[EMAIL PROTECTED]> wrote: Why not just use a dedicated server with an HTTP/TCP listener and let it respond to Lucene queries. If you have more than one server to handle the load, you need to distribute the index to all the search boxes. NFS is an easy way, but I imagine performance would suffer. Solr can use rsync to update each server with the segment changes, but other methods like letting NFS handle it are possible. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
On 9/15/06, robert engels <[EMAIL PROTECTED]> wrote: Why not just use a dedicated server with an HTTP/TCP listener and let it respond to Lucene queries. If you have more than one server to handle the load, you need to distribute the index to all the search boxes. NFS is an easy way, but I imagine performance would suffer. Solr can use rsync to update each server with the segment changes, but other methods like letting NFS handle it are possible. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
By a lot of the comments in these threads, it seems that people are accessing their Lucene indexes via NFS (or some other network protocol). Why not just use a dedicated server with an HTTP/TCP listener and let it respond to Lucene queries. I have to believe it would be orders of magnitude faster. Just curious. On Sep 14, 2006, at 10:43 PM, Yonik Seeley wrote: On 9/14/06, Michael McCandless <[EMAIL PROTECTED]> wrote: > If it will happen so rarely, make it simpler and go directly for > segments_(N-1)... (treat it like your previous plan if segments_N.done > hadn't been written yet). Yes, true, we could just fall back to the prior segments_(N-1) file in this case. Though that means the reader will likely just hit an IOException trying to load the segments (since a commit is "in process") and then I'd have to re-retry against segments_N. You need to fall back in any case... (remember the writer crashing scenario). Reusing the fallback logic makes the code simpler in a case that will almost never happen. It's really just a question of if you put in extra retry logic or not. I've been using NFS as my "proxy" for "least common denominator" I think that's a safe bet ;-) NFS v2 or v3? -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
On 9/14/06, Michael McCandless <[EMAIL PROTECTED]> wrote: > If it will happen so rarely, make it simpler and go directly for > segments_(N-1)... (treat it like your previous plan if segments_N.done > hadn't been written yet). Yes, true, we could just fall back to the prior segments_(N-1) file in this case. Though that means the reader will likely just hit an IOException trying to load the segments (since a commit is "in process") and then I'd have to re-retry against segments_N. You need to fall back in any case... (remember the writer crashing scenario). Reusing the fallback logic makes the code simpler in a case that will almost never happen. It's really just a question of if you put in extra retry logic or not. I've been using NFS as my "proxy" for "least common denominator" I think that's a safe bet ;-) NFS v2 or v3? -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Yonik Seeley wrote: Good point! A reader could easily know that's it's dealing with an unfinished segments file (since the file says how many segments it has) and then sleep/retry until the file completes, which should be a rare event. Note that such contention in the current Lucene (ie, on the commit lock) results in a 1.0 second delay and then retry. Though what if the writer has crashed and so the new segments file will never be done? I guess reader could fallback to the previous _(N-1) file after some time at the cost of more delay. If it will happen so rarely, make it simpler and go directly for segments_(N-1)... (treat it like your previous plan if segments_N.done hadn't been written yet). Yes, true, we could just fall back to the prior segments_(N-1) file in this case. Though that means the reader will likely just hit an IOException trying to load the segments (since a commit is "in process") and then I'd have to re-retry against segments_N. I think that approach would work but I'm still worried about the interaction with filesystem caching. EG how much latency is added by the caching before it realizes this file now has some more data? Local filesystems don't have that problem. Right, in local filesystems the caching is always "coherent" (thank goodness) so you don't have these issues. Still I think Lucene needs to aim to work with the "least common denominator" of all filesystems (to cause the fewest problems for all our "diverse" users using "diverse" filesystems). Meaning, don't use certain filesystem operations / semantics / feature, when possible. Not using "file renaming" is a good example (since it's unreliable on windows). And, don't expect "cache coherence for a file's contents" (by never re-using the same filename) is another. I've been using NFS as my "proxy" for "least common denominator" in testing a native locking implementation (will submit patch soon) and for testing lock-less commits. Remote filesystems would hopefully check for new blocks on demand (as you try to read it). Well I wish I could share this optimism :) NFS clients at best try for "close to open cache coherence" (and not true cache coherence since it's too costly), eg described here for the recent Linux NFS clients: http://nfs.sourceforge.net I think some NFS clients don't achieve even that. I *think* if the NFS client does implement this then you're right that re-opening the file should flush the cache. But ... I'd rather not rely on the caching at all if we can avoid it (by opening the file only once, when it's complete). This way we don't require cache coherence on the file contents ... Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
On 9/14/06, Michael McCandless <[EMAIL PROTECTED]> wrote: Yonik Seeley wrote: >> > >> But, I'm still renaming segments_N.new -> segments_N, >> > > >> > > Hmmm, remind me why you need the .new file? Why can't you just >> create >> > > segments_N after you are finished writing all of the segments? >> > >> > Because there could be a reader that tries to read the file before it's >> > done being written. It would hit EOF and throw an IOException. >> >> Ahh, right... unlikely (the segments file is pretty small), but possible. >> >> Another alternative (since this changes the index format anyway) is to >> put something in the segments file to detect if it's partially >> written... something like the size of the file or the number of >> segments. I don't know if the extra complexity would be worth saving >> the creation time of an extra file or not... > > Hey wait... the segments file already has the number of segments. > Can't you tell if it's not yet complete? Good point! A reader could easily know that's it's dealing with an unfinished segments file (since the file says how many segments it has) and then sleep/retry until the file completes, which should be a rare event. Note that such contention in the current Lucene (ie, on the commit lock) results in a 1.0 second delay and then retry. Though what if the writer has crashed and so the new segments file will never be done? I guess reader could fallback to the previous _(N-1) file after some time at the cost of more delay. If it will happen so rarely, make it simpler and go directly for segments_(N-1)... (treat it like your previous plan if segments_N.done hadn't been written yet). I think that approach would work but I'm still worried about the interaction with filesystem caching. EG how much latency is added by the caching before it realizes this file now has some more data? Local filesystems don't have that problem. Remote filesystems would hopefully check for new blocks on demand (as you try to read it). -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
: Even though I don't agree with this patch... 100ms is WAY TOO long : for a highly interactive index. agreed. : > then, it is encouraging that similar retry logic is working for other : > projects, and that the retry is both rare and short. the examples of other projects I've seen mentioned are Ant (a command line user tool) and the Subversion server (A system that intrinsicly deals with network communication) ... both of these seem like situations where adding a bit of wait/retry logic doesn't add much overhead to the overall process -- i doubt either of those projects would be very happy if a low level API they used (say for example: an XML parsing library) employed similar wait/retry logic in a manner they couldn't control. Hence my suggestion about splitting this logic into a new Directory implementation: let the applications built on top of Lucene decide wether they want to protect themselves from this or not. -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
: We could retry only for IOExceptions, possibly only those specifying : "access denied" in their root cause message. This would narrow the range of : cases the retry logic is applied. In fact the first version had this : narrowing logic, but it was removed after a comment uncomfortable with : relying on specific exception message. Narrowing this way the retry is i wouldn't feel comfortable testing the root cause message String either -- but explicitly catching IOException seems a lot better to me then just "Throwable" -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Yonik Seeley wrote: > >> But, I'm still renaming segments_N.new -> segments_N, > > > > Hmmm, remind me why you need the .new file? Why can't you just create > > segments_N after you are finished writing all of the segments? > > Because there could be a reader that tries to read the file before it's > done being written. It would hit EOF and throw an IOException. Ahh, right... unlikely (the segments file is pretty small), but possible. Another alternative (since this changes the index format anyway) is to put something in the segments file to detect if it's partially written... something like the size of the file or the number of segments. I don't know if the extra complexity would be worth saving the creation time of an extra file or not... Hey wait... the segments file already has the number of segments. Can't you tell if it's not yet complete? Good point! A reader could easily know that's it's dealing with an unfinished segments file (since the file says how many segments it has) and then sleep/retry until the file completes, which should be a rare event. Note that such contention in the current Lucene (ie, on the commit lock) results in a 1.0 second delay and then retry. Though what if the writer has crashed and so the new segments file will never be done? I guess reader could fallback to the previous _(N-1) file after some time at the cost of more delay. I think that approach would work but I'm still worried about the interaction with filesystem caching. EG how much latency is added by the caching before it realizes this file now has some more data? I'd like to have a solution for Lucene whereby we are invariant to the filesystem's caching policies. I think the good news here is we have quite a few options on how to never use file renaming in Lucene (thanks to its simplicity!). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Even though I don't agree with this patch... 100ms is WAY TOO long for a highly interactive index. On Sep 13, 2006, at 11:52 PM, Doron Cohen wrote: Hoss Man commented on LUCENE-665: FYI: on the surface FSDirs_Retry_Logic_3.patch scares me because in many cases wait/retry logic is impossed inside of catch(Throwable) blocks ... that's seems a little too broad to me. Chris Hostetter <[EMAIL PROTECTED]> wrote on 13/09/2006 14:57:29: I agree in spirit, but the caveat to that is that if we silently work arround the problem at a very low level, it can lead to situations were lucene is constaintly waiting and retrying every single operation -- which may lead people to assume Lucene itself is slow just because of their environment. We could retry only for IOExceptions, possibly only those specifying "access denied" in their root cause message. This would narrow the range of cases the retry logic is applied. In fact the first version had this narrowing logic, but it was removed after a comment uncomfortable with relying on specific exception message. Narrowing this way the retry is applied only in cases of this unexpected "access denied" error, and: - these cases are very rare - retry is for 100ms - current alternative is (possibly) a corrupted index A solution without retry, if found, is far better of course - but until then, it is encouraging that similar retry logic is working for other projects, and that the retry is both rare and short. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Hoss Man commented on LUCENE-665: > FYI: on the surface FSDirs_Retry_Logic_3.patch scares me because in > many cases wait/retry logic is impossed inside of catch(Throwable) > blocks ... that's seems a little too broad to me. Chris Hostetter <[EMAIL PROTECTED]> wrote on 13/09/2006 14:57:29: > I agree in spirit, but the caveat to that is that if we silently > work arround the problem at a very low level, it can lead to situations > were lucene is constaintly waiting and retrying every single operation -- > which may lead people to assume Lucene itself is slow just because of > their environment. We could retry only for IOExceptions, possibly only those specifying "access denied" in their root cause message. This would narrow the range of cases the retry logic is applied. In fact the first version had this narrowing logic, but it was removed after a comment uncomfortable with relying on specific exception message. Narrowing this way the retry is applied only in cases of this unexpected "access denied" error, and: - these cases are very rare - retry is for 100ms - current alternative is (possibly) a corrupted index A solution without retry, if found, is far better of course - but until then, it is encouraging that similar retry logic is working for other projects, and that the retry is both rare and short. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
On 9/13/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: On 9/13/06, Michael McCandless <[EMAIL PROTECTED]> wrote: > Yonik Seeley wrote: > >> But, I'm still renaming segments_N.new -> segments_N, > > > > Hmmm, remind me why you need the .new file? Why can't you just create > > segments_N after you are finished writing all of the segments? > > Because there could be a reader that tries to read the file before it's > done being written. It would hit EOF and throw an IOException. Ahh, right... unlikely (the segments file is pretty small), but possible. Another alternative (since this changes the index format anyway) is to put something in the segments file to detect if it's partially written... something like the size of the file or the number of segments. I don't know if the extra complexity would be worth saving the creation time of an extra file or not... Hey wait... the segments file already has the number of segments. Can't you tell if it's not yet complete? -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
On 9/13/06, Michael McCandless <[EMAIL PROTECTED]> wrote: Yonik Seeley wrote: >> But, I'm still renaming segments_N.new -> segments_N, > > Hmmm, remind me why you need the .new file? Why can't you just create > segments_N after you are finished writing all of the segments? Because there could be a reader that tries to read the file before it's done being written. It would hit EOF and throw an IOException. Ahh, right... unlikely (the segments file is pretty small), but possible. Another alternative (since this changes the index format anyway) is to put something in the segments file to detect if it's partially written... something like the size of the file or the number of segments. I don't know if the extra complexity would be worth saving the creation time of an extra file or not... -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Yonik Seeley wrote: But, I'm still renaming segments_N.new -> segments_N, Hmmm, remind me why you need the .new file? Why can't you just create segments_N after you are finished writing all of the segments? Because there could be a reader that tries to read the file before it's done being written. It would hit EOF and throw an IOException. And also, to avoid trouble with filesystem caching I'd to only ever open a given file X once X is done being written. I think the "write once" approach (never re-using a file-name) prevents the kinds of caching issues that eg cause the problems over NFS. however I think we could remove that one by instead creating a separate "done" file, eg "segments_N.done" Yes, that sounds like it would work. No renaming... cool! I think so! I will test it... Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
On 9/13/06, Michael McCandless <[EMAIL PROTECTED]> wrote: But, I'm still renaming segments_N.new -> segments_N, Hmmm, remind me why you need the .new file? Why can't you just create segments_N after you are finished writing all of the segments? however I think we could remove that one by instead creating a separate "done" file, eg "segments_N.done" Yes, that sounds like it would work. No renaming... cool! -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
On 9/13/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: I agree in spirit, but the caveat to that is that if we silently work arround the problem at a very low level, it can lead to situations were lucene is constaintly waiting and retrying every single operation -- which may lead people to assume Lucene itself is slow just because of their environment. Good point. In practice I think it's only a problem if it's reproducable (happens very often). I'd be surprised if it was that reproducable since lucene wouldn't be usable at all for some people if that were the case. A warning of some kind would seem to be most appropriate. An exception thrown can be researched and documented in such a way that application developers can fix it themselves. The problem is, it could be spurious enough that one wouldn't get the exception until it's in production, or sold to a customer, etc... too late to debug. It would be nice if we could handle the spurious error. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
: I don't think the Windows impl should be the default for Windows : systems. Nor do i ... but what is the "default" Direcotry implimentation of "Lucene"? There are convinince methods in IndexReader, IndexWriter, and IndexSearcher for opening FSDirectories based on a String (name) or a File object -- and those should probably never change; but a new WindowsFSDirectory option could be built, and applications which want to use it so they can be as robust as possible at the potential expense of speed can use it if they choose. I retract part of that statement acctually: I can't think of any compelling reason why the methods that currently take in a String or a File and implicitly assume FSDirectory couldn't be changed to try and "auto-detct" the OS and make the best corrisponding assumption -- Apps that allways want an FSDirectory could open one explicitly just like aps that want a WindowsFSDirectory explicitly. -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
I don't think the Windows impl should be the default for Windows systems. Windows properly configured server environments would not have this problem. On Sep 13, 2006, at 5:32 PM, Dejan Nenov wrote: I concur with Hoss - a default to immediate exception throwing and optional implementation for Windows would server everyone best I think. Dejan -Original Message- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 2:57 PM To: java-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows : > While it's very tempting to take the attitude of "it's Microsoft's : > fault for exposing this API" or "it's that software's fault for using : > this API", doing so will only hurt our users: they either suffer (at : > best), or find some other search software to use (at worst?). : If this can be fixed/worked-around in a manner that does not penalize : users w/o this problem, then that's what we should do. I agree in spirit, but the caveat to that is that if we silently work arround the problem at a very low level, it can lead to situations were lucene is constaintly waiting and retrying every single operation -- which may lead people to assume Lucene itself is slow just because of their environment. An exception thrown can be researched and documented in such a way that application developers can fix it themselves. An exception that is silently worked arround with a performance penalty will be a ghost in the machine -- which can do more harm to the Lucene User community at large? Looking at the patch, I can't help but wonder if this is motivation enough to create a new WindowsFSDirectory implementation, which attempts to work arround any/all issues of windows filesystems, with documentation clarifying what it does and what the performance impacts are? -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
I concur with Hoss - a default to immediate exception throwing and optional implementation for Windows would server everyone best I think. Dejan -Original Message- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 2:57 PM To: java-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows : > While it's very tempting to take the attitude of "it's Microsoft's : > fault for exposing this API" or "it's that software's fault for using : > this API", doing so will only hurt our users: they either suffer (at : > best), or find some other search software to use (at worst?). : If this can be fixed/worked-around in a manner that does not penalize : users w/o this problem, then that's what we should do. I agree in spirit, but the caveat to that is that if we silently work arround the problem at a very low level, it can lead to situations were lucene is constaintly waiting and retrying every single operation -- which may lead people to assume Lucene itself is slow just because of their environment. An exception thrown can be researched and documented in such a way that application developers can fix it themselves. An exception that is silently worked arround with a performance penalty will be a ghost in the machine -- which can do more harm to the Lucene User community at large? Looking at the patch, I can't help but wonder if this is motivation enough to create a new WindowsFSDirectory implementation, which attempts to work arround any/all issues of windows filesystems, with documentation clarifying what it does and what the performance impacts are? -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Chris Hostetter wrote: : > While it's very tempting to take the attitude of "it's Microsoft's : > fault for exposing this API" or "it's that software's fault for using : > this API", doing so will only hurt our users: they either suffer (at : > best), or find some other search software to use (at worst?). : If this can be fixed/worked-around in a manner that does not penalize : users w/o this problem, then that's what we should do. I agree in spirit, but the caveat to that is that if we silently work arround the problem at a very low level, it can lead to situations were lucene is constaintly waiting and retrying every single operation -- which may lead people to assume Lucene itself is slow just because of their environment. An exception thrown can be researched and documented in such a way that application developers can fix it themselves. An exception that is silently worked arround with a performance penalty will be a ghost in the machine -- which can do more harm to the Lucene User community at large? Looking at the patch, I can't help but wonder if this is motivation enough to create a new WindowsFSDirectory implementation, which attempts to work arround any/all issues of windows filesystems, with documentation clarifying what it does and what the performance impacts are? I think we can have a solution that doesn't do any file renaming. With the lockless fixes (I'm still working on them...) I've already removed quite a few renames by having the segments file record explicitly which generation is current (I needed this for the .del and norm files anyway). I've also removed the deletable file entirely, so it doesn't get renamed. But, I'm still renaming segments_N.new -> segments_N, however I think we could remove that one by instead creating a separate "done" file, eg "segments_N.done" or something. So the existence of the "done" file means the segments_N file can safely be loaded. I haven't tried this yet but I think such an approach should work and would solve the concerns around sleep/retry? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
: > While it's very tempting to take the attitude of "it's Microsoft's : > fault for exposing this API" or "it's that software's fault for using : > this API", doing so will only hurt our users: they either suffer (at : > best), or find some other search software to use (at worst?). : If this can be fixed/worked-around in a manner that does not penalize : users w/o this problem, then that's what we should do. I agree in spirit, but the caveat to that is that if we silently work arround the problem at a very low level, it can lead to situations were lucene is constaintly waiting and retrying every single operation -- which may lead people to assume Lucene itself is slow just because of their environment. An exception thrown can be researched and documented in such a way that application developers can fix it themselves. An exception that is silently worked arround with a performance penalty will be a ghost in the machine -- which can do more harm to the Lucene User community at large? Looking at the patch, I can't help but wonder if this is motivation enough to create a new WindowsFSDirectory implementation, which attempts to work arround any/all issues of windows filesystems, with documentation clarifying what it does and what the performance impacts are? -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12434551 ]
Hoss Man commented on LUCENE-665:
-
FYI: on the surface FSDirs_Retry_Logic_3.patch scares me because in many cases
wait/retry logic is impossed inside of catch(Throwable) blocks ... that's seems
a little too broad to me.
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, Test_Output.txt, TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patch and passes with the patch.
> 2. FSDirectory_Retry_Logic.patch
> 3. Test_Output.txt- output of the test with the patch, on my XP. Only the
> createNewFile() case had to be bypassed in this test, but for another program
> I also saw the renameFile() being bypassed.
> - Doron
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the ad
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
It you are using it in this environment, why wouldn't you just disable the locks completely, and do your own internal lock management. It would be far faster and simpler, and you would not be subject to issues like his. On Sep 13, 2006, at 4:20 PM, Yonik Seeley wrote: On 9/13/06, Michael McCandless <[EMAIL PROTECTED]> wrote: While it's very tempting to take the attitude of "it's Microsoft's fault for exposing this API" or "it's that software's fault for using this API", doing so will only hurt our users: they either suffer (at best), or find some other search software to use (at worst?). +1 If this can be fixed/worked-around in a manner that does not penalize users w/o this problem, then that's what we should do. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
On 9/13/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: the problem stems from software that does what seems to be the equivilent of trying to open any file that has recently been closed by any other app ... as a java library Lucene shouldn't be expected to guard against that any more then it should be expected to guard against the possibility of people randmoly renaming or deleting files in the index directory The problem is the mere act of observing can cause the problem on Windows... and it's not limited to automated programs. What if a sysadmin executes something that looks at the index files - perhaps a find or ls with the right params could trigger it. Since we can't fix this problem, only make it less likely, maybe we should also put something in the FAQ about avoiding even looking at index files on Windows. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
On 9/13/06, Michael McCandless <[EMAIL PROTECTED]> wrote: While it's very tempting to take the attitude of "it's Microsoft's fault for exposing this API" or "it's that software's fault for using this API", doing so will only hurt our users: they either suffer (at best), or find some other search software to use (at worst?). +1 If this can be fixed/worked-around in a manner that does not penalize users w/o this problem, then that's what we should do. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Bruce Ritchie wrote: No, I've just seen this jira issue because of your email - my last investigation of the issue was last year for which I personally did not uncover the cause nor a simple solution to the issue. Instead, we took the severe approach to just rebuild the index which itself causes issues (not technical, more customer satisfaction). This is precisely why I publicized this sneaky issue in the first place (and many thanks to Doron for actually tracking it down!!): people who hit it never can get to the bottom of it, and then just suffer through the consequences or stop using Lucene entirely. Nobody would even know to uninstall TortoiseSVN (or one of the many other software packages that may cause this). At least Ant and SVN (the server) have taken this same attitude (of trying to work around temporary file rename failures). While it's very tempting to take the attitude of "it's Microsoft's fault for exposing this API" or "it's that software's fault for using this API", doing so will only hurt our users: they either suffer (at best), or find some other search software to use (at worst?). The fact that this is an OS level API only means that more software over time is going to use it. So, maybe you have Lucene working fine now, but suddenly on installing new software XYZ you're gonna be hitting these intermittant errors. Or worse, your users, maybe a million installed desktops, will start hitting those errors... Furthermore, because Lucene has such a wonderfully simple architecture, it's not so hard to change it to never do any file renaming (I will try this with the lockless changes which already do far less renaming). Meaning, if this is such a simple change for Lucene with no other consequences, why not do it to prevent all these problems? The less Lucene can assume about the filesystem it's using, the more portable it will be. I agree that Lucene should not and can not recover from catastrophic things (like virus checker deciding a .fnm file contains a virus!), but this one seems very much like a low hanging fruit. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
> The proper solution is to have your software installer disable the > indexing on the directory. I think you are stuck on indexing ... It's not just indexing, it can be any software that uses this windows api. > If you don't any index updates are going to be abysmally slow anyway > - and if you do a lot you will bring your clients systems to their > knees (sounds like a bad situation for them). > > You should also document in the installation guide for your software the > requirements, and how certain software packages (indexers and virus scanners) > should be disable on the your software packages data directories. I don't disagree about documenting the potential issues, indeed it's a very valid suggestion. However your suggestion to disable virus scanners I believe is not reasonable for consumers, nor is the ability to diable even possible in a lot of cases without an uninstall. I see we are not going to agree on this potential solution to this issue so I'm going to disengage from this discussion - I believe I've made my view clear enough for those who have commit abilities to take it into consideration. Regards, Bruce Ritchie On Sep 13, 2006, at 3:37 PM, Bruce Ritchie wrote: > I'm afraid it's just not that simple. Lucene is not a server > application as you claimed in your first reply - it's a java based > search library. > Just because it's most often used on servers does not equate to it > always being used on servers for which disabling the index service is > a reasonable thing to do. We use it in a desktop application in > addition to server applications, and being a java based application we > want to neither have to tell our clients to disable indexing, or > tortoisesvn, or any other software they may have, nor to have to > insert something into the registry (if indeed such a thing exists). > > Now, I'm not expecting lucene to be able to recover if a virus scanner > decides to mangle an index file or any other such extreme behavior, > but I do expect it to behave correctly in the face of what I believe > is a common enough issue on a very commonly used OS. While it would be > ideal for Java itself to workaround the issue I don't think we can > expect that to happen for a while. > > > Our few choices now are to have a custom directory which has the > simple workaround in it, patch lucene everytime we have a new release, > or ignore the issue and have customers complain. While patching lucene > is possible for me I personally think this a worthy enough issue to be > included into lucene proper. > > > Regards, > > Bruce Ritchie > > > -----Original Message- > From: robert engels [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 13, 2006 4:13 PM > To: java-dev@lucene.apache.org > Subject: Re: [jira] Commented: (LUCENE-665) temporary file access > denied on Windows > > Start -> Administrative Tools -> Windows Indexing Service -> Disable > > On Sep 13, 2006, at 3:09 PM, eks dev wrote: > >> not promoting, "let lucene fix all Winblows problems", just saying, >> if > >> someone has cool, simple trick in patch form, that hurts nobody, >> would > >> be nice to accept it. Enough people burned their fingers on this one >> >> - Original Message >> From: Chris Hostetter <[EMAIL PROTECTED]> >> To: java-dev@lucene.apache.org >> Sent: Wednesday, 13 September, 2006 10:04:05 PM >> Subject: RE: [jira] Commented: (LUCENE-665) temporary file access >> denied on Windows >> >> : While what you say is true about indexing should be disabled, that >> : really doesn't solve the actual issue. Administrators of >> applications >> : using lucene often do not have control over the actual machine and >> thus >> : cannot determine what is and is not installed. Besides that, many >> of > >> us >> >> no, but they can st the operating params of the software they support >> -- as far as i can tell based on what i've read about the issue, the >> problem stems from software that does what seems to be the equivilent >> of trying to open any file that has recently been closed by any other >> app ... as a java library Lucene shouldn't be expected to guard >> against that any more then it should be expected to guard against the >> possibility of people randmoly renaming or deleting files in the >> index > >> directory -- Lucene makes some files, and it expects to manage them >> without interference from anything else -- as long as that >> expectation > >> is documented (and i'll admit, those expectations could b
RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
> Actually this is what the current patch attempts for (FSDirs_Retry_Logic_3) > - did you get a chance to try it? No, I've just seen this jira issue because of your email - my last investigation of the issue was last year for which I personally did not uncover the cause nor a simple solution to the issue. Instead, we took the severe approach to just rebuild the index which itself causes issues (not technical, more customer satisfaction). Regards, Bruce Ritchie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
The proper solution is to have your software installer disable the indexing on the directory. If you don't any index updates are going to be abysmally slow anyway - and if you do a lot you will bring your clients systems to their knees (sounds like a bad situation for them). You should also document in the installation guide for your software the requirements, and how certain software packages (indexers and virus scanners) should be disable on the your software packages data directories. On Sep 13, 2006, at 3:37 PM, Bruce Ritchie wrote: I'm afraid it's just not that simple. Lucene is not a server application as you claimed in your first reply - it's a java based search library. Just because it's most often used on servers does not equate to it always being used on servers for which disabling the index service is a reasonable thing to do. We use it in a desktop application in addition to server applications, and being a java based application we want to neither have to tell our clients to disable indexing, or tortoisesvn, or any other software they may have, nor to have to insert something into the registry (if indeed such a thing exists). Now, I'm not expecting lucene to be able to recover if a virus scanner decides to mangle an index file or any other such extreme behavior, but I do expect it to behave correctly in the face of what I believe is a common enough issue on a very commonly used OS. While it would be ideal for Java itself to workaround the issue I don't think we can expect that to happen for a while. Our few choices now are to have a custom directory which has the simple workaround in it, patch lucene everytime we have a new release, or ignore the issue and have customers complain. While patching lucene is possible for me I personally think this a worthy enough issue to be included into lucene proper. Regards, Bruce Ritchie -Original Message- From: robert engels [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 4:13 PM To: java-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows Start -> Administrative Tools -> Windows Indexing Service -> Disable On Sep 13, 2006, at 3:09 PM, eks dev wrote: not promoting, "let lucene fix all Winblows problems", just saying, if someone has cool, simple trick in patch form, that hurts nobody, would be nice to accept it. Enough people burned their fingers on this one - Original Message From: Chris Hostetter <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Wednesday, 13 September, 2006 10:04:05 PM Subject: RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows : While what you say is true about indexing should be disabled, that : really doesn't solve the actual issue. Administrators of applications : using lucene often do not have control over the actual machine and thus : cannot determine what is and is not installed. Besides that, many of us no, but they can st the operating params of the software they support -- as far as i can tell based on what i've read about the issue, the problem stems from software that does what seems to be the equivilent of trying to open any file that has recently been closed by any other app ... as a java library Lucene shouldn't be expected to guard against that any more then it should be expected to guard against the possibility of people randmoly renaming or deleting files in the index directory -- Lucene makes some files, and it expects to manage them without interference from anything else -- as long as that expectation is documented (and i'll admit, those expectations could be documented more thoroughly) then i think our work here is done. Dealing withthis problem becomes the topic of a FAQ about the cause with a pointer to a Wiki explaining the details and (*hopefully*) a list of crazy registry hacks you can use to disable it on a per directory basis. (DISCLAIMER: I am not saying such hacks exist, merely that i hope some method of disabling this "feature" exists and if it does pointeres on how to do so would be useful) -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Why do we have people writing patches for symptoms? if the developer is not keen enough to actually figure out EXACTLY what is causing the problem, it is doubtful this same developer should be submitting code to "fix" it. Figure out exactly what is causing YOUR problem and then divulge that - then the community at large can diagnose a proper fix. Simple wait and retry systems are always fragile (how long to wait? how many retries before failing?) and usually VERY site specific (hardware speed, etc.) On Sep 13, 2006, at 3:29 PM, Doron Cohen wrote: eks dev <[EMAIL PROTECTED]> wrote on 13/09/2006 13:09:42: would be nice to accept it. Enough people burned their fingers on this one <[EMAIL PROTECTED]> wrote on 13/09/2006 12:52:00: I've hit this exact issue during development - it's truly an annoying issue that a simple sleep/retry loop should resolve. Actually this is what the current patch attempts for (FSDirs_Retry_Logic_3) - did you get a chance to try it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
I'm afraid it's just not that simple. Lucene is not a server application as you claimed in your first reply - it's a java based search library. Just because it's most often used on servers does not equate to it always being used on servers for which disabling the index service is a reasonable thing to do. We use it in a desktop application in addition to server applications, and being a java based application we want to neither have to tell our clients to disable indexing, or tortoisesvn, or any other software they may have, nor to have to insert something into the registry (if indeed such a thing exists). Now, I'm not expecting lucene to be able to recover if a virus scanner decides to mangle an index file or any other such extreme behavior, but I do expect it to behave correctly in the face of what I believe is a common enough issue on a very commonly used OS. While it would be ideal for Java itself to workaround the issue I don't think we can expect that to happen for a while. Our few choices now are to have a custom directory which has the simple workaround in it, patch lucene everytime we have a new release, or ignore the issue and have customers complain. While patching lucene is possible for me I personally think this a worthy enough issue to be included into lucene proper. Regards, Bruce Ritchie -Original Message- From: robert engels [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 4:13 PM To: java-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows Start -> Administrative Tools -> Windows Indexing Service -> Disable On Sep 13, 2006, at 3:09 PM, eks dev wrote: > not promoting, "let lucene fix all Winblows problems", just saying, if > someone has cool, simple trick in patch form, that hurts nobody, would > be nice to accept it. Enough people burned their fingers on this one > > - Original Message > From: Chris Hostetter <[EMAIL PROTECTED]> > To: java-dev@lucene.apache.org > Sent: Wednesday, 13 September, 2006 10:04:05 PM > Subject: RE: [jira] Commented: (LUCENE-665) temporary file access > denied on Windows > > : While what you say is true about indexing should be disabled, that > : really doesn't solve the actual issue. Administrators of > applications > : using lucene often do not have control over the actual machine and > thus > : cannot determine what is and is not installed. Besides that, many of > us > > no, but they can st the operating params of the software they support > -- as far as i can tell based on what i've read about the issue, the > problem stems from software that does what seems to be the equivilent > of trying to open any file that has recently been closed by any other > app ... as a java library Lucene shouldn't be expected to guard > against that any more then it should be expected to guard against the > possibility of people randmoly renaming or deleting files in the index > directory -- Lucene makes some files, and it expects to manage them > without interference from anything else -- as long as that expectation > is documented (and i'll admit, those expectations could be documented > more thoroughly) then i think our work here is done. > > Dealing withthis problem becomes the topic of a FAQ about the cause > with a pointer to a Wiki explaining the details and (*hopefully*) a > list of crazy registry hacks you can use to disable it on a per > directory basis. > > (DISCLAIMER: I am not saying such hacks exist, merely that i hope some > method of disabling this "feature" exists and if it does pointeres on > how to do so would be useful) > > > > -Hoss > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Start -> Virus Scanner -> Disable On Sep 13, 2006, at 3:22 PM, Doron Cohen wrote: Start -> Administrative Tools -> Windows Indexing Service -> Disable Yes, tried that of course, just to discover that it was not the cause in my case... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
> eks dev <[EMAIL PROTECTED]> wrote on 13/09/2006 13:09:42: > would be nice to accept it. Enough people burned > their fingers on this one > > <[EMAIL PROTECTED]> wrote on 13/09/2006 12:52:00: > > I've hit this exact issue during development - it's truly > > an annoying issue that a simple sleep/retry > > loop should resolve. Actually this is what the current patch attempts for (FSDirs_Retry_Logic_3) - did you get a chance to try it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
> Start -> Administrative Tools -> Windows Indexing Service -> Disable Yes, tried that of course, just to discover that it was not the cause in my case... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Start -> Administrative Tools -> Windows Indexing Service -> Disable On Sep 13, 2006, at 3:09 PM, eks dev wrote: not promoting, "let lucene fix all Winblows problems", just saying, if someone has cool, simple trick in patch form, that hurts nobody, would be nice to accept it. Enough people burned their fingers on this one - Original Message From: Chris Hostetter <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Wednesday, 13 September, 2006 10:04:05 PM Subject: RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows : While what you say is true about indexing should be disabled, that : really doesn't solve the actual issue. Administrators of applications : using lucene often do not have control over the actual machine and thus : cannot determine what is and is not installed. Besides that, many of us no, but they can st the operating params of the software they support -- as far as i can tell based on what i've read about the issue, the problem stems from software that does what seems to be the equivilent of trying to open any file that has recently been closed by any other app ... as a java library Lucene shouldn't be expected to guard against that any more then it should be expected to guard against the possibility of people randmoly renaming or deleting files in the index directory -- Lucene makes some files, and it expects to manage them without interference from anything else -- as long as that expectation is documented (and i'll admit, those expectations could be documented more thoroughly) then i think our work here is done. Dealing withthis problem becomes the topic of a FAQ about the cause with a pointer to a Wiki explaining the details and (*hopefully*) a list of crazy registry hacks you can use to disable it on a per directory basis. (DISCLAIMER: I am not saying such hacks exist, merely that i hope some method of disabling this "feature" exists and if it does pointeres on how to do so would be useful) -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
not promoting, "let lucene fix all Winblows problems", just saying, if someone has cool, simple trick in patch form, that hurts nobody, would be nice to accept it. Enough people burned their fingers on this one - Original Message From: Chris Hostetter <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Wednesday, 13 September, 2006 10:04:05 PM Subject: RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows : While what you say is true about indexing should be disabled, that : really doesn't solve the actual issue. Administrators of applications : using lucene often do not have control over the actual machine and thus : cannot determine what is and is not installed. Besides that, many of us no, but they can st the operating params of the software they support -- as far as i can tell based on what i've read about the issue, the problem stems from software that does what seems to be the equivilent of trying to open any file that has recently been closed by any other app ... as a java library Lucene shouldn't be expected to guard against that any more then it should be expected to guard against the possibility of people randmoly renaming or deleting files in the index directory -- Lucene makes some files, and it expects to manage them without interference from anything else -- as long as that expectation is documented (and i'll admit, those expectations could be documented more thoroughly) then i think our work here is done. Dealing withthis problem becomes the topic of a FAQ about the cause with a pointer to a Wiki explaining the details and (*hopefully*) a list of crazy registry hacks you can use to disable it on a per directory basis. (DISCLAIMER: I am not saying such hacks exist, merely that i hope some method of disabling this "feature" exists and if it does pointeres on how to do so would be useful) -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
: While what you say is true about indexing should be disabled, that : really doesn't solve the actual issue. Administrators of applications : using lucene often do not have control over the actual machine and thus : cannot determine what is and is not installed. Besides that, many of us no, but they can st the operating params of the software they support -- as far as i can tell based on what i've read about the issue, the problem stems from software that does what seems to be the equivilent of trying to open any file that has recently been closed by any other app ... as a java library Lucene shouldn't be expected to guard against that any more then it should be expected to guard against the possibility of people randmoly renaming or deleting files in the index directory -- Lucene makes some files, and it expects to manage them without interference from anything else -- as long as that expectation is documented (and i'll admit, those expectations could be documented more thoroughly) then i think our work here is done. Dealing withthis problem becomes the topic of a FAQ about the cause with a pointer to a Wiki explaining the details and (*hopefully*) a list of crazy registry hacks you can use to disable it on a per directory basis. (DISCLAIMER: I am not saying such hacks exist, merely that i hope some method of disabling this "feature" exists and if it does pointeres on how to do so would be useful) -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Also, folks write desktop apps with lucene... and users of desktop search are not sys admins ... - Original Message From: robert engels <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Wednesday, 13 September, 2006 9:58:06 PM Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows Also, what was stated is that "this is not a safe assumption" is ludicrous. It happens to not be safe because X software package that was installed is holding locks on files If could be that Y software package (virus scanner !) deletes files automatically when it doesn't recognize an extension - or possibly one of the lucene index files ends up matching some virus signature. You always must be aware of the environment in which you install anyway software. Having indexing software or virus scanning software run on the directories that contains Lucene files is just a bad (incorrect) deployment - will perform badly as best, and not at all at worst. On Sep 13, 2006, at 2:52 PM, Bruce Ritchie wrote: > While what you say is true about indexing should be disabled, that > really doesn't solve the actual issue. Administrators of applications > using lucene often do not have control over the actual machine and > thus > cannot determine what is and is not installed. Besides that, many > of us > do development on Windows machines and don't want the hassle of being > forced to run the application either remotely on a unix box or in a VM > just to work around this issue. I've hit this exact issue during > development - it's truly an annoying issue that a simple sleep/retry > loop should resolve. > > > Regards, > > Bruce Ritchie > > > -Original Message- > From: robert engels [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 13, 2006 3:41 PM > To: java-dev@lucene.apache.org > Subject: Re: [jira] Commented: (LUCENE-665) temporary file access > denied > on Windows > > This is a server application. Windows indexing service should be > disable > on the directories that contain Lucene locks and files. > > This is the same procedure that would be required for any database. > > On Sep 13, 2006, at 2:27 PM, Michael McCandless (JIRA) wrote: > >> [ http://issues.apache.org/jira/browse/LUCENE-665? >> page=comments#action_12434527 ] >> >> Michael McCandless commented on LUCENE-665: >> --- >> >> I do think we should make Lucene robust to "windows change log" >> software. >> >> We could take the position that you have to uninstall such software >> because they "conflict" with Lucene, but I don't think that's >> realistic. Apparently many packages use this convenient API and that >> will only get worse with time. >> >> I would put this under the "Lucene should assume the least common >> denominator of filesystem's capabilities" umbrella. Meaning, Lucene >> now assumes it can rename files right after closing them, but on >> Windows this isn't a safe assumption so if possible we should change >> the index format to not require this. >> >> I will try to reproduce this bug with my [upcoming] changes for >> lockless commits (numbered segments files) -- the lockless commits >> changes do much less file renaming, so the issue should be rarer (but >> could still occur). >> >> >>> temporary file access denied on Windows >>> --- >>> >>> Key: LUCENE-665 >>> URL: http://issues.apache.org/jira/browse/LUCENE-665 >>> Project: Lucene - Java >>> Issue Type: Bug >>> Components: Store >>>Affects Versions: 2.0.0 >>> Environment: Windows >>>Reporter: Doron Cohen >>> Attachments: FSDirectory_Retry_Logic.patch, >>> FSDirs_Retry_Logic_3.patch, Test_Output.txt, >>> TestInterleavedAddAndRemoves.java >>> >>> >>> When interleaving adds and removes there is frequent opening/ >>> closing > >>> of readers and writers. >>> I tried to measure performance in such a scenario (for issue 565), >>> but the performance test failed - the indexing process crashed >>> consistently with file "access denied" errors - "cannot create a >>> lock > >>> file" in "lockFile.createNewFile()" and "cannot rename file". >>> This is related to: >>> - issue 516 (a closed issue: "TestFSDirectory fails on Windo
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
we hit it a few times, and we use dedicated servers, but unfortunatelly someone else is hosting our app, well, if it does not hurt someone else, would be nice to patch it somehow (like ant did it for example) - Original Message From: robert engels <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Wednesday, 13 September, 2006 9:52:29 PM Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows I do extensive Lucene on Windows machines - never had this problem. On Sep 13, 2006, at 2:52 PM, Bruce Ritchie wrote: > While what you say is true about indexing should be disabled, that > really doesn't solve the actual issue. Administrators of applications > using lucene often do not have control over the actual machine and > thus > cannot determine what is and is not installed. Besides that, many > of us > do development on Windows machines and don't want the hassle of being > forced to run the application either remotely on a unix box or in a VM > just to work around this issue. I've hit this exact issue during > development - it's truly an annoying issue that a simple sleep/retry > loop should resolve. > > > Regards, > > Bruce Ritchie > > > -Original Message- > From: robert engels [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 13, 2006 3:41 PM > To: java-dev@lucene.apache.org > Subject: Re: [jira] Commented: (LUCENE-665) temporary file access > denied > on Windows > > This is a server application. Windows indexing service should be > disable > on the directories that contain Lucene locks and files. > > This is the same procedure that would be required for any database. > > On Sep 13, 2006, at 2:27 PM, Michael McCandless (JIRA) wrote: > >> [ http://issues.apache.org/jira/browse/LUCENE-665? >> page=comments#action_12434527 ] >> >> Michael McCandless commented on LUCENE-665: >> --- >> >> I do think we should make Lucene robust to "windows change log" >> software. >> >> We could take the position that you have to uninstall such software >> because they "conflict" with Lucene, but I don't think that's >> realistic. Apparently many packages use this convenient API and that >> will only get worse with time. >> >> I would put this under the "Lucene should assume the least common >> denominator of filesystem's capabilities" umbrella. Meaning, Lucene >> now assumes it can rename files right after closing them, but on >> Windows this isn't a safe assumption so if possible we should change >> the index format to not require this. >> >> I will try to reproduce this bug with my [upcoming] changes for >> lockless commits (numbered segments files) -- the lockless commits >> changes do much less file renaming, so the issue should be rarer (but >> could still occur). >> >> >>> temporary file access denied on Windows >>> --- >>> >>> Key: LUCENE-665 >>> URL: http://issues.apache.org/jira/browse/LUCENE-665 >>> Project: Lucene - Java >>> Issue Type: Bug >>> Components: Store >>>Affects Versions: 2.0.0 >>> Environment: Windows >>>Reporter: Doron Cohen >>> Attachments: FSDirectory_Retry_Logic.patch, >>> FSDirs_Retry_Logic_3.patch, Test_Output.txt, >>> TestInterleavedAddAndRemoves.java >>> >>> >>> When interleaving adds and removes there is frequent opening/ >>> closing > >>> of readers and writers. >>> I tried to measure performance in such a scenario (for issue 565), >>> but the performance test failed - the indexing process crashed >>> consistently with file "access denied" errors - "cannot create a >>> lock > >>> file" in "lockFile.createNewFile()" and "cannot rename file". >>> This is related to: >>> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") - >>> http://issues.apache.org/jira/browse/LUCENE-516 >>> - user list questions due to file errors: >>> - http://www.nabble.com/OutOfMemory-and-IOException-Access- >>> Denied-errors-tf1649795.html >>> - http://www.nabble.com/running-a-lucene-indexing-app-as-a- >>> windows-service-on-xp%2C-crashing-tf2053536.html >>> - discussion on lock-less commits http://www.nabble.com/Lock-less- >>> commits-tf2126935.html My test setup is: XP (SP
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Also, what was stated is that "this is not a safe assumption" is ludicrous. It happens to not be safe because X software package that was installed is holding locks on files If could be that Y software package (virus scanner !) deletes files automatically when it doesn't recognize an extension - or possibly one of the lucene index files ends up matching some virus signature. You always must be aware of the environment in which you install anyway software. Having indexing software or virus scanning software run on the directories that contains Lucene files is just a bad (incorrect) deployment - will perform badly as best, and not at all at worst. On Sep 13, 2006, at 2:52 PM, Bruce Ritchie wrote: While what you say is true about indexing should be disabled, that really doesn't solve the actual issue. Administrators of applications using lucene often do not have control over the actual machine and thus cannot determine what is and is not installed. Besides that, many of us do development on Windows machines and don't want the hassle of being forced to run the application either remotely on a unix box or in a VM just to work around this issue. I've hit this exact issue during development - it's truly an annoying issue that a simple sleep/retry loop should resolve. Regards, Bruce Ritchie -Original Message- From: robert engels [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 3:41 PM To: java-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows This is a server application. Windows indexing service should be disable on the directories that contain Lucene locks and files. This is the same procedure that would be required for any database. On Sep 13, 2006, at 2:27 PM, Michael McCandless (JIRA) wrote: [ http://issues.apache.org/jira/browse/LUCENE-665? page=comments#action_12434527 ] Michael McCandless commented on LUCENE-665: --- I do think we should make Lucene robust to "windows change log" software. We could take the position that you have to uninstall such software because they "conflict" with Lucene, but I don't think that's realistic. Apparently many packages use this convenient API and that will only get worse with time. I would put this under the "Lucene should assume the least common denominator of filesystem's capabilities" umbrella. Meaning, Lucene now assumes it can rename files right after closing them, but on Windows this isn't a safe assumption so if possible we should change the index format to not require this. I will try to reproduce this bug with my [upcoming] changes for lockless commits (numbered segments files) -- the lockless commits changes do much less file renaming, so the issue should be rarer (but could still occur). temporary file access denied on Windows --- Key: LUCENE-665 URL: http://issues.apache.org/jira/browse/LUCENE-665 Project: Lucene - Java Issue Type: Bug Components: Store Affects Versions: 2.0.0 Environment: Windows Reporter: Doron Cohen Attachments: FSDirectory_Retry_Logic.patch, FSDirs_Retry_Logic_3.patch, Test_Output.txt, TestInterleavedAddAndRemoves.java When interleaving adds and removes there is frequent opening/ closing of readers and writers. I tried to measure performance in such a scenario (for issue 565), but the performance test failed - the indexing process crashed consistently with file "access denied" errors - "cannot create a lock file" in "lockFile.createNewFile()" and "cannot rename file". This is related to: - issue 516 (a closed issue: "TestFSDirectory fails on Windows") - http://issues.apache.org/jira/browse/LUCENE-516 - user list questions due to file errors: - http://www.nabble.com/OutOfMemory-and-IOException-Access- Denied-errors-tf1649795.html - http://www.nabble.com/running-a-lucene-indexing-app-as-a- windows-service-on-xp%2C-crashing-tf2053536.html - discussion on lock-less commits http://www.nabble.com/Lock-less- commits-tf2126935.html My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs. I noticed that the problem is more frequent when locks are created on one disk and the index on another. Both are NTFS with Windows indexing service enabled. I suspect this indexing service might be related - keeping files busy for a while, but don't know for sure. After experimenting with it I conclude that these problems - at least in my scenario - are due to a temporary situation - the FS, or the OS, is *temporarily* holding references to files or folders, preventing from renaming them, deleting them, or creating new files in certain directories. So I added to FSDirectory a retry logic in
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
I do extensive Lucene on Windows machines - never had this problem. On Sep 13, 2006, at 2:52 PM, Bruce Ritchie wrote: While what you say is true about indexing should be disabled, that really doesn't solve the actual issue. Administrators of applications using lucene often do not have control over the actual machine and thus cannot determine what is and is not installed. Besides that, many of us do development on Windows machines and don't want the hassle of being forced to run the application either remotely on a unix box or in a VM just to work around this issue. I've hit this exact issue during development - it's truly an annoying issue that a simple sleep/retry loop should resolve. Regards, Bruce Ritchie -Original Message- From: robert engels [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 3:41 PM To: java-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows This is a server application. Windows indexing service should be disable on the directories that contain Lucene locks and files. This is the same procedure that would be required for any database. On Sep 13, 2006, at 2:27 PM, Michael McCandless (JIRA) wrote: [ http://issues.apache.org/jira/browse/LUCENE-665? page=comments#action_12434527 ] Michael McCandless commented on LUCENE-665: --- I do think we should make Lucene robust to "windows change log" software. We could take the position that you have to uninstall such software because they "conflict" with Lucene, but I don't think that's realistic. Apparently many packages use this convenient API and that will only get worse with time. I would put this under the "Lucene should assume the least common denominator of filesystem's capabilities" umbrella. Meaning, Lucene now assumes it can rename files right after closing them, but on Windows this isn't a safe assumption so if possible we should change the index format to not require this. I will try to reproduce this bug with my [upcoming] changes for lockless commits (numbered segments files) -- the lockless commits changes do much less file renaming, so the issue should be rarer (but could still occur). temporary file access denied on Windows --- Key: LUCENE-665 URL: http://issues.apache.org/jira/browse/LUCENE-665 Project: Lucene - Java Issue Type: Bug Components: Store Affects Versions: 2.0.0 Environment: Windows Reporter: Doron Cohen Attachments: FSDirectory_Retry_Logic.patch, FSDirs_Retry_Logic_3.patch, Test_Output.txt, TestInterleavedAddAndRemoves.java When interleaving adds and removes there is frequent opening/ closing of readers and writers. I tried to measure performance in such a scenario (for issue 565), but the performance test failed - the indexing process crashed consistently with file "access denied" errors - "cannot create a lock file" in "lockFile.createNewFile()" and "cannot rename file". This is related to: - issue 516 (a closed issue: "TestFSDirectory fails on Windows") - http://issues.apache.org/jira/browse/LUCENE-516 - user list questions due to file errors: - http://www.nabble.com/OutOfMemory-and-IOException-Access- Denied-errors-tf1649795.html - http://www.nabble.com/running-a-lucene-indexing-app-as-a- windows-service-on-xp%2C-crashing-tf2053536.html - discussion on lock-less commits http://www.nabble.com/Lock-less- commits-tf2126935.html My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs. I noticed that the problem is more frequent when locks are created on one disk and the index on another. Both are NTFS with Windows indexing service enabled. I suspect this indexing service might be related - keeping files busy for a while, but don't know for sure. After experimenting with it I conclude that these problems - at least in my scenario - are due to a temporary situation - the FS, or the OS, is *temporarily* holding references to files or folders, preventing from renaming them, deleting them, or creating new files in certain directories. So I added to FSDirectory a retry logic in cases the error was related to "Access Denied". This is the same approach brought in http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows- service-on-xp%2C-crashing-tf2053536.html - there, in addition to the retry, gc() is invoked (I did not gc()). This is based on the *hope* that a access-denied situation would vanish after a small delay, and the retry would succeed. I modified FSDirectory this way for "Access Denied" errors during creating a new files, renaming a file. This worked fine for me. The performance test that failed before, now managed to complete. There should be no p
RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
While what you say is true about indexing should be disabled, that really doesn't solve the actual issue. Administrators of applications using lucene often do not have control over the actual machine and thus cannot determine what is and is not installed. Besides that, many of us do development on Windows machines and don't want the hassle of being forced to run the application either remotely on a unix box or in a VM just to work around this issue. I've hit this exact issue during development - it's truly an annoying issue that a simple sleep/retry loop should resolve. Regards, Bruce Ritchie -Original Message- From: robert engels [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 3:41 PM To: java-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows This is a server application. Windows indexing service should be disable on the directories that contain Lucene locks and files. This is the same procedure that would be required for any database. On Sep 13, 2006, at 2:27 PM, Michael McCandless (JIRA) wrote: > [ http://issues.apache.org/jira/browse/LUCENE-665? > page=comments#action_12434527 ] > > Michael McCandless commented on LUCENE-665: > --- > > I do think we should make Lucene robust to "windows change log" > software. > > We could take the position that you have to uninstall such software > because they "conflict" with Lucene, but I don't think that's > realistic. Apparently many packages use this convenient API and that > will only get worse with time. > > I would put this under the "Lucene should assume the least common > denominator of filesystem's capabilities" umbrella. Meaning, Lucene > now assumes it can rename files right after closing them, but on > Windows this isn't a safe assumption so if possible we should change > the index format to not require this. > > I will try to reproduce this bug with my [upcoming] changes for > lockless commits (numbered segments files) -- the lockless commits > changes do much less file renaming, so the issue should be rarer (but > could still occur). > > >> temporary file access denied on Windows >> --- >> >> Key: LUCENE-665 >> URL: http://issues.apache.org/jira/browse/LUCENE-665 >> Project: Lucene - Java >> Issue Type: Bug >> Components: Store >>Affects Versions: 2.0.0 >> Environment: Windows >>Reporter: Doron Cohen >> Attachments: FSDirectory_Retry_Logic.patch, >> FSDirs_Retry_Logic_3.patch, Test_Output.txt, >> TestInterleavedAddAndRemoves.java >> >> >> When interleaving adds and removes there is frequent opening/ closing >> of readers and writers. >> I tried to measure performance in such a scenario (for issue 565), >> but the performance test failed - the indexing process crashed >> consistently with file "access denied" errors - "cannot create a lock >> file" in "lockFile.createNewFile()" and "cannot rename file". >> This is related to: >> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") - >> http://issues.apache.org/jira/browse/LUCENE-516 >> - user list questions due to file errors: >> - http://www.nabble.com/OutOfMemory-and-IOException-Access- >> Denied-errors-tf1649795.html >> - http://www.nabble.com/running-a-lucene-indexing-app-as-a- >> windows-service-on-xp%2C-crashing-tf2053536.html >> - discussion on lock-less commits http://www.nabble.com/Lock-less- >> commits-tf2126935.html My test setup is: XP (SP1), JAVA 1.5 - both >> SUN and IBM SDKs. >> I noticed that the problem is more frequent when locks are created on >> one disk and the index on another. Both are NTFS with Windows >> indexing service enabled. I suspect this indexing service might be >> related - keeping files busy for a while, but don't know for sure. >> After experimenting with it I conclude that these problems - at least >> in my scenario - are due to a temporary situation - the FS, or the >> OS, is *temporarily* holding references to files or folders, >> preventing from renaming them, deleting them, or creating new files >> in certain directories. >> So I added to FSDirectory a retry logic in cases the error was >> related to "Access Denied". This is the same approach brought in >> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows- >> service-on-xp%2C-crashing-tf2053536.html - there, in a
Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
This is a server application. Windows indexing service should be
disable on the directories that contain Lucene locks and files.
This is the same procedure that would be required for any database.
On Sep 13, 2006, at 2:27 PM, Michael McCandless (JIRA) wrote:
[ http://issues.apache.org/jira/browse/LUCENE-665?
page=comments#action_12434527 ]
Michael McCandless commented on LUCENE-665:
---
I do think we should make Lucene robust to "windows change log"
software.
We could take the position that you have to uninstall such software
because they "conflict" with Lucene, but I don't think that's
realistic. Apparently many packages use this convenient API and that
will only get worse with time.
I would put this under the "Lucene should assume the least common
denominator of filesystem's capabilities" umbrella. Meaning, Lucene
now assumes it can rename files right after closing them, but on
Windows this isn't a safe assumption so if possible we should change
the index format to not require this.
I will try to reproduce this bug with my [upcoming] changes for
lockless commits (numbered segments files) -- the lockless commits
changes do much less file renaming, so the issue should be rarer (but
could still occur).
temporary file access denied on Windows
---
Key: LUCENE-665
URL: http://issues.apache.org/jira/browse/LUCENE-665
Project: Lucene - Java
Issue Type: Bug
Components: Store
Affects Versions: 2.0.0
Environment: Windows
Reporter: Doron Cohen
Attachments: FSDirectory_Retry_Logic.patch,
FSDirs_Retry_Logic_3.patch, Test_Output.txt,
TestInterleavedAddAndRemoves.java
When interleaving adds and removes there is frequent opening/
closing of readers and writers.
I tried to measure performance in such a scenario (for issue 565),
but the performance test failed - the indexing process crashed
consistently with file "access denied" errors - "cannot create a
lock file" in "lockFile.createNewFile()" and "cannot rename file".
This is related to:
- issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
http://issues.apache.org/jira/browse/LUCENE-516
- user list questions due to file errors:
- http://www.nabble.com/OutOfMemory-and-IOException-Access-
Denied-errors-tf1649795.html
- http://www.nabble.com/running-a-lucene-indexing-app-as-a-
windows-service-on-xp%2C-crashing-tf2053536.html
- discussion on lock-less commits http://www.nabble.com/Lock-less-
commits-tf2126935.html
My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
I noticed that the problem is more frequent when locks are created
on one disk and the index on another. Both are NTFS with Windows
indexing service enabled. I suspect this indexing service might be
related - keeping files busy for a while, but don't know for sure.
After experimenting with it I conclude that these problems - at
least in my scenario - are due to a temporary situation - the FS,
or the OS, is *temporarily* holding references to files or
folders, preventing from renaming them, deleting them, or creating
new files in certain directories.
So I added to FSDirectory a retry logic in cases the error was
related to "Access Denied". This is the same approach brought in
http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-
service-on-xp%2C-crashing-tf2053536.html - there, in addition to
the retry, gc() is invoked (I did not gc()). This is based on the
*hope* that a access-denied situation would vanish after a small
delay, and the retry would succeed.
I modified FSDirectory this way for "Access Denied" errors during
creating a new files, renaming a file.
This worked fine for me. The performance test that failed before,
now managed to complete. There should be no performance
implications due to this modification, because only the cases that
would otherwise wrongly fail are now delaying some extra millis
and retry.
I am attaching here a patch - FSDirectory_Retry_Logic.patch - that
has these changes to FSDirectory.
All "ant test" tests pass with this patch.
Also attaching a test case that demostrates the problem - at least
on my machine. There two tests cases in that test file - one that
works in system temp (like most Lucene tests) and one that creates
the index in a different disk. The latter case can only run if the
path ("D:" , "tmp") is valid.
It would be great if people that experienced these problems could
try out this patch and comment whether it made any difference for
them.
If it turns out useful for others as well, including this patch in
the code might help to relieve some of those "frustration" user
cases.
A comment on state of proposed patch:
- It is not a "ready to deploy" code - it has some debug printing,
showing the cases that the "retry logic" actually took place.
- I am not sure if curren
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12434527 ]
Michael McCandless commented on LUCENE-665:
---
I do think we should make Lucene robust to "windows change log"
software.
We could take the position that you have to uninstall such software
because they "conflict" with Lucene, but I don't think that's
realistic. Apparently many packages use this convenient API and that
will only get worse with time.
I would put this under the "Lucene should assume the least common
denominator of filesystem's capabilities" umbrella. Meaning, Lucene
now assumes it can rename files right after closing them, but on
Windows this isn't a safe assumption so if possible we should change
the index format to not require this.
I will try to reproduce this bug with my [upcoming] changes for
lockless commits (numbered segments files) -- the lockless commits
changes do much less file renaming, so the issue should be rarer (but
could still occur).
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, Test_Output.txt, TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12434509 ]
Michael McCandless commented on LUCENE-665:
---
I just sent this summary of this to java-user:
There is an issue opened on Lucene:
http://issues.apache.org/jira/browse/LUCENE-665
that I'd like to draw your attention to and summarize here because
recently users have hit it.
The gist of the issue is: on Windows, you sometimes see intermittant
"Access Denied" errors in renaming segments.new to segments or
deletable.new to deletable, etc. Lucene typically writes files first
to X.new and then renames then to X.
I know there was at least one recent thread where someone was hitting
this and there have been others in the past (including other Jira
issues).
Anyway, at the end of the issue it was discovered that there was an
unrelated piece of software (TortoiseSVN client) installed which was
using a filesystem "change log" capability in Windows that was
"causing" the problem: uninstalling it made the errors go away.
Unfortunately, there are apparently many software packages that use
this "change log" capability in Windows (virus checkers, Microsoft's
indexing service, etc.) and so the above issue remains open to figure
out whether / how to make Lucene robust to these cases.
But the bottom line is: if you hit these "Access Denied" errors, one
workaround is to try to turn off or uninstall the software that might
be doing this. I realize in many cases that's not an option (it's a
production box; you can't turn off virus checkers; etc.), but at least
it's something to try if you can, until there's some resolution on
that issue.
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, Test_Output.txt, TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "t
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12432004 ]
Michael McCandless commented on LUCENE-665:
---
Wow! Fantastic sleuthing. I never would have guessed that.
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch,
> FSDirs_Retry_Logic_3.patch, Test_Output.txt, TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patch and passes with the patch.
> 2. FSDirectory_Retry_Logic.patch
> 3. Test_Output.txt- output of the test with the patch, on my XP. Only the
> createNewFile() case had to be bypassed in this test, but for another program
> I also saw the renameFile() being bypassed.
> - Doron
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, se
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[ http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12431801 ] Doron Cohen commented on LUCENE-665: I think I know which software is causing/exposing this behavior in my environment. This is the SVN client I am using - TortoiseSVN. I tried the following sequence: 1) Run with TortoiseSVN installed - the test generates these "access denied:" errors (and bypasses them). 2) Uninstalled TortoiseSVN (+reboot), run test - pass with no "access denied" errorrs. 3) Installed TortoiseSVN again (+reboot), run test - same "access denied" errors again. I am using most recent stable TotoiseSVN version - 1.3.5 build 6804 - 32 bit, for svn-1.3.2, downloaded from http://tortoisesvn.tigris.org/. There is an interesting discussion thread of these type of errors on Windows platforms in svn forums - http://svn.haxx.se/dev/archive-2003-10/0136.shtml. At that case it was svn that suffers from these errors. It says "...Windows allows applications to "tag-along" to see when a file has been written - they will wait for it to close and then do whatever they do, usually opening a file descriptor or handle. This would prevent that file from being renamed for a brief period..." TortoiseSVN is a shell extension integrated into Windows explorer. As such, it probably demonstrates the "tag-along" behavior described above. (BTW, it is a great svn client to my opinion) Here is another excerpt from that discussion thread - >> >> sleep(1) would work, I suppose. ;~) >> > Most of the time, but not all the time. The only way I've made it work > well on all the machines I've tried it on is to put it into a sleep(1) > and retry loop of at *least* 20 or so attempts. Anything less and it > still fails on some machines. That implies it is very dependent on > machine speed or something, which means sleep times/retry times are just > guessing games at best. > > If I could just get it recreated outside of Subversion and prove it's a > Microsoft problem...although it probably still wouldn't get fixed for > months at least. We don't know that this is a bug in TortoiseSVN. We cannot tell that there are no other such tag-along applications in users machines. One cannot seriously expect this Win32 behavior to be fixed. I guess the question is - is it worth for Lucene to attempt to at least reduce chances of failures in this case (I say yes:-) > temporary file access denied on Windows > --- > > Key: LUCENE-665 > URL: http://issues.apache.org/jira/browse/LUCENE-665 > Project: Lucene - Java > Issue Type: Bug > Components: Store >Affects Versions: 2.0.0 > Environment: Windows >Reporter: Doron Cohen > Attachments: FSDirectory_Retry_Logic.patch, > FSDirs_Retry_Logic_3.patch, Test_Output.txt, TestInterleavedAddAndRemoves.java > > > When interleaving adds and removes there is frequent opening/closing of > readers and writers. > I tried to measure performance in such a scenario (for issue 565), but the > performance test failed - the indexing process crashed consistently with > file "access denied" errors - "cannot create a lock file" in > "lockFile.createNewFile()" and "cannot rename file". > This is related to: > - issue 516 (a closed issue: "TestFSDirectory fails on Windows") - > http://issues.apache.org/jira/browse/LUCENE-516 > - user list questions due to file errors: > - > http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html > - > http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html > - discussion on lock-less commits > http://www.nabble.com/Lock-less-commits-tf2126935.html > My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs. > I noticed that the problem is more frequent when locks are created on one > disk and the index on another. Both are NTFS with Windows indexing service > enabled. I suspect this indexing service might be related - keeping files > busy for a while, but don't know for sure. > After experimenting with it I conclude that these problems - at least in my > scenario - are due to a temporary situation - the FS, or the OS, is > *temporarily* holding references to files or folders, preventing from > renaming them, deleting them, or creating new files in certain directories. > So I added to FSDirectory a retry logic in cases the error was related to > "Access Denied". This is the same approach brought in > http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html > - there, in addition to the retry, gc() is invoked (I did not gc()). This is > based on the *hope* that a access-denied situation would vanish after a small > delay, and the retry would succeed. > I modified FSDirectory this way for "Access Denied" errors during creating a > n
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[ http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12431533 ] Michael McCandless commented on LUCENE-665: --- > But I am not sure how this should affect decision on applying this fix > - there would always be user machines out there running Lucene and > also running other services. > We could tell users - hey, make sure that none of the other services / > software running on your machine is holding / touching / examining > Lucene index files, otherwise, don't blame Lucene - but this is not > easily done. Not all developers out there have control or > understanding of what's running on their machines - some programs are > installed by a system support, you know how it is. > So, while it is understandable that Lucene would fail if there is a > malicious software that actually grabs and holds Lucene files and > interfere with them (for "long" periods of times), it would be nice to > keep these failures at minimum. Alas I still cannot reproduce this. I think there must be some environmental difference. I agree, Lucene should strive to be robust to the various "environmental differences" (OS, filesystem, permissions, virus checkers installed, etc.) up to a degree, however, I still think it's best to get to the root cause of these errors so users have the most information possible: the more information the better. Plus this may help us build a more accurate fix to the issue than sleeping / retrying. For example, if it turns out this happens only under Windows XP SP1, yes we can try to make Lucene robust to these errors, but in addition, we should document this so that those users that have the freedom to do so could upgrade to SP2. (NOTE: I'm just using this as an example: we still have no idea if it's SP1/SP2 difference that "fixes" the errors in my testing of this issue). Given that we have two environments, one very reliably showing these IO problems (yours) and one very reliably not (mine), this is really a great chance to get to the root cause. Here are the details of my env: OS: Windows XP Pro, SP2 Java: Sun JDK 1.5.0_07 Command line: java org.junit.runner.JUnitCore org.apache.lucene.index.TestInterleavedAddAndRemoves Services running: Google desktop, Symantec AV > temporary file access denied on Windows > --- > > Key: LUCENE-665 > URL: http://issues.apache.org/jira/browse/LUCENE-665 > Project: Lucene - Java > Issue Type: Bug > Components: Store >Affects Versions: 2.0.0 > Environment: Windows >Reporter: Doron Cohen > Attachments: FSDirectory_Retry_Logic.patch, > FSDirs_Retry_Logic_3.patch, Test_Output.txt, TestInterleavedAddAndRemoves.java > > > When interleaving adds and removes there is frequent opening/closing of > readers and writers. > I tried to measure performance in such a scenario (for issue 565), but the > performance test failed - the indexing process crashed consistently with > file "access denied" errors - "cannot create a lock file" in > "lockFile.createNewFile()" and "cannot rename file". > This is related to: > - issue 516 (a closed issue: "TestFSDirectory fails on Windows") - > http://issues.apache.org/jira/browse/LUCENE-516 > - user list questions due to file errors: > - > http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html > - > http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html > - discussion on lock-less commits > http://www.nabble.com/Lock-less-commits-tf2126935.html > My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs. > I noticed that the problem is more frequent when locks are created on one > disk and the index on another. Both are NTFS with Windows indexing service > enabled. I suspect this indexing service might be related - keeping files > busy for a while, but don't know for sure. > After experimenting with it I conclude that these problems - at least in my > scenario - are due to a temporary situation - the FS, or the OS, is > *temporarily* holding references to files or folders, preventing from > renaming them, deleting them, or creating new files in certain directories. > So I added to FSDirectory a retry logic in cases the error was related to > "Access Denied". This is the same approach brought in > http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html > - there, in addition to the retry, gc() is invoked (I did not gc()). This is > based on the *hope* that a access-denied situation would vanish after a small > delay, and the retry would succeed. > I modified FSDirectory this way for "Access Denied" errors during creating a > new files, renaming a file. > This worked fine for me. The performance test that failed before, now managed > to complete. There should be no
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12431100 ]
Doron Cohen commented on LUCENE-665:
> obtain() is supposed to return success or failure immediately.
> I'd be tempted to override obtain(timout) for FS locks and keep the retry
> logic there.
Right, this is the right place for the retry. This way changes are limited to
FSDirectory, and obtain() remains unchanged.
I am tesing this now and would subit an updated patch, where:
- UNEXPECTED_ERROR_RETRY_DELAY is set to 100ms.
- timeout in obtain(timeout) is always repected (even if the presence of those
unexpected io errors).
- IOExceptions "bubble up" as discussed.
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patch and passes with the patch.
> 2. FSDirectory_Retry_Logic.pat
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12430990 ]
Yonik Seeley commented on LUCENE-665:
-
A single retry in Lock.obtain() makes the error less likely, but certainly not
impossible... the second attempt could fail for the same reason.
obtain() is supposed to return success or failure immediately. I'd be tempted
to override obtain(timout) for FS locks and keep the retry logic there.
I agree we don't want to mask all IOExceptions and treat them as failure to
aquire locks... they should bubble up sooner or later to help diagnose real
IOExceptions.
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patch and passes with the patch.
> 2. FSDirectory_Retry_Logic.patch
> 3. Test_Output.txt- output of the test with the patch, on my XP.
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12430942 ]
Doron Cohen commented on LUCENE-665:
Stopping the anti-virus and its friends did not matter - still getting the
errors.
However saw a case that the 30ms did not suffice for obtaining the lock in the
retry.
Although 30ms was arbitrary in the first place, this is discouraging.
This was before fixing to let Lock.obtain() apply its retry logic in case of
such an exception.
So I fixed that (Lock.obtain()) and re-running, now using 100ms instead of 30ms
for the one retry in FSDirectory.
Ain't life fun.
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patch and passes with the patch.
> 2. FSDirectory_Retry_Logic.patch
> 3. Test_Output.txt- output of the test with the patch, on my XP. O
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[ http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12430919 ] Doron Cohen commented on LUCENE-665: > just to confirm, is it the COMMIT lock that's throwing these > unhandled exceptions (not the WRITE lock)? > If so, lockless commits would fix this. In my tests so far, these errors appeared only for commit locks. However I consider this a coincidence - there is nothing as far as I can understand special with commit locks comparing to write locks - in particular they both use createNewFile. So, I agree that lockless commits would prevent this, which is good, but we cannot count on that it would not happen for write locks as well. Also, the more I think about it the more I like lock-less commits, still, they would take a while to get into Lucene, while this simple fix can help easily now. Last, with lock-less commits, still, there would be calls to createNewFile for write lock, and there would be calls to renameFile() and other IO file operations, intensively. By having a safety code like the retry logic that is invoked only in rare cases of these unexpected, some nasty errors would be reduced, more users would be happy. > Can you provide more details on the exceptions you're seeing? > Especially on the "cannot rename file" exception? Here is one from my run log, that occurs at the call to optimize, after at the end of all the add-remove iterations - [junit] java.io.IOException: Cannot rename C:\Documents and Settings\tpowner\Local Settings\Temp\test.perf\index_24\deleteable.new to C:\Documents and Settings\tpowner\Local Settings\Temp\test.perf\index_24\deletable [junit] at org.apache.lucene.store.FSDirectory.doRenameFile(FSDirectory.java:328) [junit] at org.apache.lucene.store.FSDirectory.renameFile(FSDirectory.java:280) [junit] at org.apache.lucene.index.IndexWriter.writeDeleteableFiles(IndexWriter.java:967) [junit] at org.apache.lucene.index.IndexWriter.deleteSegments(IndexWriter.java:911) [junit] at org.apache.lucene.index.IndexWriter.commitChanges(IndexWriter.java:872) [junit] at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:823) [junit] at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:798) [junit] at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:614) [junit] at org.apache.lucene.index.IndexModifier.optimize(IndexModifier.java:304) [junit] at org.apache.lucene.index.TestBufferedDeletesPerf.doOptimize(TestBufferedDeletesPerf.java:266) [junit] at org.apache.lucene.index.TestBufferedDeletesPerf.measureInterleavedAddRemove(TestBufferedDeletesPerf.java:218) [junit] at org.apache.lucene.index.TestBufferedDeletesPerf.doTestBufferedDeletesPerf(TestBufferedDeletesPerf.java:144) [junit] at org.apache.lucene.index.TestBufferedDeletesPerf.testBufferedDeletesPerfCase7(TestBufferedDeletesPerf.java:134) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:585) [junit] at junit.framework.TestCase.runTest(TestCase.java:154) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567) [junit] Caused by: java.io.FileNotFoundException: C:\Documents and Settings\tpowner\Local Settings\Temp\test.perf\index_24\deletable (Access is denied) [junit] at java.io.FileOutputStream.open(Native Method) [junit] at java.io.FileOutputStream.(FileOutputStream.java:179) [junit] at java.io.FileOutputStream.(FileOutputStream.java:131) [junit] at org.apache.lucene.store.FSDirectory.doRenameFile(FSDirectory.java:312) [junit] ... 27 more This exception btw is from the performance test for interleaved-adds-and-removes - issue 565 - so IndexWriter line numbers here relate to applying recent patch from issue 565 (though the same errors are obtained with the
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12430740 ]
Michael McCandless commented on LUCENE-665:
---
I'm having trouble reproducing this issue. I copied the
TestInterleavedAddAndRemoves.java into src/test/org/apache/lucene/index, then
ran the test directly using "java org.junit.runner.JUnitCore
org.apache.lucene.index.TestInterleavedAddAndRemoves", using a clean checkout
of the current Lucene HEAD. The test is still running and is quite far along
and I haven't hit any of the above errors.
I'm running on Windows XP SP2, Sun JDK 1.5.0_07. I wonder if SP1 vs SP2 makes
the difference?
Could you also try [temporarily] turning off any virus / malware scanning
tools? I wonder if you have one that's doing "live" checking and hold files
open? (Though, I have a virus scanner running and it's not causing
problems...).
I would like to reproduce this so I could test it against my fixes for
lock-less commits!
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied"
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12430737 ]
Michael McCandless commented on LUCENE-665:
---
It may make more sense to trap "Access Denied" in the lock.obtain, but then
translate this into "the lock was not acquired" (ie, just return 0). Because,
above this code is the retry logic for the lock (which pauses by default for
1.0 sec).
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the LONG test that fails on XP without
> the patch and passes with the patch.
> 2. FSDirectory_Retry_Logic.patch
> 3. Test_Output.txt- output of the test with the patch, on my XP. Only the
> createNewFile() case had to be bypassed in this test, but for another program
> I also saw the renameFile() being bypassed.
> - Doron
--
This message is automatically generated by JIRA.
-
If you t
[jira] Commented: (LUCENE-665) temporary file access denied on Windows
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12430732 ]
Michael McCandless commented on LUCENE-665:
---
Doron, just to confirm, is it the COMMIT lock that's throwing these unhandled
exceptions (not the WRITE lock)? If so, lockless commits would fix this.
Also, once we switch to native locking (first "decoupling locking
implementation from directory implementation": LUCENE-635, and then I'm working
on a LockFactory that uses native locks within that) I think likely this would
be fixed as well (assuming that createNewFile is failing because two separate
processes are trying to do so at [nearly] the same time).
Can you provide more details on the exceptions you're seeing? Especially on
the "cannot rename file" exception?
> temporary file access denied on Windows
> ---
>
> Key: LUCENE-665
> URL: http://issues.apache.org/jira/browse/LUCENE-665
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.0.0
> Environment: Windows
>Reporter: Doron Cohen
> Attachments: FSDirectory_Retry_Logic.patch, Test_Output.txt,
> TestInterleavedAddAndRemoves.java
>
>
> When interleaving adds and removes there is frequent opening/closing of
> readers and writers.
> I tried to measure performance in such a scenario (for issue 565), but the
> performance test failed - the indexing process crashed consistently with
> file "access denied" errors - "cannot create a lock file" in
> "lockFile.createNewFile()" and "cannot rename file".
> This is related to:
> - issue 516 (a closed issue: "TestFSDirectory fails on Windows") -
> http://issues.apache.org/jira/browse/LUCENE-516
> - user list questions due to file errors:
> -
> http://www.nabble.com/OutOfMemory-and-IOException-Access-Denied-errors-tf1649795.html
> -
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - discussion on lock-less commits
> http://www.nabble.com/Lock-less-commits-tf2126935.html
> My test setup is: XP (SP1), JAVA 1.5 - both SUN and IBM SDKs.
> I noticed that the problem is more frequent when locks are created on one
> disk and the index on another. Both are NTFS with Windows indexing service
> enabled. I suspect this indexing service might be related - keeping files
> busy for a while, but don't know for sure.
> After experimenting with it I conclude that these problems - at least in my
> scenario - are due to a temporary situation - the FS, or the OS, is
> *temporarily* holding references to files or folders, preventing from
> renaming them, deleting them, or creating new files in certain directories.
> So I added to FSDirectory a retry logic in cases the error was related to
> "Access Denied". This is the same approach brought in
> http://www.nabble.com/running-a-lucene-indexing-app-as-a-windows-service-on-xp%2C-crashing-tf2053536.html
> - there, in addition to the retry, gc() is invoked (I did not gc()). This is
> based on the *hope* that a access-denied situation would vanish after a small
> delay, and the retry would succeed.
> I modified FSDirectory this way for "Access Denied" errors during creating a
> new files, renaming a file.
> This worked fine for me. The performance test that failed before, now managed
> to complete. There should be no performance implications due to this
> modification, because only the cases that would otherwise wrongly fail are
> now delaying some extra millis and retry.
> I am attaching here a patch - FSDirectory_Retry_Logic.patch - that has these
> changes to FSDirectory.
> All "ant test" tests pass with this patch.
> Also attaching a test case that demostrates the problem - at least on my
> machine. There two tests cases in that test file - one that works in system
> temp (like most Lucene tests) and one that creates the index in a different
> disk. The latter case can only run if the path ("D:" , "tmp") is valid.
> It would be great if people that experienced these problems could try out
> this patch and comment whether it made any difference for them.
> If it turns out useful for others as well, including this patch in the code
> might help to relieve some of those "frustration" user cases.
> A comment on state of proposed patch:
> - It is not a "ready to deploy" code - it has some debug printing, showing
> the cases that the "retry logic" actually took place.
> - I am not sure if current 30ms is the right delay... why not 50ms? 10ms?
> This is currently defined by a constant.
> - Should a call to gc() be added? (I think not.)
> - Should the retry be attempted also on "non access-denied" exceptions? (I
> think not).
> - I feel it is somewhat "woodoo programming", but though I don't like it, it
> seems to work...
> Attached files:
> 1. TestInterleavedAddAndRemoves.java - the
