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

The FileSystemBinaryStore incorrectly handles the binary unused / used cycle

XMLWordPrintable

      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.

              hchiorean Horia Chiorean (Inactive)
              hchiorean Horia Chiorean (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: