Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise 4.2.3

[Florian Müller]

Hi Igor,

The Alfresco code is here (search for "Expected"):
https://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/COMMUNITYTAGS/V4.2f/root/projects/repository/source/java/org/alfresco/opencmis/AlfrescoCmisServiceImpl.java
It's handing the OpenCMIS stream to the Alfresco TempFileProvider. At 
this point OpenCMIS has read the stream already and knows the stream 
length. The content length set on the client side doesn't matter because 
it is not transported by the Browser binding. On the server, 
contentStream.getLength() returns the real stream length. That is, the 
stream has reached the server.

TempFileProvider somehow (I don't know the details) stores that stream 
on disk, but afterwards the temp file length is zero. That raises the 
CmisStorageException.

The querstion is how the TempFileProvider works and why it doesn't store 
the documents on disk under load. But that's a question for Alfresco.


- Florian


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