Document checkin fails

[longinus]

Hello All

We are getting this exception while checking in multiple versions of the document. It seems like the update is not complete yet and checkin appears too early. Is there a way to confirm that document versions has been updated before we check in?

CmisStorageException: Expected 29184 bytes but retrieved 0 bytes!

org.apache.chemistry.opencmis.client.bindings.spi.browser.AbstractBrowserBindingService.post(AbstractBrowserBindingService.java:362)

        at org.apache.chemistry.opencmis.client.bindings.spi.browser.VersioningServiceImpl.checkIn(VersioningServiceImpl.java:123)

        at org.apache.chemistry.opencmis.client.runtime.DocumentImpl.checkIn()

Many thanks

Krzysztof

[jpotts]

If you post the Java code that is performing the checkout and the check-in someone might be able to help you. Otherwise, we can only guess.

[longinus]

Sure, sorry about that. I are using OpenCMIS api to call alfresco core:

ObjectId pwcId = ((Document) target).checkOut();
Document pwcDocument = (Document) session.getObject(pwcId);
ContentStream contentStream = createContentStream(name, contentlength, mimeType, content);
ObjectId newVersionId = pwcDocument.checkIn(updateMajor, null, contentStream, "new version");

The problem is we update the document in batch, creating new versions. It seems like previous update is not complete when we attempt to check out for new version.

It would be nice to instruct CMIS to perform checkout when the previous check-in is complete.

[longinus]

Would you say that DocumentProperties.isVersionSeriesCheckedOut() is a good assumption about document being ready for checkout? Or if clients should sleep and try again in 2s?

[phong_van]

Dear Longinus,

Have you found to solution for this issue? I'm  facing the same issue. So I must Sleep 2s, a try again later. But I don't like this.

[drivera]

I'm running into this using Alfresco Community - 6.0.7 (rb4fe76b5-b113). This is definitely a race condition or some other less-than-predictable problem within Alfresco since if I run the same code again, the files that failed originally now succeed, while other files that succeeded earlier fail.

The code is also confirmed to submit the correct data over the wire using Browser bindings (through HTTP sniffing).

I found this thread that seems to suggest this is some sort of an issue with TempFileProvider, which would make sense since it seems to be sporadic. While that thread does reference the SVN for Alfresco 4.2f, I suspect this is one of those issues that has simply slept its way into the future b/c of how infrequently it rears its head.

Cheers!