Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 39895 invoked from network); 24 Nov 2010 15:39:12 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 24 Nov 2010 15:39:12 -0000 Received: (qmail 55284 invoked by uid 500); 24 Nov 2010 15:39:43 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 54979 invoked by uid 500); 24 Nov 2010 15:39:43 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 54972 invoked by uid 99); 24 Nov 2010 15:39:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Nov 2010 15:39:42 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Nov 2010 15:39:39 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id oAOFdHm3000316 for ; Wed, 24 Nov 2010 15:39:18 GMT Message-ID: <21769699.288071290613157937.JavaMail.jira@thor> Date: Wed, 24 Nov 2010 10:39:17 -0500 (EST) From: "Michael McCandless (JIRA)" To: dev@lucene.apache.org Subject: [jira] Resolved: (LUCENE-2729) Index corruption after 'read past EOF' under heavy update load and snapshot export In-Reply-To: <26430505.143121288365871012.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/LUCENE-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-2729. ---------------------------------------- Resolution: Invalid OK I'm glad to hear it's solved! Resolving as Invalid since this wasn't a Lucene problem. > Index corruption after 'read past EOF' under heavy update load and snapshot export > ---------------------------------------------------------------------------------- > > Key: LUCENE-2729 > URL: https://issues.apache.org/jira/browse/LUCENE-2729 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Affects Versions: 3.0.1, 3.0.2 > Environment: Happens on both OS X 10.6 and Windows 2008 Server. Integrated with zoie (using a zoie snapshot from 2010-08-06: zoie-2.0.0-snapshot-20100806.jar). > Reporter: Nico Krijnen > Attachments: 2010-11-02 IndexWriter infoStream log.zip, backup_force_failure2.log.zip, eof-extra-logging-4-analysis.txt, eof-extra-logging-4.log.zip, LUCENE-2729-test1.patch, read-past-eof-debugging.zip > > > We have a system running lucene and zoie. We use lucene as a content store for a CMS/DAM system. We use the hot-backup feature of zoie to make scheduled backups of the index. This works fine for small indexes and when there are not a lot of changes to the index when the backup is made. > On large indexes (about 5 GB to 19 GB), when a backup is made while the index is being changed a lot (lots of document additions and/or deletions), we almost always get a 'read past EOF' at some point, followed by lots of 'Lock obtain timed out'. > At that point we get lots of 0 kb files in the index, data gets lots, and the index is unusable. > When we stop our server, remove the 0kb files and restart our server, the index is operational again, but data has been lost. > I'm not sure if this is a zoie or a lucene issue, so i'm posting it to both. Hopefully someone has some ideas where to look to fix this. > Some more details... > Stack trace of the read past EOF and following Lock obtain timed out: > {code} > 78307 [proj.zoie.impl.indexing.internal.RealtimeIndexDataLoader@31ca5085] > ERROR proj.zoie.impl.indexing.internal.BaseSearchIndex - read past EOF > java.io.IOException: read past EOF > at org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:154) > at org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:39) > at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:37) > at org.apache.lucene.store.IndexInput.readInt(IndexInput.java:69) > at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:245) > at org.apache.lucene.index.IndexFileDeleter.(IndexFileDeleter.java:166) > at org.apache.lucene.index.DirectoryReader.doCommit(DirectoryReader.java:725) > at org.apache.lucene.index.IndexReader.commit(IndexReader.java:987) > at org.apache.lucene.index.IndexReader.commit(IndexReader.java:973) > at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:162) > at org.apache.lucene.index.IndexReader.close(IndexReader.java:1003) > at proj.zoie.impl.indexing.internal.BaseSearchIndex.deleteDocs(BaseSearchIndex.java:203) > at proj.zoie.impl.indexing.internal.BaseSearchIndex.loadFromIndex(BaseSearchIndex.java:223) > at proj.zoie.impl.indexing.internal.LuceneIndexDataLoader.loadFromIndex(LuceneIndexDataLoader.java:153) > at proj.zoie.impl.indexing.internal.DiskLuceneIndexDataLoader.loadFromIndex(DiskLuceneIndexDataLoader.java:134) > at proj.zoie.impl.indexing.internal.RealtimeIndexDataLoader.processBatch(RealtimeIndexDataLoader.java:171) > at proj.zoie.impl.indexing.internal.BatchedIndexDataLoader$LoaderThread.run(BatchedIndexDataLoader.java:373) > 579336 [proj.zoie.impl.indexing.internal.RealtimeIndexDataLoader@31ca5085] > ERROR proj.zoie.impl.indexing.internal.LuceneIndexDataLoader - > Problem copying segments: Lock obtain timed out: > org.apache.lucene.store.SingleInstanceLock@5ad0b895: write.lock > org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: > org.apache.lucene.store.SingleInstanceLock@5ad0b895: write.lock > at org.apache.lucene.store.Lock.obtain(Lock.java:84) > at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1060) > at org.apache.lucene.index.IndexWriter.(IndexWriter.java:957) > at proj.zoie.impl.indexing.internal.DiskSearchIndex.openIndexWriter(DiskSearchIndex.java:176) > at proj.zoie.impl.indexing.internal.BaseSearchIndex.loadFromIndex(BaseSearchIndex.java:228) > at proj.zoie.impl.indexing.internal.LuceneIndexDataLoader.loadFromIndex(LuceneIndexDataLoader.java:153) > at proj.zoie.impl.indexing.internal.DiskLuceneIndexDataLoader.loadFromIndex(DiskLuceneIndexDataLoader.java:134) > at proj.zoie.impl.indexing.internal.RealtimeIndexDataLoader.processBatch(RealtimeIndexDataLoader.java:171) > at proj.zoie.impl.indexing.internal.BatchedIndexDataLoader$LoaderThread.run(BatchedIndexDataLoader.java:373) > {code} > We get exactly the same behavour on both OS X and on Windows. On both zoie is using a SimpleFSDirectory. > We also use a SingleInstanceLockFactory (since our process is the only one working with the index), but we get the same behaviour with a NativeFSLock. > The snapshot backup is being made by calling: > *proj.zoie.impl.indexing.ZoieSystem.exportSnapshot(WritableByteChannel)* > Same issue in zoie JIRA: > http://snaprojects.jira.com/browse/ZOIE-51 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org