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?
Date Fri, 17 Aug 2007 11:45:16 GMT
Hi Stefan et al,
Further update on this, plus some answers to your questions.

The consistency check and fix logic in JackRabbit 1.3.1 solved all but 1 of
the issues. However although the log reports the remaining issue has been
fixed each time, this message appears after repeated restarts :(

org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager  -
acme: checked 1000/0 bundles...
org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager  -
NodeState fe75116c-5617-423b-8c9a-4a964b667f20 references unexistent child
{http://www.acme.co.uk/xmlns/contentmodel}components with id
d3c09b52-d3be-4d3c-8807-b7827d337973
org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager  -
acme: checked 2000/0 bundles...
org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager  -
acme: Fixing 1 inconsistent bundle(s)...
org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager  -
acme: Fixing bundle fe75116c-5617-423b-8c9a-4a964b667f20
org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager  -
acme: checked 2505/0 bundles.

Is the consistency checker the only way to fix up these problems, or is
there any way we can 'open the hood' to investigate further?

Stefan wrote:
"did you notice anything peculiar about the corrupt nodes? is there a chance
to reconstruct the steps that lead to this state?"

What tools what you recommend using to review the corrupt nodes? We only
currently use the command contrib. project.

Reproducing this scenario is proving really difficult. The original
corruption occurred when a user was creating a particularly complex node
object which included the creation, deletion and re-ordering of various
same-name-siblings. After multi-hours of attempts we are yet to reproduce
the event. Frustrating, but we know its occurred at least twice.

"furthermore, could you please share some details about your
config/deployment?"

Sure. 
 - JackRabbit 1.3.1
 	- MySql Bundle Persistence Manager
	- Clustered across 2 nodes - only 1 node is read-write, the other is
read-only to the repos
      - Spring used to provide a JackRabbit JCRSessionInHttpSession pattern
for the editors who are using a web-based UI.
 - MySql 5.0.45
 - Tomcat 5.0.30
 - Sun JDK 1.5
 - Redhat Enterprise Linux

All suggestions welcome.
Regards,
Shaun


-----Original Message-----
From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com] 
Sent: 17 August 2007 11:26
To: users@jackrabbit.apache.org
Subject: Re: Node corruption using Jackrabbit 1.3.1?

hi shaun,

On 8/16/07, sbarriba <sbarriba@yahoo.co.uk> wrote:
> 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?

that should be possible since the changelog of a save operation is stored
atomically. if an error occurs during processing of the change log all
previous changes are rolled back.

>
>
>
> Surely this is a state that should never happen?

absolutely, and the problem you're describing is very alarming indeed!

did you notice anything peculiar about the corrupt nodes? is there a chance
to reconstruct the steps that lead to this state?

furthermore, could you please share some details about your
config/deployment?

the only possible explanation i can currently come up with is
that there are multiple jackrabbit instances accessing the same
database...

cheers
stefan


>
>
>
> Regards,
>
> Shaun
>
>
>
>


Mime
View raw message