Details
-
Bug
-
Resolution: Done
-
Blocker
-
3.3.x-prod-ip6.0, 3.8.0.Final, 4.0.0.Beta1
-
None
-
None
Description
When removing binary properties in a repository configured to use a FileSystemBinaryStore, ModeShape will not remove the binary value immediately from the binary store, but will rather move this binary content into a trash area.
If at any time later the same binary value is reused and the value is still in the trash, this value is brought back from the trash into the main repository area.
The entire used/unused cycle is ATM asynchronous (unfortunately) via a BinaryUsageChangeSetListener. Because of this, the FileSystemBinaryStore and possibly other stores as well have severe flaws manifesting as:
1. Exceptions like:
org.modeshape.jcr.value.binary.BinaryStoreException: Unable to find binary value with key "92eb27d63a7c4432832e6406e01eaf130ceaa9ba" within binary store at "target\persistent_repository\binaries" at org.modeshape.jcr.value.binary.FileSystemBinaryStore.getStoredMimeType(FileSystemBinaryStore.java:478) at org.modeshape.jcr.value.binary.AbstractBinaryStore.getMimeType(AbstractBinaryStore.java:153) at org.modeshape.jcr.value.binary.StoredBinaryValue.getMimeType(StoredBinaryValue.java:63) at org.modeshape.jcr.JcrSession$JcrPreSave.process(JcrSession.java:2233) at org.modeshape.jcr.cache.document.WritableSessionCache.runPreSaveBeforeTransaction(WritableSessionCache.java:507) at org.modeshape.jcr.cache.document.WritableSessionCache.save(WritableSessionCache.java:565) at org.modeshape.jcr.JcrSession.save(JcrSession.java:1165) at org.modeshape.jcr.BinaryStorageIntegrationTest.shouldReuseBinariesFromTrashForFilesystemStore(BinaryStorageIntegrationTest.java:166) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:67)
2. Various assertion failures in the FileLocks class.
