topic Re: Lucene index corruption short time after upgrade to CE 3.3g in Alfresco Archive

Lucene index corruption short time after upgrade to CE 3.3g

rays — Wed, 28 Jul 2010 15:00:31 GMT

After only two days in use, our Community Edition 3.3g server is unable to start, despite moving the lucene-indexes file out of the way and re-starting with a FULL re-indexing option selected.Below is an extract of the appearing outputs in catalina.out. Is there any hope of a recovery from this situ

Re: Lucene index corruption short time after upgrade to CE 3.3g

rays — Wed, 28 Jul 2010 15:44:16 GMT

In view of the references in catalina.out to "lock" issues, I am wondering whether this JIRA issue is at the source of our current difficulties?

http://issues.alfresco.com/jira/browse/ALF-2641 "WebDav Permission Issues - MAC OSX Finder"

We have uploaded files to the affected server using webdav from Mac OS X Finder yesterday. Could the "lock" issues I report in that JIRA bug be related to these type of entries I'm seeing today during start-up? Bearing in mind that Lucene would have backed-up its indexes between then and now.

6:59:04,952  ERROR [lucene.index.IndexInfo] Index merger failed to recover - suspending
java.lang.RuntimeException: Error during run with lock.‍‍

Again, all qualified advice would be welcomed.

Re: Lucene index corruption short time after upgrade to CE 3.3g

sibe — Tue, 20 Sep 2011 12:08:52 GMT

Hello

Have you find a solution for the problem ?

Thank I have the some probleme using alfresco community 3.3g

Thank for your answer

Re: Lucene index corruption short time after upgrade to CE 3.3g

andy — Thu, 22 Sep 2011 09:18:53 GMT

Hi

It looks like the index is confused and missing files.

More than one repo pointing at teh same index location?
Some remote protocol caching stuffed up (could be the protocol itself, time sync on machines etc etc)

Andy

Re: Lucene index corruption short time after upgrade to CE 3.3g

rivarola — Sun, 22 Apr 2012 12:59:12 GMT

Hi,

We got the same error on 3.3g during a bulk import and after having changed the merger options to

lucene.indexer.mergerMergeFactor=10
lucene.indexer.mergerRamBufferSizeMb=32
lucene.indexer.writerMergeFactor=10
lucene.indexer.writerRamBufferSizeMb=32
lucene.indexer.maxRamInMbForInMemoryMerge=32
lucene.indexer.maxRamInMbForInMemoryIndex=32‍‍‍‍‍‍

It seems the merger recovered from the error because the server is still alive and Lucene queries are still working.