Florian I'm not 100% sure if it does really use a temp file unless the file
is bigger than a size. Anyway checking that Alfresco's temporary file
partition is not full is a good starting point.
Many times is worth checking how you create the content stream.
Are you passing the file size when creating the content stream ?
I had a customer that had some trouble due to the fact that they were using
"-1" and letting the API guess the size. It did work under normal
circunstances but it failed in high concurrency scenarios.
Bye
2015-03-30 16:07 GMT+02:00 Florian Müller <f...@apache.org>:
> Hi Mark,
>
> I vaguely remember that this was a problem on the Alfresco side. There is
> nothing you can do on the client side.
> Alfresco 4 stores document content in a temp file (-> TempFileProvider).
> If that fails, you get such an error message.
> But you have to talk to Alfresco. It's not OpenCMIS client or server code.
>
>
> - Florian
>
>
>
>
> *Chemistry experts *
>>
>>
>>
>> *We have a large CMIS implementation using Alfresco Enterprise 4.2.3 and
>> Chemistry v0.10.0-RELEASE *
>>
>>
>>
>> *Everything has worked extremely well to date but we have now modified our
>> UI page logic such that it is able to start uploading multiple documents
>> in
>> parallel - we now have custom built REST services layer that receives the
>> requests from the UI and then using the Chemistry client API makes the
>> calls.*
>>
>>
>> *We are running into the following issue... (occurs with both browser and
>> atom binding and we are using CMIS 1.1 URLs) *
>>
>>
>>
>> 2015-03-24 16:50:52,987 ERROR - [ID: ] -
>> com.acmecompany.cmis.services.CmisServices.addDocument(): Expected 65201
>> bytes but retrieved 0 bytes!
>>
>>
>>
>> *org.apache.chemistry.opencmis.commons.exceptions.CmisStorageException:
>> Expected 65201 bytes but retrieved 0 bytes!*
>>
>>
>>
>> at
>> org.apache.chemistry.opencmis.client.bindings.spi.browser.
>> AbstractBrowserBindingService.convertStatusCode(
>> AbstractBrowserBindingService.java:240)
>>
>> at
>> org.apache.chemistry.opencmis.client.bindings.spi.browser.
>> AbstractBrowserBindingService.post(AbstractBrowserBindingService.
>> java:352)
>>
>> at
>> org.apache.chemistry.opencmis.client.bindings.spi.browser.
>> ObjectServiceImpl.createDocument(ObjectServiceImpl.java:83)
>>
>> at
>> org.apache.chemistry.opencmis.client.runtime.SessionImpl.
>> createDocument(SessionImpl.java:751)
>>
>> at
>> org.apache.chemistry.opencmis.client.runtime.FolderImpl.
>> createDocument(FolderImpl.java:95)
>>
>> at
>> org.apache.chemistry.opencmis.client.runtime.FolderImpl.
>> createDocument(FolderImpl.java:469)
>>
>>
>>
>> The line of code that triggers the error is this:
>>
>>
>>
>> org.apache.chemistry.opencmis.client.api.*Document*
>> document = folder.createDocument(docProps, contentStream,
>> versioningState);
>>
>>
>> This has always worked where we were running createDocument() calls
>> SERIALLY (we were throttling the pace such that only one call was made
>> at
>> a time)...
>>
>>
>> As soon as we changed things to perhaps having 3 to 5 events running in
>> PARALLEL, the CmisStorageException is thrown above with only a couple of
>> uploads making it through...
>>
>>
>>
>> In fact, we checked the contentStream and bytes on each of 5 parallel
>> calls
>> by Console logging the following:
>>
>>
>>
>> System.out.println("contentStream: " +
>> contentStream.getStream());
>>
>> System.out.println("contentStream: " + contentStream.getLength());
>>
>>
>> document = folder.createDocument(docProps, contentStream,
>> versioningState);
>> // docProps is the HashMap of properties only
>>
>>
>> And the output we see is:
>>
>>
>>
>> contentStream: java.io.ByteArrayInputStream@2a1a4763
>>
>> contentStream: 65201
>>
>> contentStream: java.io.ByteArrayInputStream@1fd226e2
>>
>> contentStream: 65201
>>
>> contentStream: java.io.ByteArrayInputStream@1df6cfc0
>>
>> contentStream: 65201
>>
>> contentStream: java.io.ByteArrayInputStream@79356271
>>
>> contentStream: 65201
>>
>> contentStream: java.io.ByteArrayInputStream@36c1559e
>>
>> contentStream: 65201
>>
>>
>>
>> *5 unique contentStream object IDs and the correct contentStream length
>> for
>> each is reported correctly on the client side... which is what was
>> expected. *
>>
>>
>>
>> As seen above the "storage exception" aligns with the byte size but it
>> complains the contentStream is "0" bytes?
>>
>>
>> We have debugged (which of course disrupts and slows things and then it
>> appears to work but that's effectively forcing a serial pattern), and in
>> all cases, the Map of properties, the contentStream, and versioningState
>> parameters are all correct for each on the *folder.createDocument()*
>> method
>> call.
>>
>>
>> Has anyone seen this?
>>
>>
>> We have already opened a ticket with Alfresco HOWEVER, we have also
>> checked
>> the Alfresco server side logs and because the failure is thrown by the
>> Client API code, there is also evidence that the stream reaching the
>> server
>> is zero thus resulting in the exception.
>>
>>
>> Perhaps we have to adjust how the Cmis Session is created or are we seeing
>> thread safety problem? So multiple uploads are happening on different
>> threads to Alfresco through one Session. Could this be part of the issue
>> we are seeing? Should we create a new Session for each request? It's our
>> understanding that it's expensive to create Session objects each time and
>> that we shouldn't have to do that.
>>
>>
>> Thought we'd ask here in case this has been seen before.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Mark
>>
>
>
--
Igor Blanco González
Binovo IT Human Project
e-mail: ibla...@binovo.es
Telf. : 943493611
Dirección:
Astigarraga Bidea 2
Planta 6. - Ofi. 3-2
20180 Oiartzun ( Gipuzkoa )
