Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 47578 invoked from network); 22 Nov 2006 20:52:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Nov 2006 20:52:25 -0000 Received: (qmail 50804 invoked by uid 500); 22 Nov 2006 20:52:31 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 50765 invoked by uid 500); 22 Nov 2006 20:52:31 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 50754 invoked by uid 99); 22 Nov 2006 20:52:31 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Nov 2006 12:52:31 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ning.li.li@gmail.com designates 66.249.82.231 as permitted sender) Received: from [66.249.82.231] (HELO wx-out-0506.google.com) (66.249.82.231) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Nov 2006 12:52:18 -0800 Received: by wx-out-0506.google.com with SMTP id i29so320524wxd for ; Wed, 22 Nov 2006 12:51:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FgNkmxX8PKEJR7Yog7UN3yboxna8cPypR6pqhO7azKeS1x7LtbEzjQAMyaBOW/GM2WZawAT5SMX95HTkJiHPzy8coqM4f1A/k7SwpD3yo3a63cZisnSesj26OKfaTWx8z/zokRgjx7UHVROAGjd1NSor/v1vFzbUuoKjFflb3js= Received: by 10.90.49.19 with SMTP id w19mr7176010agw.1164228717865; Wed, 22 Nov 2006 12:51:57 -0800 (PST) Received: by 10.90.31.12 with HTTP; Wed, 22 Nov 2006 12:51:57 -0800 (PST) Message-ID: Date: Wed, 22 Nov 2006 15:51:57 -0500 From: "Ning Li" To: java-dev@lucene.apache.org Subject: Re: [jira] Resolved: (LUCENE-709) [PATCH] Enable application-level management of IndexWriter.ramDirectory size In-Reply-To: <4564A51B.5020602@manawiz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <26596647.1163138077092.JavaMail.jira@brutus> <22186323.1164163923262.JavaMail.jira@brutus> <45649B53.20806@gmail.com> <4564A51B.5020602@manawiz.com> X-Virus-Checked: Checked by ClamAV on apache.org > There is a flaw in this approach as you exceed the threshold before > flushing. With very large documents, that can cause an OOM. This is a good point. > I agree that it would be better to do this in IndexWriter, but more > machinery would be needed. Lucene would need to estimate the size of > the new ram segment and check the threshold prior to consuming the space. Agree. > The API that Yonik committed last night (thanks Yonik!) provides the > flexibility to address both use cases. It's a tiny bit more work for I agree that making flushRamSegments() public provides the flexibility. I was wondering if there is a way to do a bit more work so many apps could do less. Ning --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org