Hi, I don't think this is JCR-2171 issue as the deadlock hangs the process and does not throw any exceptions.
The UUID not found (cafebabe-cafe-babe-cafe-babecafebabe) is the root node (jcr:root) which is mandatory and is the entry point for reconstructing node hierarchy. Is this error occurs only for new nodes on the cluster ? If so, this can be the following issue: https://issues.apache.org/jira/browse/JCR-1558 Otherwise, i think your repository is inconsistent, maybe the root node has been lost or corrupted or the local configuration of a node is not valid. In this case, you may want to try restarting the node from scratch after deleting the home repository folder (data is shared in MySQL), this can take times because all changelog needs to be replayed for creating the index. aasoj j a écrit : > Hi, > > Could this "(JCR-2171) Deadlock in SharedItemStateManager on session.move > and node.save" be causing this issue below? > > "Jukka Zitting updated JCR-2171: > ------------------------------- > > Attachment: JCR-2171.patch > > Yes, I can see the issue you're encountering. > > The cause of the problem is the fact that instead of simply evicting > modified entries when receiving node state updates, the > CachingHierarchyManager tries to read the modified states and update the > cache accordingly. It seems that this behaviour was added (and is needed?) > for the shareable node feature." > > > > The primary question is, how is the repository recovered? > > > Thanks and Regards > aasoj > > > On Wed, Jul 8, 2009 at 7:28 PM, aasoj j <[email protected]> wrote: > > >> Hi all, >> >> We have started seeing an unexpected error in our application. >> >> javax.jcr.ItemNotFoundException: failed to build path of >> b91e0f2a-844e-4c7e-97d9-1efa03878956: cafebabe-cafe-babe-cafe-babecafebabe >> has no child entry for b91e0f2a-844e-4c7e-97d9-1efa03878956 >> at >> org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyManagerImpl.java:289) >> at >> org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarchyManager.java:195) >> at >> org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:393) >> at >> org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierarchyManager.java:229) >> at >> org.apache.jackrabbit.core.ItemImpl.getPrimaryPath(ItemImpl.java:213) >> at >> org.apache.jackrabbit.core.NodeImpl.getPrimaryPath(NodeImpl.java:3240) >> >> JR version 1.5.5 (cluster deployment, 2 nodes) >> MySQL persistence >> java version 1.6.0_06 (64 bit) >> >> We tried restarting the application, deleting indexes. But the exception is >> seen every time. Sessions are not shared, i.e. a new session is created for >> every read or write. The tree has very few nodes, and we were adding 4 nodes >> sequentially in the same session. >> >> We are not able to reproduce this issue on a fresh setup. >> >> Please see if you could answer the following questions: >> 1. How do we recover from this state? >> 2. How do we prevent this situation in future? >> >> >> Regards >> aasoj >> >> >> > > -- Sébastien Launay
