nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

CmisStorageException on checkin

timwebster9

Hi,

I am trying to programmatically add and checkout/checkin documents against Alfresco 4.2f using Apache Chemistry v11.0 (atompub binding). Frequently I get the following exception from the server while performing a checkin:

org.apache.chemistry.opencmis.commons.exceptions.CmisStorageException: Expected 654502 bytes but retrieved 0 bytes!
   at org.alfresco.opencmis.AlfrescoCmisServiceImpl.copyToTempFile(AlfrescoCmisServiceImpl.java:2812)
   at org.alfresco.opencmis.AlfrescoCmisServiceImpl.checkIn(AlfrescoCmisServiceImpl.java:2029)
‍‍‍‍‍

If the checkin fails the document remains checkout out, so I then try to delete the document like so (the document here is the object returned from the original createDocument() call):

            if (document.isVersionSeriesCheckedOut()) {
                LOG.info("Cancelling checkout of document with id {}.", document.getId());
                document.cancelCheckOut();
            }

            document.delete();
‍‍‍‍‍‍‍‍

However, the check to see if it's checked out returns false, and it tries to delete it anyway, resulting in another exception:

org.apache.chemistry.opencmis.commons.exceptions.CmisConstraintException: Could not delete/cancel checkout on the original checked out document

Am I doing anything obviously wrong?

Thanks,

Find more posts tagged with

Comments

kaynezhang

You can avoid this exception

 CmisStorageException: Expected 654502 bytes but retrieved 0 bytes!‍

by specifying content stream length when construct ContentStream like below

         File file = new File("C:\\userguide.pdf");
         InputStream fis = new FileInputStream(file);
         DataInputStream dis = new DataInputStream(fis);
         byte[] bytes = new byte[(int) file.length()];
         dis.readFully(bytes);
         ContentStream contentStream = new ContentStreamImpl(file
               .getAbsolutePath(), BigInteger.valueOf(bytes.length), "application/pdf",
               new ByteArrayInputStream(bytes));
‍‍‍‍‍‍‍‍‍‍

timwebster9

Hi,

Thanks for the reply. I am already doing that however.

I've also discovered that if I put a break point in my code between the checkout and checkin, it always works. Does the server need some fine-tuning maybe?

kaynezhang

Please reload the object form the repository using

d.refresh();‍

or object checking status only maintented in client side.

document.checkIn(**);
document.refresh();// reload the object 
 if (document.isVersionSeriesCheckedOut()) {
                LOG.info("Cancelling checkout of document with id {}.", document.getId());
                document.cancelCheckOut();
      
            }
 
            document.delete();
‍‍‍‍‍‍‍‍‍‍‍

timwebster9

ok thanks, will give that a try.

Regarding the other problem, for now putting a small wait (200 - 500ms) between the checkout and checkin seems to fix it, but obviously this doesn't seem like a long-term solution. It could be my setup - this is OOB alfresco install with no extra configuration or tuning.

timwebster9

thanks for that - that sorted out the delete problem…:-)

kaynezhang

This is caused by apache chemistry client side caching.

Client side caching is turned on by default. That is, getObject() will first look into the session cache if the object already exists there. If this is the case, it returns the object without talking to the repository. So it might return stale objects.

you can look to http://chemistry.apache.org/java/developing/dev-client-cache.html

aowian

I had a similar problem on a clustered Alfresco with 5 nodes. It is due to a cluster caching bug. We had to tether our client to a single instance of Alfresco. Since this is not optimal, we have introduced some retry logic similar to the RetryingTransactionHandler, and we are going to test if we can now remove the tethering.
We tested, and we still need the tethering even though our retry logic retries up to 10 times per transaction with a wait of 1 second in between.

ziggy

CmisStorageException: Expected 654502 bytes but retrieved 0 bytes!

I'm not a java person, but did a quick review of the code (since we're seeing similar issues while under load) --

There appear to be multiple things going on... I would suggest a need for some serious code reviews:

Inside "createTempFile()" -- are multiple issues, that based upon LOAD will personify themselves differently.

&nbsp;&nbsp;&nbsp; private File copyToTempFile(ContentStream contentStream)
&nbsp;&nbsp;&nbsp; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (contentStream == null)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return null;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; File result = null;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; result = TempFileProvider.createTempFile(contentStream.getStream(), "cmis", "content");
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; catch (Exception e)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw new CmisStorageException("Unable to store content: " + e.getMessage(), e);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if ((contentStream.getLength() > -1) && (result == null || contentStream.getLength() != result.length()))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; removeTempFile(result);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw new CmisStorageException("Expected " + contentStream.getLength() + " bytes but retrieved " +
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (result == null ? -1 :result.length()) + " bytes!");
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return result;
&nbsp;&nbsp;&nbsp; }

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

"result" is out of scope and should be dereferenced when the delete file is performed under the "removeTempFile(result)"
".createTempFile(contentStream.getStream()..." -- consumes contentStream.getStream() -- and also performs a "close" of the stream in its "Finally"-block. However, the above code wants to continue to rely on contentStream.getLength() -- as if it should remain in scope

aowian

For one, the removeTempFile(result); makes result.length() always be zero. Therefore the exception message is misleading. Perhaps we ought to be seeing "Expected 654502 bytes but retrieved 654500 bytes!"

*Update*

I patched the war to retain the resultLength

        if ((contentStream.getLength() > -1) && (result == null || contentStream.getLength() != result.length()))
        {
            long resultLength = result.length();
            removeTempFile(result);
            throw new CmisStorageException("Expected " + contentStream.getLength() + " bytes but retrieved " +
                    (result == null ? -1 :resultLength) + " bytes!")
        }

and it still says "... retrieved 0 bytes!".

I did packet captures on both the cmis client and server sides, and they both show that the posts are garbled. It looks like the cmis client is generating garbled payloads, and the server cannot parse the content, resulting in zero-length content streams.

sachinsurya

Hello All,

We are getting "Expected 250536 bytes but retrieved 0 bytes!" in everyday file upload into Alfresco and If we re-run same process again then we are not getting any exception. We couldn't see a pattern when and why it is happening.

I read above answers in the thread but I am looking for how to re-produce the error and find the solution.

We are using below libraries.

org.alfresco.cmis.client = 1.0

org.apache.chemistry.opencmis = 0.13.0

Please advise.

Thanks,

Sachin

josenavarrovarg

Read the kayne zhang answer.

phong_van

Dear kayne zhang,

I've disable cache for session as your instruction, but in case of multi file upload concurrent, error still miss. To slove this problem, I must to sleep 2s (if multi file upload concurrent). So, do you have other solution? Please give me some advise?