Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 71633 invoked from network); 10 Aug 2006 00:16:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Aug 2006 00:16:07 -0000 Received: (qmail 49635 invoked by uid 500); 10 Aug 2006 00:16:02 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 49605 invoked by uid 500); 10 Aug 2006 00:16:01 -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 49588 invoked by uid 99); 10 Aug 2006 00:16:01 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Aug 2006 17:16:01 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= 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; Wed, 09 Aug 2006 17:16:00 -0700 Received: by rescomp.berkeley.edu (Postfix, from userid 1007) id A82DA5B766; Wed, 9 Aug 2006 17:15:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rescomp.berkeley.edu (Postfix) with ESMTP id 9868B7F403 for ; Wed, 9 Aug 2006 17:15:40 -0700 (PDT) Date: Wed, 9 Aug 2006 17:15:40 -0700 (PDT) From: Chris Hostetter To: java-user@lucene.apache.org Subject: Re: Lucene hits.length() In-Reply-To: <359a92830608091049v213b924bl19610bd83167581a@mail.gmail.com> Message-ID: References: <8834A84C87A2C148AD46921BB8BFC97C021E567A@S1SE1MAIL.emea1.ad.group> <359a92830608091049v213b924bl19610bd83167581a@mail.gmail.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 : I think, but am not certain (chime in here guys) that this is expected : behavior. As I remember from various threads, internally indexing uses a : RAMdir to accumulate data until it merges it with the FSDir. Since the : searcher and indexer are separate, I assume that the searcher is looking at : the snapshot that is on disk and missing that in the RAMdir. After you : merge, the RAMdir data has been added to that on disk, and the two are "in : synch". off the top of my head, that doesn't sound right ... Lucene's file formats and commit locks are designed to ensure that a single IndexReader (and thus, and IndexSearcher) has a consisten view of the index from the moment it is opened, to the moment it is closed -- regardless of what other IndexReaders or IndexWriters are out there mucking things up. If you open an IndexSearcher, and use it to execute a query, the number of hits you get back should be the same if you reuse that searcher to run the same query in 5 seconds, 5 minutes, 5 hours, or 5 days -- as long as you are still using that same searcher, it shouldn't matter what you do with an IndexWriter in the same process or in any other process. can you post some sample code demonstrating the problem you are having? If i had to guess, i'd speculate that maybe you are opening a new searcher more often then you think. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org