You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Johannes Boneschanscher <ja...@boneschanscher.net> on 2008/11/21 22:50:23 UTC

RepositoryException failed to resolve name of

Does anyone know why on a particular query we always get this exception?

Caused by: javax.jcr.RepositoryException: failed to resolve name of 
25a3e325-815c-4e23-8b0d-48acb9869d7e
        at 
org.apache.jackrabbit.core.HierarchyManagerImpl.getName(HierarchyManagerImpl.java:451)
        at 
org.apache.jackrabbit.core.CachingHierarchyManager.getName(CachingHierarchyManager.java:285)
        at org.apache.jackrabbit.core.NodeImpl.getName(NodeImpl.java:1931)
        at 
org.customer.vi.dpvi.myapp.jcr.security.jackrabbit.RubriceringAccessManager.isGranted(RubriceringAccessManager.java:174)
        at 
org.apache.jackrabbit.core.query.lucene.QueryResultImpl.getResults(QueryResultImpl.java:303)
        at 
org.apache.jackrabbit.core.query.lucene.QueryResultImpl.<init>(QueryResultImpl.java:192)
        at 
org.apache.jackrabbit.core.query.lucene.QueryImpl.execute(QueryImpl.java:138)
        at 
org.apache.jackrabbit.core.query.QueryImpl.execute(QueryImpl.java:176)
        at 
org.customer.vi.dpvi.myapp.service.impl.jcr.JcrVidiServiceImpl$2.doInSession(JcrVidiServiceImpl.java:264)
        at 
org.customer.vi.dpvi.myapp.service.impl.jcr.JcrVidiServiceImpl.execute(JcrVidiServiceImpl.java:2051)
        ... 78 more

This is what I understand from it (reading the stacktrace bottom up):

On executing a query, which is handled by Lucene, while retrieving the 
results, it tries to find a Node name,
presumably because it only has it's UUID from some search index.

We have a clustered JackRabbit configuration, meaning multiple cluster 
nodes share the same database datastore,
but each node has it's own Lucene indexes on disk.
For failover purposes these indexes are on a network share, which 
recently became unavailable, causing all searches to fail.

After restarting the application server nodes which are serving 
JackRabbit and our customers application everything seems
fine except above mentioned problem.

What can/should we do to fix it?

Regards,

Johannes

Re: RepositoryException failed to resolve name of

Posted by Jan Grathwohl <ja...@kontrast.de>.
Hi Johannes,

if the Exception is caused by a corrupted search index, it should be  
gone after a complete rebuild of the index. Did you try that already?

To rebuild the indices for a cluster node, you have to shutdown the  
Jackrabbit instance, delete all "index" directories (there is one  
repository-wide index for the versions plus one for each workspace),  
and restart Jackrabbit. The indices will then automatically be  
recreated by re-indexing all content from the repository. But as this  
is done during Jackrabbit startup, the cluster node won't be availabe  
while the index is being recreated, and this might take quite long,  
depending on the size of the repository. So it may not always be  
possible to do that with a running production system.

If the Exception is caused by something else, it might happen that the  
rebuilding of the index would fail and the reindexing would not be  
completed. So it will be a good idea to keep a backup copy of the  
original index before starting this whole procedure.

BR,

Jan



Am 22.11.2008 um 16:34 schrieb Johannes Boneschanscher:

> I'm sorry to bother everyone on the list again, drawing attention to  
> my question, but I hope it's quite simple...
>
> I also did some extra research and found some settings for the  
> Lucene search which are not enabled on our customers production  
> server or enabled by default.
>
> But I'm not sure at all that Lucene is at fault, or whether this  
> could fix it. By the way: We are using Jackrabbit 1.3 in case anyone  
> wants to know.
>
> Should I try enabling (on a production server) the parameters  
> mentioned on:
>
> http://wiki.apache.org/jackrabbit/Search
>
> enableConsistencyCheck
> forceConsistencyCheck
>
> And why is enableConsistencyCheck false by default?
>
> Hope someone can give a hint here :-)
>
> Regards,
>
> Johannes
>
>
> Johannes Boneschanscher wrote:
>> Does anyone know why on a particular query we always get this  
>> exception?
>>
>> Caused by: javax.jcr.RepositoryException: failed to resolve name of  
>> 25a3e325-815c-4e23-8b0d-48acb9869d7e
>>       at  
>> org 
>> .apache 
>> .jackrabbit 
>> .core.HierarchyManagerImpl.getName(HierarchyManagerImpl.java:451)
>>       at  
>> org 
>> .apache 
>> .jackrabbit 
>> .core.CachingHierarchyManager.getName(CachingHierarchyManager.java: 
>> 285)
>>       at org.apache.jackrabbit.core.NodeImpl.getName(NodeImpl.java: 
>> 1931)
>>       at  
>> org 
>> .customer 
>> .vi 
>> .dpvi 
>> .myapp 
>> .jcr 
>> .security 
>> .jackrabbit 
>> .RubriceringAccessManager.isGranted(RubriceringAccessManager.java: 
>> 174)
>>       at  
>> org 
>> .apache 
>> .jackrabbit 
>> .core.query.lucene.QueryResultImpl.getResults(QueryResultImpl.java: 
>> 303)
>>       at  
>> org 
>> .apache 
>> .jackrabbit 
>> .core.query.lucene.QueryResultImpl.<init>(QueryResultImpl.java:192)
>>       at  
>> org 
>> .apache 
>> .jackrabbit.core.query.lucene.QueryImpl.execute(QueryImpl.java:138)
>>       at  
>> org.apache.jackrabbit.core.query.QueryImpl.execute(QueryImpl.java: 
>> 176)
>>       at  
>> org.customer.vi.dpvi.myapp.service.impl.jcr.JcrVidiServiceImpl 
>> $2.doInSession(JcrVidiServiceImpl.java:264)
>>       at  
>> org 
>> .customer 
>> .vi 
>> .dpvi 
>> .myapp 
>> .service 
>> .impl.jcr.JcrVidiServiceImpl.execute(JcrVidiServiceImpl.java:2051)
>>       ... 78 more
>>
>> This is what I understand from it (reading the stacktrace bottom up):
>>
>> On executing a query, which is handled by Lucene, while retrieving  
>> the results, it tries to find a Node name,
>> presumably because it only has it's UUID from some search index.
>>
>> We have a clustered JackRabbit configuration, meaning multiple  
>> cluster nodes share the same database datastore,
>> but each node has it's own Lucene indexes on disk.
>> For failover purposes these indexes are on a network share, which  
>> recently became unavailable, causing all searches to fail.
>>
>> After restarting the application server nodes which are serving  
>> JackRabbit and our customers application everything seems
>> fine except above mentioned problem.
>>
>> What can/should we do to fix it?
>>
>> Regards,
>>
>> Johannes
>


