Hi Igor,
Could you please let me know the ID of the support case you have opened with us
(Alfresco)?
Regards,
Gavin
On 30/03/2015 16:36, "Mark Streit" <mcs...@gmail.com> wrote:
>Igor
>
>Thanks for your reply as well. We DID confirm that we are creating the
>ContentStream correctly (passing the size) and the resulting length is
>checked and logged to the Console (temporarily) while we are trying to
>determine the problem. It appears to be correct.
>
>*We already have an open support case with Alfresco on this and have
>included all such information.*
>
>
>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: 5 unique object id values each with the correct
>length are reported.
>
>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
>
>That output is reported just before making that call shown above using the
>method:
>
>
>Folder.*createDocument*(Map docProps, ContentStream contentStream,
>VersioningState versioningState)
>
>
>Mark
>
>On Mon, Mar 30, 2015 at 11:20 AM, Igor Blanco <ibla...@binovo.es> wrote:
>
>> 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 )
>>
