Hi all, While trying to determine the cause of the repository corruption I enabled the consistency check within the persistence manager:
<param name="consistencyCheck" value="true"/> This generated about 10 occurrences of the following problem: 17 Aug 2007 06:50:54,798 ERROR org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager - NodeState cdbc8e43-71f3-4542-91be-747546d871c0 references unexistent child I presume the suggested next step is to repeat the test with "consistencyFix" true - any known issues with doing this? Are there any outstanding issues with 1.3.1 known to cause such corruption? Regards, Shaun -----Original Message----- From: sbarriba [mailto:[EMAIL PROTECTED] Sent: 16 August 2007 16:44 To: [email protected] Subject: Node corruption using Jackrabbit 1.3.1? Hi all, We upgraded to JackRabbit 1.3.1 a few days ago. We have since seen a couple of occasions where we've been able to get the repository in an indeterminate state. The following output shows the state of a node which has an ordered child node property called acme:components e.g. [miq:FooBar] > nt:base orderable + acme:components (acme:Component) multiple COPY We have an instance of FooBar where acme:components[5] has disappeared?? e.g. name type node new modified ------------------------------ --------------- --------- --------- --------- acme:components acme:Section true false false acme:components[2] acme:Text true false false acme:components[3] acme:Text true false false acme:components[4] acme:Text true false false acme:components[6] acme:Section true false false acme:components[7] acme:Section true false false jcr:created Date false false false jcr:primaryType Name false false false jcr:uuid String false false false I presume this could happen if the deletion of the child node succeeded by the saving of the parent FooBar node failed for some reason? Surely this is a state that should never happen? Regards, Shaun