Re: RepositoryException failed to resolve name of

Posted by Marcel Reutegger <ma...@gmx.net>.
Johannes Boneschanscher wrote:
> And why is enableConsistencyCheck false by default?

see: https://issues.apache.org/jira/browse/JCR-1063

regards
 marcel

Re: RepositoryException failed to resolve name of

Posted by Johannes Boneschanscher <ja...@boneschanscher.net>.
I'm sorry to bother everyone on the list again, drawing attention to my 
question, but I hope it's quite simple...

I also did some extra research and found some settings for the Lucene 
search which are not enabled on our customers production server or 
enabled by default.

But I'm not sure at all that Lucene is at fault, or whether this could 
fix it. By the way: We are using Jackrabbit 1.3 in case anyone wants to 
know.

Should I try enabling (on a production server) the parameters mentioned on:

http://wiki.apache.org/jackrabbit/Search

enableConsistencyCheck
forceConsistencyCheck

And why is enableConsistencyCheck false by default?

Hope someone can give a hint here :-)

Regards,

Johannes


Johannes Boneschanscher wrote:
> Does anyone know why on a particular query we always get this exception?
>
> Caused by: javax.jcr.RepositoryException: failed to resolve name of 
> 25a3e325-815c-4e23-8b0d-48acb9869d7e
>        at 
> org.apache.jackrabbit.core.HierarchyManagerImpl.getName(HierarchyManagerImpl.java:451) 
>
>        at 
> org.apache.jackrabbit.core.CachingHierarchyManager.getName(CachingHierarchyManager.java:285) 
>
>        at org.apache.jackrabbit.core.NodeImpl.getName(NodeImpl.java:1931)
>        at 
> org.customer.vi.dpvi.myapp.jcr.security.jackrabbit.RubriceringAccessManager.isGranted(RubriceringAccessManager.java:174) 
>
>        at 
> org.apache.jackrabbit.core.query.lucene.QueryResultImpl.getResults(QueryResultImpl.java:303) 
>
>        at 
> org.apache.jackrabbit.core.query.lucene.QueryResultImpl.<init>(QueryResultImpl.java:192) 
>
>        at 
> org.apache.jackrabbit.core.query.lucene.QueryImpl.execute(QueryImpl.java:138) 
>
>        at 
> org.apache.jackrabbit.core.query.QueryImpl.execute(QueryImpl.java:176)
>        at 
> org.customer.vi.dpvi.myapp.service.impl.jcr.JcrVidiServiceImpl$2.doInSession(JcrVidiServiceImpl.java:264) 
>
>        at 
> org.customer.vi.dpvi.myapp.service.impl.jcr.JcrVidiServiceImpl.execute(JcrVidiServiceImpl.java:2051) 
>
>        ... 78 more
>
> This is what I understand from it (reading the stacktrace bottom up):
>
> On executing a query, which is handled by Lucene, while retrieving the 
> results, it tries to find a Node name,
> presumably because it only has it's UUID from some search index.
>
> We have a clustered JackRabbit configuration, meaning multiple cluster 
> nodes share the same database datastore,
> but each node has it's own Lucene indexes on disk.
> For failover purposes these indexes are on a network share, which 
> recently became unavailable, causing all searches to fail.
>
> After restarting the application server nodes which are serving 
> JackRabbit and our customers application everything seems
> fine except above mentioned problem.
>
> What can/should we do to fix it?
>
> Regards,
>
> Johannes