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 191E717A9A for ; Mon, 30 Mar 2015 15:36:31 +0000 (UTC) Received: (qmail 42576 invoked by uid 500); 30 Mar 2015 15:36:28 -0000 Delivered-To: apmail-chemistry-dev-archive@chemistry.apache.org Received: (qmail 42521 invoked by uid 500); 30 Mar 2015 15:36:27 -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 42509 invoked by uid 99); 30 Mar 2015 15:36:27 -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:36:27 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mcs130@gmail.com designates 209.85.223.175 as permitted sender) Received: from [209.85.223.175] (HELO mail-ie0-f175.google.com) (209.85.223.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Mar 2015 15:36:02 +0000 Received: by iedm5 with SMTP id m5so120854548ied.3 for ; Mon, 30 Mar 2015 08:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5uF6xdXkL9AaSnh6gic3PVSYIpRsaGDc44yX1qIZ8mk=; b=r6sE4TQ2rhLwG/Gji91Xjv7PCyL48lKuiLuwi7f73nerhBJTVSMkaVRRgaeEnhhXo8 Vs1mRoppff9GDupAGlzEkZKH7yPP/hSqigCy+OwLcFdM/U6pMEikLVzFY8J/0/QPwxYR PJ8bpeFSiCq69cq5AibRgSxetwDsX1U/EGrUBnimWTq6kv9QA3T4Xie+O3DP9R38zB1a 9M41OO3Hz89fJ/H0c+PljENfXfyC9ZlnlKx/dhT6yJYLEgHrTCWy3B6wPilekwtUnJ9o VsiaS4SE5w1vUNUiAEZNSrHuA6l1zFb5fFM5+p1J1RhR1k2r8+kA+zMadY0sjGL+ZUPz v+jQ== MIME-Version: 1.0 X-Received: by 10.42.77.4 with SMTP id g4mr60989128ick.17.1427729760550; Mon, 30 Mar 2015 08:36:00 -0700 (PDT) Received: by 10.50.4.165 with HTTP; Mon, 30 Mar 2015 08:36:00 -0700 (PDT) In-Reply-To: References: <7b099df173b5aa44f8664c67d73cea5a@jpberlin.de> Date: Mon, 30 Mar 2015 11:36:00 -0400 Message-ID: Subject: Re: CmisStorageException with OpenCMIS 0.10.0 - Alfresco Enterprise 4.2.3 From: Mark Streit To: Igor Blanco Cc: "dev@chemistry.apache.org" Content-Type: multipart/alternative; boundary=20cf3005da463683b30512833d2b X-Virus-Checked: Checked by ClamAV on apache.org --20cf3005da463683b30512833d2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =3D 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 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 fil= e > 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 i= s >> 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 cod= e. >> >> >> - Florian >> >> >> >> >> *Chemistry experts * >>> >>> >>> >>> *We have a large CMIS implementation using Alfresco Enterprise 4.2.3 an= d >>> 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 document= s >>> in >>> parallel - we now have custom built REST services layer that receives t= he >>> 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 a= nd >>> 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 6520= 1 >>> 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 mad= e >>> 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 o= f >>> 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 i= n >>> all cases, the Map of properties, the contentStream, and versioningStat= e >>> 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 o= ur >>> understanding that it's expensive to create Session objects each time a= nd >>> 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=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 ) > --20cf3005da463683b30512833d2b--