Hi, I've did some work on the Lucene plugin that should fix XPLUCENE-5, XPLUCENE-38 and XPLUCENE-40 and posted a patch here: http://jira.xwiki.org/jira/browse/XPLUCENE-5. There are more things that needs to be done. I have some comments and questions: * Why are there special "index" classes (IndexData/DocumentData/ObjectData/AttachmentData) that are stored in the queue? Why not just store XWikiDocuments and (or DocumentModelBridge) and XWikiAttachments directly? This would seem to save memory (the documents must be loaded to be indexed anyway) and reduce the load on the database (when the documents are already loaded). Maybe the idea was that by looking up the document as late as possible we will get a fresh version of it, and duplicated requests for updating a document are filtered out in the queue. But to me this seem to be a rare situation, and the way this was implemented, there was a race condition so the document was likely to be added twice anyway. * There are some code to support multiple indices, but it doesn't seem to be used and I doubt that it works. * The code contains lots of "catch (Exception e)" clauses. * Also, how threads are synchronized should be thought of more carefully. It seems that the keyword "synchronized" have been thrown in at various places "just in case". * To complete the upgrade to Lucene 2.9.0 the deprecated methods and classes should be replaced. For instance the now deprecated Hits class should be replaced with TopDocuments. * The methods IndexWriter::isLocked and IndexWriter::unlock in lucene seems unreliable. This is an obstacle for XPLUCENE-33. Best regards, Andreas Jonsson Guillaume Lerouge wrote:

Hello, I already use it as default (since 1.9.x) as I have a solution with too many data (mainly attached documents) to index and needed a more powerful indexation engine. Lucene works quite good for me but you are right, those open issues might be ennoying... I'm not expert enough to choose... Pascal On Tue, Oct 27, 2009 at 6:33 PM, Denis Gervalle <dgl(a)softec.st> wrote: