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

rg1_ — Wed, 15 May 2013 20:31:04 GMT

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?

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

Florent_Guillau — Thu, 16 May 2013 13:23:57 GMT

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.

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

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

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