*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
