-
1. Re: Fix missing child references
hchiorean May 20, 2015 11:02 AM (in response to wesssel)There isn't anything you can do with IDs since they are completely internal and auto-generated by ModeShape. You cannot add a node with an explicit id (it's outside the JCR spec).
If your use case allows it, you can try getting the "missing" node by ID, copying its data into a new node, removing the old node and adding the new node under the same parent.
.This was a workaround for indexes that are not accurate, caused by Modeshape nodes periodically leaving the cluster, caused by OOMs since there was a workspace cache without eviction.
You should be aware that ModeShape (and Infinispan for that matter) cannot handle network partitions and remain consistent, so if you're experiencing this you'll have to come up with a solution yourselves. Being a JCR spec implementation, ModeShape requires strong consistency (at least linearizability) and this can't be guaranteed by ISPN in the presence of partitions.
-
2. Re: Fix missing child references
wesssel May 20, 2015 11:06 AM (in response to hchiorean)Removal of the old node will not work, since the node cannot be found under its parent, causing exceptions. Network partitions was not the problem we were experiencing. Parts of the Modeshape cluster just crashed altogether, leaving them with inaccurate indexes as nodes were added on the cluster that was still running. Thus when trying to add a node after querying for its existence on a restarted instance, the query can come up false. When trying to add, the node did however already exist under the parent, which is why we implemented the try-catch block.
I guess this is a case that could be fixed when implementing https://issues.jboss.org/browse/MODE-1641
-
3. Re: Fix missing child references
hchiorean May 21, 2015 2:24 AM (in response to wesssel)I guess this is a case that could be fixed when implementing https://issues.jboss.org/browse/MODE-1641
IMO this issue is more "wishful thinking" than something with a realistic chance of implementation. JCR-2.0 *is hugely complex* meaning it's highly unlikely to figure out what "repairing a repository" means. Moreover, data corruption can mean more inconsistencies than just in terms of the JCR2.0 invariants, but also in terms of internal data structures (the problem you're describing is such an example). ModeShape is essentially a JCR2.0 implementation, not a data store/database (for which such a utility would make more sense perhaps).
The more realistic approach to data corruption is tracking down the cause of the corruption (via samples/test cases) and trying to solve it so that it doesn't happen again. Issues like [MODE-2420] Modeshape can potentially lose data because Infinispan Cache Stores do not participate in transactions - JBo… on the other hand mean that in theory at least, there can be cases of data corruption/inconsistency where ModeShape can do absolutely nothing as they are caused by Infinispan's design.