Return-Path: X-Original-To: apmail-chemistry-dev-archive@www.apache.org Delivered-To: apmail-chemistry-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3C53E179D8 for ; Mon, 30 Mar 2015 15:21:55 +0000 (UTC) Received: (qmail 7593 invoked by uid 500); 30 Mar 2015 15:20:56 -0000 Delivered-To: apmail-chemistry-dev-archive@chemistry.apache.org Received: (qmail 7542 invoked by uid 500); 30 Mar 2015 15:20:56 -0000 Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@chemistry.apache.org Delivered-To: mailing list dev@chemistry.apache.org Received: (qmail 7530 invoked by uid 99); 30 Mar 2015 15:20:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Mar 2015 15:20:56 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of iblanco@binovo.es designates 209.85.216.175 as permitted sender) Received: from [209.85.216.175] (HELO mail-qc0-f175.google.com) (209.85.216.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Mar 2015 15:20:30 +0000 Received: by qcbjx9 with SMTP id jx9so74064360qcb.0 for ; Mon, 30 Mar 2015 08:20:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x3K8xCGiuBIa7QNj8Fqoqi4DWLb2fmbyapwDbD/YZq4=; b=fAhZfgjJcKxbtlsBCBwPsJwzW6s7VO5dDmZ4Y0qUOjdHJIkJrj4uKFkLwNRti2fkCT e6/ptaFpc2YMOVkVqEudUoKhGExYvTb20CU74cp3DZEsJXaE/oqLtDgju2JUPv0+VCKu nFsSUKQ19rN+vDstCy6otVMx4BrI8VCDd8qzuZNmGZdlbON2lobCcRwP7DiwTHku67Hn 95SzmoT8HHajy+fqXKoga3OPkeinuwmQchhHuNQEdLN7Ii6VUXjp+XrhZB3AvREXUV2Q EvEtm3elLx+XmWikgwYlbn2u7jsTLLR9+JCqIsGMnfskK0sNQIDi5cSueqxphpIW7bq8 ovcg== X-Gm-Message-State: ALoCoQkYiXpEjq0FbD2zoX29vjdeIGFg9VSL5H/6XKTSRqlR/vjq6GN+UjibjZC9WnENk4S5jzQQ MIME-Version: 1.0 X-Received: by 10.55.53.85 with SMTP id c82mr69271402qka.45.1427728828882; Mon, 30 Mar 2015 08:20:28 -0700 (PDT) Received: by 10.140.47.5 with HTTP; Mon, 30 Mar 2015 08:20:28 -0700 (PDT) In-Reply-To: <7b099df173b5aa44f8664c67d73cea5a@jpberlin.de> References: <7b099df173b5aa44f8664c67d73cea5a@jpberlin.de> Date: Mon, 30 Mar 2015 17:20:28 +0200 Message-ID: Subject: Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise 4.2.3 From: Igor Blanco To: dev@chemistry.apache.org Cc: Mark Streit Content-Type: multipart/alternative; boundary=001a114903c8ae6b3b051283059f X-Virus-Checked: Checked by ClamAV on apache.org --001a114903c8ae6b3b051283059f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=BCller : > 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 o= ur >> 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 th= e >> 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 an= d >> 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 =3D 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 =3D 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 seei= ng >> thread safety problem? So multiple uploads are happening on different >> threads to Alfresco through one Session. Could this be part of the iss= ue >> we are seeing? Should we create a new Session for each request? It's ou= r >> understanding that it's expensive to create Session objects each time an= d >> that we shouldn't have to do that. >> >> >> Thought we'd ask here in case this has been seen before. >> >> >> >> Thanks >> >> >> >> Mark >> > > --=20 Igor Blanco Gonz=C3=A1lez Binovo IT Human Project e-mail: iblanco@binovo.es Telf. : 943493611 Direcci=C3=B3n: Astigarraga Bidea 2 Planta 6. - Ofi. 3-2 20180 Oiartzun ( Gipuzkoa ) --001a114903c8ae6b3b051283059f--