jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aasoj j <aas....@gmail.com>
Subject Re: Unexpected ItemNotFoundException (cafebabe-cafe-babe-cafe-babecafebabe)
Date Wed, 08 Jul 2009 23:55:25 GMT

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

On Wed, Jul 8, 2009 at 7:28 PM, aasoj j <aas.ojj@gmail.com> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message