chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <f...@apache.org>
Subject Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise 4.2.3
Date Mon, 30 Mar 2015 14:07:29 GMT
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


Mime
View raw message