Must java.io.tmpdir be on the same filesystem as the binary store in order to leverage NXP-9361 no-copy optimization

[rg1_]

The upgrade notes of NXP-9361 seem to indicate that java.io.tmpdir must be on the same filesystem as the binary store in order to leverage the NXP-9361 no-copy optimization. This does not seem correct. Rather, doesn't the binary store have its own temporary directory on the binary store filesystem for temporary storage during creation? If this is the case, how is java.io.tmpdir referenced in the upgrade notes relevant?

[Florent_Guillau · Accepted solution]

Yes, the binary store has its own temporary directory on the binary store filesystem for temporary storage during creation, but that's not the only relevant case for no-copy optimizations. For the pure use-case of NXP-9361 where you provide an InputStream then yes java.io.tmpdir is not relevant.

The issue with no-copy optimizations is that the initial file containing the binary that is being sent to Nuxeo VCS for storage (through the creation of a Blob for instance) may be created by a third-party library as a file and not a stream, for instance the RichFaces file upload component. For no-copy we want whatever temporary file RichFaces provided us to be used directly, so we have to make sure it's already on the proper filesystem, and we do that by setting java.io.tmpdir.