jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Hendriks (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-2129) Prevent data inconsistencies due to incorrect or missed merges in the ItemStateManagers
Date Mon, 08 Jun 2009 12:22:07 GMT

     [ https://issues.apache.org/jira/browse/JCR-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Martijn Hendriks updated JCR-2129:
----------------------------------

    Description: 
There are two places where transient state changes are merged with persisted state: (i) in
the SessionISM.stateModified call back method (typically called by a saving thread after it's
changes have been saved) and (ii) in the SharedISM.Update.begin method. Sometimes the merge
strategy fails in the sense that corrupt data is written to database. 

How to reproduce:
The attached test program contains steps to reproduce the issue. The testInconsistency1 method
concurrently adds a node D to a node A and moves child node B of A to another place. This
sometimes results in a situation in which node A still has a child reference to node B whereas
B has another parent. In this situation, Jackrabbit cannot be started anymore if the search
index is missing: 

Jun 8, 2009 2:16:23 PM org.apache.jackrabbit.core.query.OnWorkspaceInconsistency$1 handleMissingChildNode
SEVERE: Node /A (a7a29e8c-8d13-4fbd-b0ca-4f93f9c0ef42) has missing child 'B' (80aa13c5-1db6-4f62-b576-5e7f626d90c1)
Jun 8, 2009 2:16:23 PM org.apache.jackrabbit.core.RepositoryImpl initStartupWorkspaces
SEVERE: Failed to initialize workspace 'wm9'

The testInconsistency2 method concurrently adds a reference property to a node B (the threads
do exactly the same). This sometimes results in a situation in which the referenced node can
never be removed anymore because there is a "ghost" reference to it which cannot be removed.
(It gives a ReferentialIntegrityException).

Jun 8, 2009 2:19:51 PM org.apache.jackrabbit.core.state.MLRUItemStateCache cache
WARNING: overwriting cached entry bc28ff87-216d-4ccd-bd73-03e7499ab54e/{}ref to B
Exception in thread "main" javax.jcr.ReferentialIntegrityException: 9f025634-d3e1-448e-904c-1c285f6b1bf6:
the node cannot be removed because it is still being referenced.

It seems the first problem (the parent-child relation) is caused by an incorrect merge in
the NodeStateMerger class. The second problem might also be caused by an incorrect or missed
merge, but I am not sure whether that's the real problem.



  was:
The SharedItemStateManager.Update class's begin method tests whether states in the given local
ChangeLog are stale. If so, it tries to merge the changes to the new persisted state. It does
this by comparing the modCount of state instances for non-transient states. There is a race
between threads that call save such that sometimes this test fails and states are not merged
when they should be. As a result, the data in the repository can become corrupt and, for instance,
it becomes impossible to start Jackrabbit or remove certain nodes.

Analysis: persisted state information, including modCount, is pushed down from another thread
while a local ChangeLog is being constructed. The increased modCount thus appears in the local
ChangeLog and the SharedISM falsely assumes that the state in the local ChangeLog needs no
merging (isStale test).

Reproduction:
The attached test program contains steps to reproduce the issue (see comments of the testInconsistency1
and testInconsistency2 methods).



        Summary: Prevent data inconsistencies due to incorrect or missed merges in the ItemStateManagers
 (was: Prevent data inconsistencies due to missed merges in the SharedItemStateManager)

> Prevent data inconsistencies due to incorrect or missed merges in the ItemStateManagers
> ---------------------------------------------------------------------------------------
>
>                 Key: JCR-2129
>                 URL: https://issues.apache.org/jira/browse/JCR-2129
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: core 1.4.5, 2.0.0
>            Reporter: Martijn Hendriks
>            Priority: Critical
>         Attachments: InconsistencyTest.java, repository.xml
>
>
> There are two places where transient state changes are merged with persisted state: (i)
in the SessionISM.stateModified call back method (typically called by a saving thread after
it's changes have been saved) and (ii) in the SharedISM.Update.begin method. Sometimes the
merge strategy fails in the sense that corrupt data is written to database. 
> How to reproduce:
> The attached test program contains steps to reproduce the issue. The testInconsistency1
method concurrently adds a node D to a node A and moves child node B of A to another place.
This sometimes results in a situation in which node A still has a child reference to node
B whereas B has another parent. In this situation, Jackrabbit cannot be started anymore if
the search index is missing: 
> Jun 8, 2009 2:16:23 PM org.apache.jackrabbit.core.query.OnWorkspaceInconsistency$1 handleMissingChildNode
> SEVERE: Node /A (a7a29e8c-8d13-4fbd-b0ca-4f93f9c0ef42) has missing child 'B' (80aa13c5-1db6-4f62-b576-5e7f626d90c1)
> Jun 8, 2009 2:16:23 PM org.apache.jackrabbit.core.RepositoryImpl initStartupWorkspaces
> SEVERE: Failed to initialize workspace 'wm9'
> The testInconsistency2 method concurrently adds a reference property to a node B (the
threads do exactly the same). This sometimes results in a situation in which the referenced
node can never be removed anymore because there is a "ghost" reference to it which cannot
be removed. (It gives a ReferentialIntegrityException).
> Jun 8, 2009 2:19:51 PM org.apache.jackrabbit.core.state.MLRUItemStateCache cache
> WARNING: overwriting cached entry bc28ff87-216d-4ccd-bd73-03e7499ab54e/{}ref to B
> Exception in thread "main" javax.jcr.ReferentialIntegrityException: 9f025634-d3e1-448e-904c-1c285f6b1bf6:
the node cannot be removed because it is still being referenced.
> It seems the first problem (the parent-child relation) is caused by an incorrect merge
in the NodeStateMerger class. The second problem might also be caused by an incorrect or missed
merge, but I am not sure whether that's the real problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message