[daisy] Re: Error when using the fulltext search (Daisy 2.0)

Bruno Dumon bruno at outerthought.org
Fri Oct 6 11:09:12 CDT 2006


(oops, forgot to press send, I've written this a couple of hours
ago ;-) )

On Fri, 2006-10-06 at 13:31 +0200, Andreas Deininger wrote:
> 2006/10/6, Bruno Dumon <bruno at outerthought.org>:
> > On Fri, 2006-10-06 at 10:27 +0200, Andreas Deininger wrote:
> > >
> > > Bingo! However, I'm still having difficulties to recreate the
> > > currently non existing index-files, and the instructions in the
> > > upgrade installations are a bit terse/non existing.
> > > I can reindex a single document successfully (select id where
> > > id='xxx-NS'), however there are still no files in the indexstore dir.
> > > If I start invoke 'reIndexAllDocuments' (with 1300 docs), the process
> > > loops for hours. How long is that process supposed to take? Probably
> > > you have to use the FullTextIndexer (IndexExists: false) prior to the
> > > FullTextIndexUpdater, but I don't know how.
> >
> > After invoking the reIndexAllDocuments operation, do you get the
> > confirmation page ("Invocation successful") or does the browser keep
> > waiting for a response?
> 
> No, I haven't seen the confirmation page after invoking the
> reIndexAllDocuments operation. The title bar of the browser shows
> "Loading" and seems to be busy for a long time now (we are talking
> about hours). Not sure whether really something is still going on.

When invoking reIndexAllDocuments, this is what happens:

* the query "select id where true" is executed. For 1300 documents, this
shouldn't take very long.

* for each of the documents returned by the query, a message is pushed
on the fullTextIndexerJobs JMS queue. This shouldn't take very long
either.

The actual re-indexing happens by another thread which receives the
messages pushed on the fullTextIndexerJobs queue, so this doesn't block
the response you should get from the JMX operation.

My guess is that it keeps hanging when trying to push messages on the
JMS queue.

The first thing to check is if the backup lock isn't active (you can
also see this in the JMS console: BackupLocker -> Locked attribute is
false).

If this isn't the problem, it is likely a problem somewhere in Active
MQ. You could check the log files of the repository server to see if
that says anything. If you're running the repository server in a
console, you can press "ctrl + \" to see the status of all threads,
which can help in confirming where it is really hanging. On Linux, you
can also do "jstack <pid-of-the-java-process>" to get something similar.

PS: I remember something about JMS not working when moving between the
older and newer ActiveMQ versions (first we were using some active mq
milestone before the final version), which can be solved by dropping the
tables in the ActiveMQ database. I think this can however only be the
case if you runned SVN snapshots of Daisy, I don't think this was ever
in a released version.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno at outerthought.org                          bruno at apache.org



More information about the daisy mailing list