"Nilesh Bansal" <[EMAIL PROTECTED]> wrote:
> thanks for your replies. i have two more questions.
> > You need to be really certain your own locking protects Lucene
> > properly. Specifically, no IndexReader can be created (restarted)
> > while a writer is open against the index, and, only one writ
thanks for your replies. i have two more questions.
You need to be really certain your own locking protects Lucene
properly. Specifically, no IndexReader can be created (restarted)
while a writer is open against the index, and, only one writer can be
open on the index at once (it sounds like you
"Chris Hostetter" <[EMAIL PROTECTED]> wrote:
>
> : locks without upgrading to 2.1. Our application uses its own custom
> : locking mechanism, so that lucene locking is actually redundant. We
> : are currently using Lucene version 2.0.
>
> since before the 2.0.0 release there has been a static
> FS
: locks without upgrading to 2.1. Our application uses its own custom
: locking mechanism, so that lucene locking is actually redundant. We
: are currently using Lucene version 2.0.
since before the 2.0.0 release there has been a static
FSDirectory.setDisableLocks that can be called before openin
Thanks for your response. Is there a way that I can disable these read
locks without upgrading to 2.1. Our application uses its own custom
locking mechanism, so that lucene locking is actually redundant. We
are currently using Lucene version 2.0.
The application has multiple threads (different we
"Nilesh Bansal" <[EMAIL PROTECTED]> wrote:
> We have a web-based application that searches a large lucene index.
> This application only creates object of type IndexSearcher only (and
> no IndexWriters) for searching the index. After the application runs
> for some time (a few hours), I can see loc
