Apologies, it was Mark that raised the issue so I’ll redirect that question to
you Mark ;-)
On 31/03/2015 08:51, "Gavin Cornwell" <gavin.cornw...@alfresco.com> wrote:
>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 )
>>>
