Uploaded image for project: 'ModeShape'
  1. ModeShape
  2. MODE-2302

The FileSystemBinaryStore incorrectly handles the binary unused / used cycle

    Details

      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.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                hchiorean Horia Chiorean
                Reporter:
                hchiorean Horia Chiorean
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: