Thanks for the advice drj. I do close the searcher and set it to null before instantiating another searcher. I believe that I am closing the reader and writer at the correct times as well...
-----Original Message----- From: d rj [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 11:40 AM To: java-user@lucene.apache.org Subject: Re: Possible memory issue? I would suggest checking that close() is properly called for all IndexSearcher/Reader/Writer objects when doing adds/deletes and when recreating IndexSearcher object. Free memory in the JVM heap can diminish quickly if these objects aren't properly disposed. -drj On 10/26/06, Aigner, Thomas < [EMAIL PROTECTED]> wrote: > > Howdy all, > > I have a issue with java running out of memory after the search > has been running for a while. We are using 1.9.1 release and I check > the indexreader's version to determine if I need to get a new searcher > for searches (so I pick up any changes to the index). I am seeing jumps > in memory for the first search after loads to the index. After these > jumps the memory does not come back down after a load has taken place.. > more loads = more memory consumed until we eventually run out. Is it > possible that this is a bug with lucene caching the memory from the last > search and creating memory for the next search? Is there a way to tell > lucene to drop it's cached memory if that is the case? > > Has anyone come across this possible problem with multiple sort > fields? > > > Ex. Java memory before loads hovers around 110M and about half of it > free. > Many searches take place, memory stays relatively the same > Then Load takes place > Next search uses 192M memory with 80Meg free.. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
