Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 30995 invoked from network); 10 Jul 2005 23:15:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Jul 2005 23:15:48 -0000 Received: (qmail 74613 invoked by uid 500); 10 Jul 2005 23:15:43 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 74569 invoked by uid 500); 10 Jul 2005 23:15:42 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 74556 invoked by uid 99); 10 Jul 2005 23:15:42 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Jul 2005 16:15:42 -0700 X-ASF-Spam-Status: No, hits=1.0 required=10.0 tests=SPF_HELO_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [169.229.70.167] (HELO rescomp.berkeley.edu) (169.229.70.167) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Jul 2005 16:15:39 -0700 Received: by rescomp.berkeley.edu (Postfix, from userid 1007) id 0DC065B7F1; Sun, 10 Jul 2005 16:15:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rescomp.berkeley.edu (Postfix) with ESMTP id 032087F460 for ; Sun, 10 Jul 2005 16:15:31 -0700 (PDT) Date: Sun, 10 Jul 2005 16:15:30 -0700 (PDT) From: Chris Hostetter Sender: hossman@hal.rescomp.berkeley.edu To: java-user@lucene.apache.org Subject: Re: Index Partitioning ( was Re: Search deadlocking under load) In-Reply-To: <73809823-CE46-406E-A142-6C4C0EA1E0E4@aconex.com> Message-ID: References: <20050708193944.61757.qmail@web31112.mail.mud.yahoo.com> <73809823-CE46-406E-A142-6C4C0EA1E0E4@aconex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N : Nathan's point about pooling Searchers is something that we also : addressed by a LRU cache mechanism. In testing we also found that Generally speaking, you only ever need one active Searcher, which all of your threads should be able to use. (Of course, Nathan says that in his code base, doing this causes his JVM to freeze up, but I've never seen this myself). I say one "active" Searcher because it might make sense in your application to open a new searcher after new documents have been added, do some searches on that new Searcher to "warm" FieldCache for ssorting, and then close the old searcher and make the new Searcher available to all of your query threads. : However his 2nd point is interesting that creating a new index each : time eventually suffered OutOfMemory (even though he's closing them) : is a worry. Is this because an IndexSearcher can be closed, but the : underlying IndexReader is not automatically closed? As I understand it, the general rule is: if you call IndexReader.open, you better call .close() on that reader. If you construct and IndexSearcher using a Directory or a path, then calling .close() on the searcher will take care of closing the reader -- but if your code look like this... Searcher s = new IndexSearcher(IndexReader.open(foo)) ...then you are screwed, because nothing will ever close that reader and free it's resources. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org