Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4A3B3B04.1010700@ajlsm.com>
References: <4A3B3B04.1010700@ajlsm.com>
Date: Fri, 19 Jun 2009 05:21:22 -0400
Message-ID: <9ac0c6aa0906190221x60c659c8o7e4ee612641d1511@mail.gmail.com>
Subject: Re: windows locking file problem
From: Michael McCandless <lucene@mikemccandless.com>
To: java-user@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

It's best to let IndexWriter manage the deletion of files (for exactly
this reason).

It turns out, it's perfectly fine to open an IndexWriter with
"create=true" even when IndexReaders are reading that same index.
Those open IndexReaders continue to search their point-in-time
snapshot, and then when they reopen they'll switch to the "reset"
index.

So, assuming you have enough free disk space, you could leave your
searcher open, create an IndexWriter with create=true, call
addIndexesNoOptimize passing in your RAMDir (or, skip RAMDir and
simply add your docs directly to this writer), then commit or close
the writer and reopen the searcher.

Because Lucene is transactional, and assuming you use autoCommit=false
when opening the writer, you can make all of your index updates and
the searcher, even if reopened, will see none of these changes, until
you've called commit/close from the writer.

Mike

On Fri, Jun 19, 2009 at 3:15 AM, Malo Pichot<malo.pichot@ajlsm.com> wrote:
> Hi,
>
> I know a similar subject has been discussed in this list and this is not
> a "windows file system" list ;-) But may be someone have encountered the
> "thing"... and perhaps solved it !
>
> I have a web application that index many documents so I have a quite
> large Lucene (2.2) index (~ 350 Mo) managed by a FSDirectory. The
> indexation (I mean writing in indeces) is done by batches. Each batch
> works first in a RAMDirectory, wich is merged with the main index in a
> third one (a temporary FSDirectory). When the merge is done, the
> application have to replace the main index (untouched until this time).
> Here comes the problem ! To replace, the application close the searcher,
> then the FSDirectory itself. After that, the application delete all
> files of the main index and then copy all files of the temporary index
> in place, before re-open the FSDirectory, generate searcher, etc.
>
> All that is good in Linux environment, and in Windows most of the time.
> Yeap ! sometimes, windows FS refuses the deletion of the main index
> files. Th only way I found to force windows FS unlocking those files is
> to stop the servlets server (Tomcat). I can't shutdown Tomcat during the
> indexation work.
>
> I don't know how to solved that :-(
>
> Does anyone get inspiration ?
>
> Malo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org