> So, in 2.3.1, is there any way we can be sure that an update will not corrupt this index? You shouldn't be able to corrupt it even if you want.
DIGY -----Original Message----- From: Jeff Pennal [mailto:[email protected]] Sent: Monday, August 10, 2009 9:09 PM To: [email protected] Subject: Re: Thread safe lucene index writing Thats good to know. We've been using Lucene.NET since the 1.9 version and have gotten used to not having this ability. However, one thing we've been burned by in the past is index corruption. If we have an update that somehow messed up the index, then our applications search wouldn't work any more until the entire index was rebuilt (a long running process). So, in 2.3.1, is there any way we can be sure that an update will not corrupt this index? Digy wrote: > Starting with 2.3.1, you can concurrently make updates and searches on the > same index. But you'll have to open a new searcher in order to see the > changes. > > DIGY > > > -----Original Message----- > From: Jeff Pennal [mailto:[email protected]] > Sent: Saturday, August 08, 2009 1:17 AM > To: [email protected] > Subject: Thread safe lucene index writing > > We are currently using Lucene.Net 2.3.1 to power the search engine of > our web application. Our architecture works like this: > > - The web application queries the index for searches using the > IndexReader/IndexSearcher. > - Whenever content is updated by a user of the web app, the database is > updated and a message is put into a queue indicating that the content > needs to be updated in the lucene index > - A windows service is running, listening to the queue and when a > message comes in, will update the lucene index using an IndexWriter. > > The main objective for us here is to keep the database and the index in > sync. We need to be able to trust that when content is updated and saved > to the database, the document in the index that represents that content > will be updated asap. > > We have run into issues in the past where the IndexWriter cannot update > the index because there is a lock on the file. The usual cause of this > is that the IndexReader has the index open when the writer tries to > write to the index. > > Our current workaround for this is when we do updates to the index, we > do the updates in a temporary folder so we wont have to worry about > locks during the updating process. Once the update is done, we replace > the existing index with the newly updated one. > > While this does work now, it is not the most robust solution and will > cause us trouble scaling the web app since we want to be able to use the > lucene index in other areas than search. > > Does anyone run Lucene.Net in a similar setup? Have you any ideas on how > this configuration can be made to be more reliable when it comes to > writing to the index? > > Thanks in advance, > Jeff > > > > > > -- Jeff Pennal [email protected] OpenRoad Communications phone: 604.694.0554 x113 Internet Business Solutions fax: 604.694.0558 Vancouver, B.C. http://www.openroad.ca
