Thanks for your reply, Marcel.
On Thu, Feb 4, 2010 at 8:12 PM, Marcel Reutegger
<[email protected]> wrote:
> is that a single threaded environment or is it possible that multiple
> threads share a session? that's not supported.
The Session instance is only utilized by a single thread.
> what's the root cause of the exception?
Here goes, the silly-looking printouts are those that I put in
SearchIndex myself:
2010-02-05 19:48:20,794 DEBUG observation.ObservationDispatcher -
notifying 3 synchronous listeners.
2010-02-05 19:48:20,794 DEBUG core.SearchManager - onEvent: indexing started
2010-02-05 19:48:20,795 DEBUG lucene.SearchIndex - search index: updateNodes()
2010-02-05 19:48:20,796 DEBUG lucene.SearchIndex - trying to create document
2010-02-05 19:48:20,797 WARN lucene.SearchIndex - Exception while
creating document for node: 4977b098-bba2-4274-ae7d-7575d2679526:
javax.jcr.RepositoryException: Error while indexing node:
4977b098-bba2-4274-ae7d-7575d2679526 of type:
{http://www.jcp.org/jcr/nt/1.0}unstructured:
4977b098-bba2-4274-ae7d-7575d2679526/{}date-updated:
4977b098-bba2-4274-ae7d-7575d2679526/{}date-updated
2010-02-05 19:48:20,798 DEBUG lucene.SearchIndex - whoopsy, failed!,
root cause: org.apache.jackrabbit.core.state.NoSuchItemStateException:
4977b098-bba2-4274-ae7d-7575d2679526/{}date-updated
2010-02-05 19:48:20,798 DEBUG lucene.SearchIndex - trying to create document
2010-02-05 19:48:20,800 DEBUG core.SearchManager - onEvent: indexing
finished in 6 ms.
> are you able to re-index the workspace after such an event or is the
> data in the persistence manager corrupt as well?
If I just restart the app or the server, JackRabbit says the redo.log
is empty, so there's nothing to re-index, thus the state of the
indexes stays wrong, and I still get wrong query results.
Removing the contents of $home$/index and
$home$/workspaces/default/index directories and then restarting the
server, restores proper index.
--
sp
