You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Mark Streit <mc...@gmail.com> on 2015/03/27 23:57:21 UTC
CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise 4.2.3
*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
Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise
4.2.3
Posted by Gavin Cornwell <ga...@alfresco.com>.
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" <ga...@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" <mc...@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 <ib...@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 <fm...@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: iblanco@binovo.es
>>> Telf. : 943493611
>>> Dirección:
>>> Astigarraga Bidea 2
>>> Planta 6. - Ofi. 3-2
>>> 20180 Oiartzun ( Gipuzkoa )
>>>
Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise
4.2.3
Posted by Gavin Cornwell <ga...@alfresco.com>.
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" <mc...@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 <ib...@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 <fm...@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: iblanco@binovo.es
>> Telf. : 943493611
>> Dirección:
>> Astigarraga Bidea 2
>> Planta 6. - Ofi. 3-2
>> 20180 Oiartzun ( Gipuzkoa )
>>
Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise 4.2.3
Posted by Mark Streit <mc...@gmail.com>.
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 <ib...@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 <fm...@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: iblanco@binovo.es
> Telf. : 943493611
> Dirección:
> Astigarraga Bidea 2
> Planta 6. - Ofi. 3-2
> 20180 Oiartzun ( Gipuzkoa )
>
Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise
4.2.3
Posted by Florian Müller <fm...@apache.org>.
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 <fm...@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
>>>
>>
>>
Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise 4.2.3
Posted by Igor Blanco <ib...@binovo.es>.
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 <fm...@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: iblanco@binovo.es
Telf. : 943493611
Dirección:
Astigarraga Bidea 2
Planta 6. - Ofi. 3-2
20180 Oiartzun ( Gipuzkoa )
Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise
4.2.3
Posted by Florian Müller <fm...@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