[
https://issues.apache.org/jira/browse/OAK-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18017761#comment-18017761
]
Julian Reschke commented on OAK-9897:
-------------------------------------
With this change, I'm getting reproducible failures on Windows, likely because
of unclosed files:
{noformat}
[ERROR]
testExisting(org.apache.jackrabbit.oak.segment.remote.persistentcache.PersistentRedisCacheTest)
Time elapsed: 0.026 s <<< ERROR!
java.nio.file.AccessDeniedException:
target\redis-server-5.0.14.1-windows-amd64.exe
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
at java.base/sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:171)
at
java.base/sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:284)
at java.base/java.nio.file.Files.copy(Files.java:1305)
at
org.apache.jackrabbit.oak.segment.remote.persistentcache.PersistentRedisCacheTest.setUp(PersistentRedisCacheTest.java:57)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
{noformat}
> SplitPersistence: FileReaper cannot finish cleanup
> --------------------------------------------------
>
> Key: OAK-9897
> URL: https://issues.apache.org/jira/browse/OAK-9897
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
> Affects Versions: 1.44.0
> Reporter: Julian Sedding
> Assignee: Julian Sedding
> Priority: Minor
> Fix For: 1.86.0
>
>
> When running revision compaction (aka GC) on a setup with split persistence,
> it is possible that the "cleanup" phase identifies files from the read-only
> part of the persistence as redundant and submits them to the {{FileReaper}}
> for deletion.
> However, the delete method of the {{SplitSegmentArchiveManager}} is
> implemented to return "false" when attempting the deletion of a file from the
> read-only persistence (which I would argue is correct). The {{FileReaper}}
> then re-adds the offending file to its queue in order to retry deleting it.
> Of course this fails again and so it can never finish and logs warnings for
> the files it cannot delete.
> It should be possible to prevent deletion of read-only files in the first
> place. In fact, I think there is no need to mark and sweep them at all.
> cc [~adulceanu]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
