jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sbarriba" <sbarr...@yahoo.co.uk>
Subject RE: Node corruption using Jackrabbit 1.3.1? - consistency check fails
Date Fri, 17 Aug 2007 05:59:10 GMT
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:sbarriba@yahoo.co.uk] 
Sent: 16 August 2007 16:44
To: users@jackrabbit.apache.org
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

 



Mime
View raw message