Re: Concurrent Indexing + Searching

Thanks a ton Mark. I am really obliged to interact with you, who is never hesistant to reply on the slightest of queries. Thanks again. Ajay Garg markrmiller wrote: > > >> Again, if the >> indexerThreads are bombarding the writer continuously, then the moment, >> when >> no indexer is accessi

Re: Concurrent Indexing + Searching

arkrmiller wrote: > > > > ajay_garg wrote: >> Thanks Mark. >> >> Ok, I got your point. So it happens like this : >> >> a) If it is me, who is re-opening an IndxReader, at any time, but >> "manually-programmatically". That is, I don&#x

Re: Concurrent Indexing + Searching

en made to the index...and it does not > want to get greedy if a Writer is batch loading, so it waits for you to > release the Writer. You can control how often the 'view' is updated by > releasing the Writer more often -- say every 50 docs. Write 50 docs, > release, get, w

Re: Concurrent Indexing + Searching

sor controls* *when the IndexSearchers are > reopened*, those docs will still not be visible until the last thread > holding a Writer releases it...that is when the reopening of Searchers > occurs as well as when the Writer is closed. > > - Mark > > ajay_garg wrote: >>

Re: Indexing Speed: 2.3 vs 2.2 (real world numbers)

Hi Jake. Was the test conducted with a single indexing thread, or multiple ones ? Jake Mannix wrote: > > Hello all, > I know you lucene devs did a lot of work on indexing performance in 2.3, > and I just tested it out last thursday, so I thought I'd let you know how > it > fared: > > On

Re: Query in Lucene 2.3.0

Thanks Yonik for the clarifications, and for the prompt replies. Now, God forbidding, I should be fine, and shouldn't be losing my sleep :-) Thanks again to Yonik and Mike. Ajay Garg Yonik Seeley wrote: > > On Feb 3, 2008 11:44 AM, ajay_garg <[EMAIL PROTECTED]> > wrote: &g

Re: Concurrent Indexing + Searching

Hi. Sorry if I seem a stranger in this thread, but there is something that I can't resist clearing myself on. Mark, you say that the additional documents added to a index, won't show up until the # of threads accessing the index hits 0; and subsequently the indexwriter instance is closed. But I

Re: Query in Lucene 2.3.0

index at a time. > > Many threads sharing a single instance of these classes has always > been fine. > > Mike > > ajay_garg wrote: > >> >> @Mike. >> >> Thanks for the reply. But I had thought that write.lock is there to >> prevent >

Re: Query in Lucene 2.3.0

to get better performance. > > Mike > > ajay_garg wrote: > >> >> @Yonik >> >> So you mean to say, that if two threads have the same instance of an >> IndexWriter passed to both of them, and both these threads run on two >> different CPUs, then they can

A small doubt related to write.lock

Hi all. I will be obliged, if someone could elaborate as to what is the difference between IndexReader.unlock() and IndexWriter.finalize() methods. Thanks Ajay Garg -- View this message in context: http://www.nabble.com/A-small-doubt-related-to-write.lock-tp15199037p15199037.html Sent from the

Re: Query in Lucene 2.3.0

@Yonik So you mean to say, that if two threads have the same instance of an IndexWriter passed to both of them, and both these threads run on two different CPUs, then they can write to the index at the same time ? Yonik Seeley wrote: > > On Jan 30, 2008 10:59 PM, ajay_garg >

Re: Query in Lucene 2.3.0

heap size so close to your actual > memory usage that GC is forced to run excessively since that'll hurt > performance. > > Mike > > ajay_garg wrote: > >> >> Hi all. >> >> Lucene latest version - 2.3.0 says that the default behaviour of >

Query in Lucene 2.3.0

Hi all. Lucene latest version - 2.3.0 says that the default behaviour of flushing from memory to file-system based index is based upon RAM usage - with 16 MB being the default value. Fine. Works for me, as long as I am using a single thread to write into the index. However, I have been trying to