Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 14677 invoked from network); 11 Jul 2008 19:28:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Jul 2008 19:28:23 -0000 Received: (qmail 94190 invoked by uid 500); 11 Jul 2008 19:28:23 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 93531 invoked by uid 500); 11 Jul 2008 19:28:21 -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 93522 invoked by uid 99); 11 Jul 2008 19:28:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Jul 2008 12:28:21 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ning.li.li@gmail.com designates 74.125.44.30 as permitted sender) Received: from [74.125.44.30] (HELO yx-out-2324.google.com) (74.125.44.30) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Jul 2008 19:27:29 +0000 Received: by yx-out-2324.google.com with SMTP id 3so1088251yxj.5 for ; Fri, 11 Jul 2008 12:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fiIP/kUs07ctGlE+n/GhvlUyNETieY1TdgNzWUN5wpY=; b=tWDL8i9mTpDTYmstONSLELc/s+8O7MVAW+YcibjTHNH25uCknXxMbtZshj/V+Z3fZe qyTJi4+P253gaH6rnNzDc/nr2qrJ3gptZ4uRe6A5eR06z5msjtYu++8/6OoClGb7D1vU P904hVZUGRPN4vhA0dQXYNMb79UiilRp8/tYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=C2qvlqs4vlVxNzdaqH/Afsk/jUiRmCIkCJEYPF2eBmEKXQZ0hvTVZEG3nlYsp76ih3 I7Uo+cujk4loDGAfb+E9MPWGGidWBNy+7qgulGkU57/MbQcIwhkrEdPzu49fUC0R5MAC StCeS1mjF8D3ZjcNlY7waWDlT8tExSgGVZnAA= Received: by 10.151.144.4 with SMTP id w4mr16373500ybn.234.1215804471955; Fri, 11 Jul 2008 12:27:51 -0700 (PDT) Received: by 10.151.141.21 with HTTP; Fri, 11 Jul 2008 12:27:51 -0700 (PDT) Message-ID: Date: Fri, 11 Jul 2008 15:27:51 -0400 From: "Ning Li" To: java-dev@lucene.apache.org Subject: Re: Commit while addIndexes is in progress In-Reply-To: <486A779F-E8B2-4EF7-B853-9DB81855F06A@mikemccandless.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <486A779F-E8B2-4EF7-B853-9DB81855F06A@mikemccandless.com> X-Virus-Checked: Checked by ClamAV on apache.org > What should it "mean" when you call commit(), while another thread is in the > middle of addIndexes? > > We could 1) disallow it (throw an exception if you try), 2) allow it but > block until addIndexes is done, 3) allow it but commit all changes up until > when addIndexes was first called ... anything else? I don't have a strong preference. One reasoning is that commit itself calls flush and waits for flush to finish. So is 2) more consistent that commit waits for addIndexes to finish? We should also disallow concurrent addIndexes, right? > I think there're similar problems with calling optimize() while addIndexes > is in progress... I think we should disallow that? Optimize waits for addIndexes to finish? I think it's useful to allow addIndexes during maybeMerge and optimize, no? Cheers, Ning Li --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org