Strange error

[Miklos Pocsaji <mi...@gmail.com>]

Hi!

I get a NoSuchElementException running the following code

QueryResult result = QueryHelper.query(session, qstr.toString(), "xpath");
NodeIterator ni = result.getNodes();
while (ni.hasNext())
    {
      Node newsitem = ni.nextNode(); // ***
      // ...
    }

The row marked with *** throws the following:

java.util.NoSuchElementException
        at org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNodeImpl(NodeIteratorImpl.java:164)
        at org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNode(NodeIteratorImpl.java:72)
        at com.clarmont.cms.jcr.beans.NewsManagerBean.listNews(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)

Seems like the index is not coherent with the data stored. I am really
confused by this error, any ideas?
(Is it possible that unclosed sessions cause this error?)

Thank you in advance:
Miklos Pocsaji

Re: Strange error

[Marcel Reutegger <ma...@gmx.net>]

Hi Fabrizio,

Fabrizio Giustina wrote:
> No, the reason why I didn't submit any issue to jira is because I
> wasn't able to reproduce the error that caused the inconsistency...
> removing nodes usually removes them from the search index correctly, I
> was not able to recreate that situation in a junit test.
> After a few day's tests I ended up in removing the index directory to
> make lucene reindex the whole repository and now it's fine (the index
> has never been corrupted anymore).
> 
> I was thinking about adding an hook in the search result iterator in
> order to remove invalid nodes on the fly (a rude implementation: catch
> the NoSuchElement exception and remove it from the index): maybe this
> could be a fail safe solution in order to avoid ghost nodes in the
> search index?

yeah, I was also thinking about such a solution, but this would surely 
be just a workaround for this kind of situation. I'll probably implement 
a more failsafe iterator which will log as much information as possible 
about the node when this error occurs. this would then help to find out 
what acutally happens.

thanks a lot for your feedback.

hmm, just thought about the node type discussions we had on this list... 
  This might be a source where the nodes in the workspace are not in 
sync anymore with the index. If one modifies the custom_nodetypes.xml 
directly on the filesystem then this change will not be reflected in the 
search index.

regards
  marcel

Re: Strange error

[Fabrizio Giustina <fg...@gmail.com>]

On 7/5/05, Marcel Reutegger <ma...@gmx.net> wrote:
> Fabrizio Giustina encountered a similar error:
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/2363
> 
> But we haven't received any feedback whether he had been able to
> reproduce his error with a JUnit test.

No, the reason why I didn't submit any issue to jira is because I
wasn't able to reproduce the error that caused the inconsistency...
removing nodes usually removes them from the search index correctly, I
was not able to recreate that situation in a junit test.
After a few day's tests I ended up in removing the index directory to
make lucene reindex the whole repository and now it's fine (the index
has never been corrupted anymore).

I was thinking about adding an hook in the search result iterator in
order to remove invalid nodes on the fly (a rude implementation: catch
the NoSuchElement exception and remove it from the index): maybe this
could be a fail safe solution in order to avoid ghost nodes in the
search index?


fabrizio

Re: Strange error

[Marcel Reutegger <ma...@gmx.net>]

Hi Miklos,

Miklos Pocsaji wrote:
> I get a NoSuchElementException running the following code
> 
> QueryResult result = QueryHelper.query(session, qstr.toString(), "xpath");
> NodeIterator ni = result.getNodes();
> while (ni.hasNext())
>     {
>       Node newsitem = ni.nextNode(); // ***
>       // ...
>     }
</snip>
> Seems like the index is not coherent with the data stored. I am really
> confused by this error, any ideas?

Could you please try to find out what node in the index caused this 
error? I know it might be a bit tricky but it would help a lot to find 
the cause for this error. You should find an error message in the logs 
which states the uuid of the missing node. with this information you 
should be able to find the lucene document in one of the indexes in the 
workspace folder. Using a tool like Luke 
(http://www.getopt.org/luke/luke.jnlp) can help you on this journey ;)

I'm also interested to see, if the error also occurs if you restrict the 
query to only a subtree of the workspace. but maybe you're doing that 
already...

As a short term solution, you can delete the index in the workspace 
folder. The index is recreated on startup if it is missing.

> (Is it possible that unclosed sessions cause this error?)

well, the only situation where you can really force this error to 
happen, is, to delete a node (but not save its parent) and then search 
for something that matches the deleted node. That's because the index is 
based on the persistent view of the workspace, as specified by jsr-170.

Fabrizio Giustina encountered a similar error: 
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/2363

But we haven't received any feedback whether he had been able to 
reproduce his error with a JUnit test.

Anyway, I created a JIRA issue to keep track of this error:
http://issues.apache.org/jira/browse/JCR-160

regards
  marcel