jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3652) Bundle serialization broken
Date Wed, 28 Aug 2013 08:15:51 GMT

    [ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13752202#comment-13752202

Thomas Mueller commented on JCR-3652:

A simpler test case:

Node node = root.addNode(nodeName);
try {
    node.setProperty("jcr:isCheckedOut", true);
} catch (ArrayIndexOutOfBoundsException e) {
    System.out.println("set failed strangely: " + e);

I think what happens is: the property is half-way added (in NodeImpl.SetPropertyOperation.perform,
PropertyImpl property = getOrCreateProperty(name, type, false, enforceType, status);). The
property is non-multi-valued, and the values array is 0. This seems to be always done like
that. Then it tries to set the value, with a try { property.setValue(value); } catch(RepositoryException)
{ ... revert ... }. The setValue checks if setting the value is allowed (via checkSetValue,
which calls ItemValidator.checkModify, which calls ItemValidator.checkCondition). At some
point this verification calls NodeImpl.isCheckedOut(). There is a "// FIXME should not only
rely on existence of jcr:isCheckedOut property" in the code, but for performance reason it
just gets the value of the jcr:isCheckedOut property, using "return ps.getValues()[0].getBoolean();".
Now, as the property is half-way set, this throws an ArrayOutOfBoundsException (half-way set
properties have an empty values array). Because this isn't a RepositoryException, this is
thrown back to the user, and the property remains half-way set. The internal state of the
node is corrupt.

One solution is to change NodeImpl.isCheckedOut() to deal with a half-way set property, and
throw a RepositoryException instead of a ArrayOutOfBoundsException. However, there might be
more checks that don't deal with half-way set properties.

In addition to the above, instead of just catching RepositoryException, the code could catch
Exception or even Throwable (that is, also Error). Usually catching Throwable isn't a good
idea, however the alternative (having a corrupt node) is much worse, so I guess this should
also be done.

The best solution would be not to have half-way set properties at all, but that would be quite
a big change, so I will not try to do that.

> Bundle serialization broken
> ---------------------------
>                 Key: JCR-3652
>                 URL: https://issues.apache.org/jira/browse/JCR-3652
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: jackrabbit-core
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>            Priority: Minor
>             Fix For: 2.4.4, 2.7.1
>         Attachments: JCR-3652.patch, JCR-3652-test-case.patch
> I have got a strange case where some node bundle is broken, seemingly because a byte
is missing. I can't explain the missing byte, but it is reproducible, meaning that writing
the bundles again will break them again. There are 11 broken bundles, 10 of them have the
size 480 bytes and one is slightly larger. It is always a boolean property value that is missing,
always the value for the property jcr:isCheckedOut.
> As a (temporary) solution, and to help analyze what the problem might be, I will create
a patch that does the following:
> * When serializing a bundle, check if the byte array can be de-serialized. If not, then
try again. Starting with the 3th try, use a slower variant where before and after writing
the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't
do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue.
> * If de-serializing a bundle fails, check if it's because of a missing boolean property
value. If yes, insert the missing byte.
> I have also added some log messages (warning / error) to help analyze the problem.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message